When a trait is not implemented for a type, but there *is* an `impl`
for another type or different trait params, we format the output to
use highlighting in the same way that E0308 does for types.
The logic accounts for 3 cases:
- When both the type and trait in the expected predicate and the candidate are different
- When only the types are different
- When only the trait generic params are different
For each case, we use slightly different formatting and wording.
Update cargo
18 commits in e75214ea4936d2f2c909a71a1237042cc0e14b07..0310497822a7a673a330a5dd068b7aaa579a265e
2024-10-25 16:34:32 +0000 to 2024-11-01 19:27:56 +0000
- Add more metadata to `rustc_fingerprint` (rust-lang/cargo#14761)
- test(rustfix): switch to a simpler case for dedup-suggestions (rust-lang/cargo#14765)
- chore(deps): update rust crate security-framework to v3 (rust-lang/cargo#14766)
- chore(deps): update rust crate gix to 0.67.0 (rust-lang/cargo#14762)
- fix(util): Respect all `..`s in `normalize_path` (rust-lang/cargo#14750)
- test(doc): Resolve flaky test (rust-lang/cargo#14760)
- refactor(test): Remove dead 'expect_stdout_contains_n' check (rust-lang/cargo#14759)
- add unstable -Zroot-dir flag to configure the path from which rustc should be invoked (rust-lang/cargo#14752)
- docs(resolver): Further v3 prep (rust-lang/cargo#14753)
- fix: track version in fingerprint dep-info files (rust-lang/cargo#14751)
- test: Remove unused msrv-policy (rust-lang/cargo#14748)
- download targeted transitive deps of with artifact deps' target platform (rust-lang/cargo#14723)
- Remove requirement for --target when invoking Cargo with -Zbuild-std (rust-lang/cargo#14317)
- docs(fingerprint): document the encoding of Cargo's depinfo (rust-lang/cargo#14745)
- Allow build scripts to report error messages through `cargo::error` (rust-lang/cargo#14743)
- fix(publish): Downgrade version-exists error to warning on dry-run (rust-lang/cargo#14742)
- fix: clean up for deprecated and removed commands (rust-lang/cargo#14739)
- Deprecate `cargo verify-project` (rust-lang/cargo#14736)
Rollup of 14 pull requests
Successful merges:
- #131829 (Remove support for `-Zprofile` (gcov-style coverage instrumentation))
- #132369 (style-guide: Only use the new binop heuristic for assignments)
- #132383 (Implement suggestion for never type fallback lints)
- #132413 (update offset_of! docs to reflect the stabilization of nesting)
- #132438 (Remove unncessary option for default rust-analyzer setting)
- #132439 (Add `f16` and `f128` to `invalid_nan_comparison`)
- #132444 (rustdoc: Directly use rustc_abi instead of reexports)
- #132445 (Cleanup attributes around unchecked shifts and unchecked negation in const)
- #132448 (Add missing backtick)
- #132450 (Show actual MIR when MIR building forgot to terminate block)
- #132451 (remove some unnecessary rustc_allow_const_fn_unstable)
- #132455 (make const_alloc_layout feature gate only about functions that are already stable)
- #132456 (Move remaining inline assembly test files into asm directory)
- #132459 (feat(byte_sub_ptr): unstably add ptr::byte_sub_ptr)
r? `@ghost`
`@rustbot` modify labels: rollup
This adds a bunch of missing mailmap entries for many people. These are
needed when using rust-lang/team information in rust-lang/thanks, as the
emails there may differ.
These are all the "easy" ones, where there was a mailmap entry already,
making it clear which one is the preferred email address.
feat(byte_sub_ptr): unstably add ptr::byte_sub_ptr
This is an API that naturally should exist as a combination of byte_offset_from and sub_ptr
both existing (they showed up at similar times so this union was never made). Adding these
is a logical (and perhaps final) precondition of stabilizing ptr_sub_ptr (https://github.com/rust-lang/rust/issues/95892).
Original PR by ``@Gankra`` (https://github.com/rust-lang/rust/pull/121919), I am just reviving it. The 2nd commit (with a small docs tweak) is by me.
Move remaining inline assembly test files into asm directory
Before:
```
tests/assembly/asm/*
tests/assembly/asm-comments.rs
tests/codegen/asm-target-clobbers.rs
tests/codegen/asm-goto.rs
tests/codegen/asm-maybe-uninit.rs
tests/codegen/asm-msp430-clobbers.rs
tests/codegen/asm-options.rs
tests/codegen/asm-clobbers.rs
tests/codegen/asm-may_unwind.rs
tests/codegen/asm-arm64ec-clobbers.rs
tests/codegen/asm-powerpc-clobbers.rs
tests/codegen/asm-sanitize-llvm.rs
tests/codegen/asm-s390x-clobbers.rs
tests/codegen/asm-clobber_abi.rs
tests/codegen/asm-multiple-options.rs
tests/codegen/global_asm.rs
tests/codegen/global_asm_include.rs
tests/codegen/global_asm_x2.rs
tests/ui/asm/*
```
After:
```
tests/assembly/asm/*
tests/codegen/asm/*
tests/ui/asm/*
```
I moved the remaining standalone test files into the asm directory, and then either removed the "asm-" suffix or for x86-specific registers tests replaced the "asm-" suffix with the "x86-" suffix.
(Then I noticed that there is no test for clobber_abi for already stabilized aarch64, arm, riscv, and loongarch64 asm... I don't believe there is a problem like https://github.com/rust-lang/rust/pull/131332, but I plan to add tests for them later.)
r? ``@Amanieu``
``@rustbot`` label +A-inline-assembly
make const_alloc_layout feature gate only about functions that are already stable
The const_alloc_layout feature gate has two kinds of functions: those that are stable, but not yet const-stable, and those that are fully unstable.
I think we should split that up. So this PR makes const_alloc_layout just about functions that are already stable but waiting for const-stability; all the other functions now have their constness guarded by the gate that also guards their regular stability.
Cc https://github.com/rust-lang/rust/issues/67521
remove some unnecessary rustc_allow_const_fn_unstable
These are either unstable functions that don't need the attribute, or the attribute refers to a feature that is already stable.
Cleanup attributes around unchecked shifts and unchecked negation in const
The underlying intrinsic is marked as "safe to expose on stable", so we shouldn't need any `rustc_allow_const_fn_unstable(unchecked_shifts)` anywhere. However, bootstrap rustc doesn't yet have the new const stability checks, so these changes only apply under `cfg(not(bootstrap))`.
rustdoc: Directly use rustc_abi instead of reexports
rustc_target reexports a lot of things that are in rustc_abi, but that will be over soon and now is probably a good time to switch. Uses of rustc_target remain where they inquire about the target tuple.
Add `f16` and `f128` to `invalid_nan_comparison`
Currently `f32_nan` and `f64_nan` are used to provide the `invalid_nan_comparison` lint. Since we have `f16_nan` and `f128_nan`, hook these up so the new float types get the same lints.
Implement suggestion for never type fallback lints
r? ```@WaffleLapkin```
Just opening this up for vibes; it's not done yet. I'd still like to make this suggestable in a few more cases before merge:
- [x] Try to annotate `_` -> `()`
- [x] Try to annotate local variables if they're un-annotated: `let x = ...` -> `let x: () = ...`
- [x] Try to annotate the self type of a `Trait::method()` -> `<() as Trait>::method()`.
The only other case we may want to suggest is a missing turbofish, like `f()` -> `f::<()>()`. That may be possible, but seems overly annoying.
This partly addresses https://github.com/rust-lang/rust/issues/132358; the other half of fixing that would be to make the error message a bit better, perhaps just special casing the `?` operator 🤔 I don't think I'll do that part.
Remove support for `-Zprofile` (gcov-style coverage instrumentation)
Tracking issue: #42524
MCP: https://github.com/rust-lang/compiler-team/issues/798
---
This PR removes the unstable `-Zprofile` flag, which enables ”gcov-style” coverage instrumentation, along with its associated `-Zprofile-emit` configuration flag.
(The profile flag predates and is almost entirely separate from the stable `-Cinstrument-coverage` flag.)
Notably, the `-Zprofile` flag:
- Is largely untested in-tree, having only one run-make test that does not check whether its output is correct or useful.
- Has no known maintainer.
- Has seen no push towards stabilization.
- Has at least one severe regression reported in 2022 that apparently remains unaddressed.
- #100125
- Is confusingly named, since it appears to be more about coverage than performance profiling, and has nothing to do with PGO.
- Is fundamentally limited by relying on counters auto-inserted by LLVM, with no knowledge of Rust beyond debuginfo.
Double-check conditional constness in MIR
To prevent any unchecked `~const` bounds from leaking through during MIR lowering.
If this check fails, it will eventually just delay a bug, but for now it reports errors. That error reporting may be redundant if we're calling it from code that already doesn't allow `~const` (i.e. when the `effects` and `const_trait_impl` gates are disabled), but I don't think it's that big of a deal.
edit: This also makes sure that we issue a const stability error if we encounter *any* function with const conditions when `const_trait_impl` is not enabled. This ensures that that feature remains airtight.
rustc_target reexports a lot of things that are in rustc_abi, but
that will be over soon and now is probably a good time to switch.
Uses of rustc_target remain where they inquire about the target tuple.
The OS version depends on the deployment target environment variables,
the access of which we want to move to later in the compilation pipeline
that has access to more information, for example `env_depinfo`.
Some where clause lowering simplifications
Rename `PredicateFilter::SelfThatDefines` to `PredicateFilter::SelfTraitThatDefines` to make it clear that it's only concerned with converting *traits*, and make it do a bit less work when converting bounds.
Also, make the predicate filter matching in `probe_ty_param_bounds_in_generics` explicit, and simply the args it receives a bit.
This is an API that naturally should exist as a combination of byte_offset_from and sub_ptr
both existing (they showed up at similar times so this union was never made). Adding these
is a logical (and perhaps final) precondition of stabilizing ptr_sub_ptr (#95892).
Remove support for decompressing dylib metadata
We haven't been compressing dylib metadata for a while now. Removing decompression support will regress error messages about an incompatible rustc version being used, but dylibs are pretty rare anyway.
Fixes https://github.com/rust-lang/rust-analyzer/issues/18451
Use protected visibility when building rustc with LLD
https://github.com/rust-lang/compiler-team/issues/782
I wasn't sure about having two commits in a PR, but I figured, at least initially it might make sense to discuss these commits together. Happy to squash, or move the second commit to a separate PR.
I contemplated trying to enable protected visibility for more cases when LLD will be used other than just `-Zlinker-features=+lld`, but that would be more a complex change that probably still wouldn't cover all cases when LLD is used, so went with the simplest option of just checking if the linker-feature is enabled.
r? lqd
Currently `f32_nan` and `f64_nan` are used to provide the
`invalid_nan_comparison` lint. Since we have `f16_nan` and `f128_nan`,
hook these up so the new float types get the same lints.
