Add pub struct with allow(dead_code) into worklist
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Fixes#126289
Fix Miri sysroot for `x run`
Miri no longer (after https://github.com/rust-lang/miri/pull/3411) respects `MIRI_SYSROOT` and wants to be treated like a REAL rustc, with `--sysroot`. \*pats Miri\* sure Miri, just for you :3.
fixes#126233
r? RalfJung (or whoever else feels like it)
[1/2] clean-up / general improvements
This PR applies various clippy suggestions on the tools. I have only applied the ones that make sense and left out trivial changes (e.g., suggestions like 'remove &' are ignored to keep the original commit history for the lines).
I am planning to do the same for the library and compiler, but those will add too many changes to this PR, so I will handle them in a separate PR later.
Clarify `Command::new` behavior for programs with arguments
I mistakenly passed program path along arguments as the same string into `Command::new` a couple of times now. It might be useful to explicitly highlight that `Command::new` intends to accept path to a program, not path to a program plus arguments. Also nudge the user to use `Command::arg` or `Command::args` if they wish to pass arguments.
Implement lint for obligations broken by never type fallback change
This is the second (and probably last major?) lint required for the never type fallback change.
The idea is to check if the code errors with `fallback = ()` and if it errors with `fallback = !` and if it went from "ok" to "error", lint.
I'm not happy with the diagnostic, ideally we'd highlight what bound is the problem. But I'm really unsure how to do that (cc `@jackh726,` iirc you had some ideas?)
r? `@compiler-errors`
Thanks `@BoxyUwU` with helping with trait solver stuff when I was implementing the initial version of this lint.
Tracking:
- https://github.com/rust-lang/rust/issues/123748
compiletest: Stricter parsing of `//@ normalize-*` headers
I noticed some problems with the existing parser for these headers:
- It is extremely lax, and basically ignores everything other than the text between two pairs of double-quote characters.
- Unlike other name-value headers, it doesn't even check for a colon after the header name, so the test suite contains a mixture of with-colon and without-colon normalization rules.
- If parsing fails, the header is silently ignored.
The latter is especially bad for platform-specific normalization rules, because the lack of normalization probably won't be noticed until the test mysteriously fails in one of the full CI jobs.
Add a new trait to retrieve StableMir definition Ty
We implement the trait only for definitions that should have a type. It's possible that I missed a few definitions, but we can add them later if needed.
Fixes https://github.com/rust-lang/project-stable-mir/issues/80
run-make: annotate library with `#[must_use]` and enforce `unused_must_use` in rmake.rs
This PR adds `#[must_use]` annotations to functions of the `run_make_support` library where it makes sense, and adjusts compiletest to compile rmake.rs with `-Dunused_must_use`.
The rationale is that it's highly likely that unused `#[must_use]` values in rmake.rs test files are bugs. For example, unused fs/io results are often load-bearing to the correctness of the test and often unchecked fs/io results allow the test to silently pass where it would've failed if the result was checked.
This PR is best reviewed commit-by-commit.
try-job: test-various
try-job: x86_64-msvc
Make `try_from_target_usize` method public
There is now no way to create a TyConst from an integer, so I propose making this method public unless there was a reason for keeping it otherwise.
safe transmute: support `Single` enums
Previously, the implementation of `Tree::from_enum` incorrectly treated enums with `Variants::Single` and `Variants::Multiple` identically. This is incorrect for `Variants::Single` enums, which delegate their layout to that of a variant with a particular index (or no variant at all if the enum is empty).
This flaw manifested first as an ICE. `Tree::from_enum` attempted to compute the tag of variants other than the one at `Variants::Single`'s `index`, and fell afoul of a sanity-checking assertion in `compiler/rustc_const_eval/src/interpret/discriminant.rs`. This assertion is non-load-bearing, and can be removed; the routine its in is well-behaved even without it.
With the assertion removed, the proximate issue becomes apparent: calling `Tree::from_variant` on a variant that does not exist is ill-defined. A sanity check the given variant has `FieldShapes::Arbitrary` fails, and the analysis is (correctly) aborted with `Err::NotYetSupported`.
This commit corrects this chain of failures by ensuring that `Tree::from_variant` is not called on variants that are, as far as layout is concerned, nonexistent. Specifically, the implementation of `Tree::from_enum` is now partitioned into three cases:
1. enums that are uninhabited
2. enums for which all but one variant is uninhabited
3. enums with multiple inhabited variants
`Tree::from_variant` is now only invoked in the third case. In the first case, `Tree::uninhabited()` is produced. In the second case, the layout is delegated to `Variants::Single`'s index.
Fixes#125811
docs(rustc): Improve discoverable of Cargo docs
In preparing Cargo's blog post for 1.80, I tried to find the documentation for the lint configuration and I couldn't. The link is only visible from the lint itself, which isn't where I started, and the side bar, which was collapsed for me.
The first place I went was the docs for `unexpected_cfgs` because this is configuration for that lint. If using lint configuration were a one off, I could see skipping it here. However, when we discussed this with at least one T-compiler member, there was interest in using this for other lints in the future. To that end, it seems like we should be exposing this with the lint itself.
The second place I checked was the `check-cfg` documentation. This now has a call out for the sub-page.
Urls to docs in rust_hir
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Harmonize using root or leaf obligation in trait error reporting
When #121826 changed the error reporting to use root obligation and not the leafmost obligation, it didn't actually make sure that all the other diagnostics helper functions used the right obligation.
Specifically, when reporting similar impl candidates we are looking for impls of the root obligation, but trying to match them against the trait ref of the leaf obligation.
This does a few other miscellaneous changes. There's a lot more clean-up that could be done here, but working with this code is really grief-inducing due to how messy it has become over the years. Someone really needs to show it love. 😓
r? ``@estebank``
Fixes#126129
Walk into alias-eq nested goals even if normalization fails
Somewhat broken due to the fact that we don't handle aliases well, nor do we handle ambiguities well. Still want to put up this incremental piece, since it improves type errors for projections whose trait refs are not satisfied.
r? lcnr
