It seems one can't overwrite a cache entry:
```
Failed to save: Unable to reserve cache with key linkcheck--0.8.1, another job may be creating this cache. More details: Cache already exists. Scope: refs/heads/master, Key: linkcheck--0.8.1, Version: 33f8fd511bed9c91c40778bc5c27cb58425caa894ab50f9c5705d83cb78660e0
Warning: Cache save failed.
```
A proper solution is to use `restore-keys`:
https://github.com/actions/cache/blob/main/tips-and-workarounds.md#update-a-cache
Remove dead rustc_allowed_through_unstable_modules for std::os::fd contents
As far as I was able to reconstruct, the history here is roughly as follows:
- https://github.com/rust-lang/rust/pull/99723 added some `rustc_allowed_through_unstable_modules` to the types in `std::os::fd::raw` since they were accessible on stable via the unstable `std::os::wasi::io::AsRawFd` path. (This was needed to fix https://github.com/rust-lang/rust/issues/99502.)
- Shortly thereafter, https://github.com/rust-lang/rust/pull/98368 re-organized things so that instead of re-exporting from an internal `std::os::wasi::io::raw`, `std::os::wasi::io::AsRawFd` is now directly re-exported from `std::os::fd`. This also made `library/std/src/os/wasi/io/raw.rs` entirely dead code as far as I can tell, it's not imported by anything any more.
- Shortly thereafter, https://github.com/rust-lang/rust/pull/103308 stabilizes `std::os::wasi::io`, so `rustc_allowed_through_unstable_modules` is not needed any more to access `std::os::wasi::io::AsRawFd`. There is even a comment in `library/std/src/os/wasi/io/raw.rs` saying the attribute can be removed now, but that file is dead code so it is not touched as part of the stabilization.
I did a grep for `pub use crate::os::fd` and all the re-exports I could find are in stable modules. So given all that, we can remove the `rustc_allowed_through_unstable_modules` (hoping they are not also re-exported somewhere else, it's really hard to be sure about this).
I have checked that std still builds after this PR on the wasm32-wasip2 target.
Always force non-trimming of path in `unreachable_patterns` lint
Creating a "trimmed DefID path" when no error is being emitted is an ICE (on purpose). If we create a trimmed path for a lint that is then silenced before being emitted causes a known ICE. This side-steps the issue by always using `with_no_trimmed_path!`.
This was verified to fix https://github.com/quinn-rs/quinn/, but couldn't write a repro case for the test suite.
Fix#135289.
Match Ergonomics 2024: document and reorganize the currently-implemented feature gates
The hope here is to make it easier to adjust, understand, and test the experimental pattern typing rules implemented in the compiler. This PR doesn't (or at isn't intended to) change any behavior or add any new tests; I'll be handling that later. I've also included some reasoning/commentary on the more involved changes in the commit messages.
Relevant tracking issue: #123076
r? `@Nadrieril`
fully de-stabilize all custom inner attributes
`#![test]` and `#![rustfmt::skip]` were accidentally accepted in more places than they should. These have been marked as soft-unstable since forever (https://github.com/rust-lang/rust/pull/82399) and shown in future-compat reports since Rust 1.77 (https://github.com/rust-lang/rust/pull/116274).
Cc `@rust-lang/lang` `@petrochenkov`
This adds explanation of inherited references and how they relate to the default binding mode.
Co-authored-by: Nadrieril <Nadrieril@users.noreply.github.com>
Fix dev guide docs for error-pattern
I know it would have made more sense to make this PR to the dev guide repo but I had already made the fix before I realized that.
r? `@jieyouxu`
Don't skip argument parsing when running `rustc` with no arguments
Setting up the argument parser to parse no arguments is a tiny bit of wasted work, but avoids an otherwise-unnecessary special case, in a scenario (printing a help message and quitting) where perf at this scale really doesn't matter anyway.
In particular, this lets us avoid having to deal with multiple different APIs to determine whether the compiler is nightly or not.
---
This special-case handling for rustc with no arguments is very very old (long predating 1.0), and used to be much simpler, without any need to set up boolean values to handle various conditional cases. So I don't think it was ever explicitly decided that having this special case was worth the extra complexity; it just started out simple and accumulated complexity over time.
Improve `select_nth_unstable` documentation clarity
* Instead uses `before` and `after` variable names in the example
where `greater` and `lesser` are flipped.
* Uses `<=` and `>=` instead of "less than or equal to" and "greater
than or equal to" to make the docs more concise.
* General attempt to remove unnecessary words and be more precise. For
example it seems slightly wrong to say "its final sorted position",
since this implies there is only one sorted position for this element.
