Implement rustc part of RFC 3127 trim-paths
This PR implements (or at least tries to) [RFC 3127 trim-paths](https://github.com/rust-lang/rust/issues/111540), the rustc part. That is `-Zremap-path-scope` with all of it's components/scopes.
`@rustbot` label: +F-trim-paths
Normalize alloc-id in tests.
AllocIds are globally numbered in a rustc invocation. This makes them very sensitive to changes unrelated to what is being tested. This commit normalizes them by renumbering, in order of appearance in the output.
The renumbering allows to keep the identity, that a simple `allocN` wouldn't. This is useful when we have memory dumps.
cc `@saethlin`
r? `@oli-obk`
Rollup of 5 pull requests
Successful merges:
- #111072 (Add new simpler and more explicit syntax for check-cfg)
- #116717 (Special case iterator chain checks for suggestion)
- #116719 (Add MonoItems and Instance to stable_mir)
- #116787 (Implement an internal lint encouraging use of `Span::eq_ctxt`)
- #116827 (Make `handle_options` public again.)
r? `@ghost`
`@rustbot` modify labels: rollup
Implement an internal lint encouraging use of `Span::eq_ctxt`
Adds a new Rustc internal lint that forbids use of `.ctxt() == .ctxt()` for spans, encouraging use of `.eq_ctxt()` instead (see https://github.com/rust-lang/rust/issues/49509).
Also fixed a few violations of the lint in the Rustc codebase (a fun additional way I could test my code). Edit: MIR opt folks I believe that's why you're CC'ed, just a heads up.
Two things I'm not sure about:
1. The way I chose to detect calls to `Span::ctxt`. I know adding diagnostic items to methods is generally discouraged, but after some searching and experimenting I couldn't find anything else that worked, so I went with it. That said, I'm happy to implement something different if there's a better way out there. (For what it's worth, if there is a better way, it might be worth documenting in the rustc-dev-guide, which I'm happy to take care of)
2. The error message for the lint. Ideally it would probably be good to give some context as to why the suggestion is made (e.g. `rustc::default_hash_types` tells the user that it's because of performance), but I don't have that context so I couldn't put it in the error message. Happy to iterate on the error message based on feedback during review.
r? ``@oli-obk``
Use tidy to enforce alphabetical dependency ordering
I get annoyed when dependencies in `Cargo.toml` files are not in alphabetical order. The [style guide](https://github.com/rust-lang/rust/blob/master/src/doc/style-guide/src/cargo.md) agrees with me.
There are ongoing efforts to provide linting/formatting of `Cargo.toml` files, e.g. https://github.com/rust-lang/rustfmt/pull/5240, https://crates.io/crates/cargo-toml-lint, and https://github.com/TimonPost/cargo-toml-format. But it's far from clear what's the right approach.
So this PR does something very simple: it uses the order checking already present in tidy. This allows incremental application of ordering, starting right now, and avoiding the need for any kind of all-at-once conversion.
If we do end up using some more comprehensive `Cargo.toml` linting/formatting solution in the future, the `tidy-alphabetical` lines will be easy to remove.
r? `@wesleywiser`
Improve display of parallel jobs in rustdoc-gui tester script
If no `-j` option is not passed to `x.py`, it would display `-1`, which isn't great.
r? `@notriddle`
It's a better name, and lets "active features" refer to the features
that are active in a particular program, due to being declared or
enabled by the edition.
The commit also renames `Features::enabled` as `Features::active` to
match this; I changed my mind and have decided that "active" is a little
better thatn "enabled" for this, particularly because a number of
pre-existing comments use "active" in this way.
Finally, the commit renames `Status::Stable` as `Status::Accepted`, to
match `ACCEPTED_FEATURES`.
