Tweak output of import suggestions
When both `std::` and `core::` items are available, only suggest the `std::` ones. We ensure that in `no_std` crates we suggest `core::` items.
Ensure that the list of items suggested to be imported are always in the order of local crate items, `std`/`core` items and finally foreign crate items.
Tweak wording of import suggestion: if there are multiple items but they are all of the same kind, we use the kind name and not the generic "items".
Fix#83564.
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.
When both `std::` and `core::` items are available, only suggest the
`std::` ones. We ensure that in `no_std` crates we suggest `core::`
items.
Ensure that the list of items suggested to be imported are always in the
order of local crate items, `std`/`core` items and finally foreign crate
items.
Tweak wording of import suggestion: if there are multiple items but they
are all of the same kind, we use the kind name and not the generic "items".
Fix#83564.
This partially reverts #17350, based on the feedback in #17397.
If we don't have an autofix, it's more annoying to highlight the whole line.
This heuristic fixes the diagnostic overwhelming the user during startup.
Implement LLVM x86 SSE4.2 intrinsics
SSE4.2 is arguably the least important SIMD extension for the x86 ISA, but it should still be supported for the sake of completeness.
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.
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
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.
