Since [1], `Cargo.lock` was split into `Cargo.lock` and
`library/Cargo.lock`. Update Triagebot to give the same warning for both.
[1]: https://github.com/rust-lang/rust/pull/128534
Rollup of 8 pull requests
Successful merges:
- #125042 (Use ordinal number in argument error)
- #127229 (rustdoc: click target for sidebar items flush left)
- #127337 (Move a few intrinsics to Rust abi)
- #127472 (MIR building: Stop using `unpack!` for `BlockAnd<()>`)
- #127579 (Solve a error `.clone()` suggestion when moving a mutable reference)
- #127769 (Don't use implicit features in `Cargo.toml` in `compiler/`)
- #127844 (Remove invalid further restricting suggestion for type bound)
- #127855 (Add myself to review rotation)
r? `@ghost`
`@rustbot` modify labels: rollup
Merge Apple `std::os` extensions modules into `std::os::darwin`
The functionality available on Apple platforms are very similar, and were (basically) duplicated for each platform.
This PR rectifies that by merging the code into one module.
Ultimately, I've done this to fix `./x build library --target=aarch64-apple-tvos,aarch64-apple-watchos,aarch64-apple-visionos`, as that currently fails because of dead code warnings.
Publically exposing these to tvOS/watchOS/visionOS targets is considered in https://github.com/rust-lang/rust/pull/123723, but that seems to be dragging out, and in any case I think it makes sense to do the refactor separately from stabilization.
r? libs
Fixes https://github.com/rust-lang/rust/issues/121640 and https://github.com/rust-lang/rust/issues/124825.
The functionality available on Apple platforms are very similar, and
were duplicated for each platform.
Additionally, this fixes a warning when compiling the standard library
for tvOS, watchOS and visionOS by marking the corresponding code as
dead code.
- Autolabel PRs modifying `tests/run-make/` and
`src/tools/run-make-support/` with `X-run-make` label.
- Add reminder to update the tracking issue
<https://github.com/rust-lang/rust/issues/121876>
if applicable when `tests/run-make/` is modified by a PR.
Notify T-rustdoc for beta-accepted and stable-accepted too
Otherwise, it's unclear when the nomination label is removed whether the backport was accepted, thus nomination removed, or if the backport was rejected, thus nomination removed.
r? ````@GuillaumeGomez````
Also mention my-self for other check-cfg docs changes
This PR adds a mention for my-self for the recently added `src/doc/rustc/src/check-cfg` directory.
*I had to add a second mention just for the directory since [`Path::starts_with`](https://doc.rust-lang.org/std/path/struct.Path.html#method.starts_with) as used by [triagebot](48f29f351c/src/handlers/mentions.rs (L69)), matches on path components and so can never return true for a file and directory at the same time.*
Otherwise, it's unclear when the nomination label is removed whether the
backport was accepted, thus nomination removed, or if the backport was
rejected, thus nomination removed.
Meta: Allow unauthenticated users to modify `L-*`, `PG-*` and `-Z*` labels
Complements: rust-lang/rust-forge#744.
1. `L-*`: Issues and PRs concerning specific lints
2. `PG-*`: Issues and PRs concerning specific project groups
3. `-Z*`: Issues and PRs concerning specific unstable `-Z` compiler options
These are safe to expose. Allows unauthenticated users greater leeway in triaging issues.
We have a lot of such people <3 and I want to support them as much as possible.
r? jieyouxu (you get assigned a lot these days :P) or compiler
[meta] Clarify prioritization alert
Apparently, there used to exist the label <kbd>I-nominated</kbd> judging from this entry:
8847bda592/triagebot.toml (L393)
Since it was replaced with individual team labels, I think it makes sense to update the prioritization alert. Of course, it's not super important since the members of WG-prioritization already know that. This is just cleanup.
r? apiraino or wg-prioritization
use key-value format in stage0 file
Currently, we are working on the python removal task on bootstrap. Which means we have to extract some data from the stage0 file using shell scripts. However, parsing values from the stage0.json file is painful because shell scripts don't have a built-in way to parse json files.
This change simplifies the stage0 file format to key-value pairs, which makes it easily readable from any environment.
See the zulip thread for more details: https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/Using.20different.20format.20in.20the.20stage0.20file
meta: notify #t-rustdoc Zulip stream on backport nominations
In July '23, it was decided to handle rustdoc-specific backport nominations in t-rustdoc meetings going forward ([Zulip announcement](https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/T-rustdoc.20backports/near/374828518)). However, t-rustdoc meetings are far too infrequent for them to address nominations on time (contrary to the weekly t-compiler meetings).
Hence GuillaumeGomez and I came to the conclusion that {beta,stable}-nominated rustdoc PRs should be dealt with on a case by case basis, e.g. on Zulip.
This PR attempts to partially automate this process. ~~Sadly, `triagebot` is not quite as flexible has I've hoped. Blocked on `triagebot` improvements (see the `FIXME`s in this PR).~~ (Fixed in rust-lang/triagebot#1791).
r? GuillaumeGomez
Stabilize checking of cfgs at compile-time: `--check-cfg` option
This PR stabilize the `--check-cfg` CLI option of `rustc` (and `rustdoc`) 🎉.
In particular this PR does two things:
1. it makes the `--check-cfg` option stable
2. and it moves the documentation to the stable books
FCP: https://github.com/rust-lang/rust/issues/82450#issuecomment-1965328542Resolves#82450
``@rustbot`` labels +S-blocked +F-check-cfg
r? ``@petrochenkov``
