[Debugger Visualizers] Unify `*-gnu` and `*-msvc` enum output
Followup patch to rust-lang/rust#145218
Ports the msvc enum synthetic/summary logic to the gnu handlers so they have identical output. Also removes the "look-through-pointers" logic that caused rust-lang/rust#147450
<img width="629" height="220" alt="image" src="https://github.com/user-attachments/assets/d6ae44d5-232f-412d-b291-64ac52850c74" />
I know we don't run the test suite in CI anymore, but it's still useful locally so I updated the relevant tests.
Fix MaybeUninit codegen using GVN
This is an alternative to https://github.com/rust-lang/rust/pull/142837, based on https://github.com/rust-lang/rust/pull/146355#discussion_r2421651968.
The general approach I took here is to aggressively propagate anything that is entirely uninitialized. GVN generally takes the approach of only synthesizing small types, but we need to generate large consts to fix the codegen issue.
I also added a special case to MIR dumps for this where now an entirely uninit const is printed as `const <uninit>`, because otherwise we end up with extremely verbose dumps of the new consts.
After GVN though, we still end up with a lot of MIR that looks like this:
```
StorageLive(_1);
_1 = const <uninit>;
_2 = &raw mut _1;
```
Which will break tests/codegen-llvm/maybeuninit-rvo.rs with the naive lowering. I think the ideal fix here is to somehow omit these `_1 = const <uninit>` assignments that come directly after a StorageLive, but I'm not sure how to do that. For now at least, ignoring such assignments (even if they don't come right after a StorageLive) in codegen seems to work.
Note that since GVN is based on synthesizing a `ConstValue` which has a defined layout, this scenario still gets deoptimized by LLVM.
```rust
#![feature(rustc_attrs)]
#![crate_type = "lib"]
use std::mem::MaybeUninit;
#[unsafe(no_mangle)]
pub fn oof() -> [[MaybeUninit<u8>; 8]; 8] {
#[rustc_no_mir_inline]
pub fn inner<T: Copy>() -> [[MaybeUninit<T>; 8]; 8] {
[[MaybeUninit::uninit(); 8]; 8]
}
inner()
}
```
This case can be handled correctly if enough inlining has happened, or it could be handled by post-mono GVN. Synthesizing `UnevaluatedConst` or some other special kind of const seems dubious.
Turn moves into copies after copy propagation
Previously copy propagation presumed that there is further unspecified distinction between move operands and copy operands in assignments and propagated moves from assignments into terminators. This is inconsistent with current operational semantics.
Turn moves into copies after copy propagation to preserve existing behavior.
Fixes https://github.com/rust-lang/rust/issues/137936.
Fixes https://github.com/rust-lang/rust/issues/146423.
r? `@cjgillot`
Skip unused variables warning for unreachable code
Fixesrust-lang/rust#148373
These warnings are not reported on stable branch, but are now reported on the beta.
I tried another solution to record whether a `local` is reachable in `find_dead_assignments`, but the code in this PR seems simpler.
r? `@cjgillot`
Fix ICE when collecting opaques from trait method declarations
fixesrust-lang/rust#148622
When using an `opaque` type as a `const` generic parameter, the compiler would attempt to collect TAIT from trait method declarations, causing an ICE by panicking in `hir_body_owned_by`.
Fix the issue of unused assignment from MIR liveness checking
Fixesrust-lang/rust#148960Fixesrust-lang/rust#148418
r? ``@davidtwco``
cc ``@cjgillot``
My first try on MIR related code, so it may not be the best fix.
Address annotate-snippets test differences
When `annotate-snippets` became the default renderer on `nightly`, it came with a few rendering differences. I was not entirely happy with a few of the differences, and after talking with ``@davidtwco`` about them, I decided to address those that seemed like regressions.
r? ``@davidtwco``
Warn against calls which mutate an interior mutable `const`-item
## `const_item_interior_mutations`
~~`interior_mutable_const_item_mutations`~~
~~`suspicious_mutation_of_interior_mutable_consts`~~
*warn-by-default*
The `const_item_interior_mutations` lint checks for calls which mutates an interior mutable const-item.
### Example
```rust
use std::sync::Once;
const INIT: Once = Once::new(); // using `INIT` will always create a temporary and
// never modify it-self on use, should be a `static`
// instead for shared use
fn init() {
INIT.call_once(|| {
println!("Once::call_once first call");
});
}
```
```text
warning: mutation of an interior mutable `const` item with call to `call_once`
--> a.rs:11:5
|
11 | INIT.call_once(|| {
| ^---
| |
| _____`INIT` is a interior mutable `const` item of type `std::sync::Once`
| |
12 | | println!("Once::call_once first call");
13 | | });
| |______^
|
= note: each usage of a `const` item creates a new temporary
= note: only the temporaries and never the original `const INIT` will be modified
= help: for more details on interior mutability see <https://doc.rust-lang.org/reference/interior-mutability.html>
= note: `#[warn(const_item_interior_mutations)]` on by default
help: for a shared instance of `INIT`, consider making it a `static` item instead
|
6 - const INIT: Once = Once::new(); // using `INIT` will always create a temporary and
6 + static INIT: Once = Once::new(); // using `INIT` will always create a temporary and
|
```
### Explanation
Calling a method which mutates an interior mutable type has no effect as const-item are essentially inlined wherever they are used, meaning that they are copied directly into the relevant context when used rendering modification through interior mutability ineffective across usage of that const-item.
The current implementation of this lint only warns on significant `std` and `core` interior mutable types, like `Once`, `AtomicI32`, ... this is done out of prudence and may be extended in the future.
----
This PR is an targeted alternative to rust-lang/rust#132146. It avoids false-positives by adding an internal-only attribute `#[rustc_should_not_be_called_on_const_items]` on methods and functions that mutates an interior mutale type through a shared reference (mutable refrences are already linted by the `const_item_mutation` lint).
It should also be noted that this is NOT an uplift of the more general [`clippy::borrow_interior_mutable_const`](https://rust-lang.github.io/rust-clippy/master/index.html#/borrow_interior_mutable_const) lint, which is a much more general lint regarding borrow of interior mutable types, but has false-positives that are completly avoided by this lint.
A simple [GitHub Search](https://github.com/search?q=lang%3Arust+%2F%28%3F-i%29const+%5Ba-zA-Z0-9_%5D*%3A+Once%2F&type=code) reveals many instance where the user probably wanted to use a `static`-item instead.
----
````@rustbot```` labels +I-lang-nominated +T-lang
cc ````@traviscross````
r? compiler
Fixes [IRLO - Forbidding creation of constant mutexes, etc](https://internals.rust-lang.org/t/forbidding-creation-of-constant-mutexes-etc/19005)
Fixes https://github.com/rust-lang/rust/issues/132028
Fixes https://github.com/rust-lang/rust/issues/40543
Reduce confusing `unreachable_code` lints
Closesrust-lang/rust#149042
Attempts to be smarter about identifying 'real'/user-written unreachable code to raise the lint
Fix error message for calling a non-tuple struct
This feels a bit odd checking for `"0"` but I can't see how else to check for it being a Tuple
closes https://github.com/rust-lang/rust/issues/148919
rustdoc-json: add rlib path to ExternalCrate to enable robust crate resolution
Historically, it's not been possible to robustly resolve a cross-crate item in rustdoc-json. If you had a `Id` that wasn't in `Crate::index` (because it was defined in a different crate), you could only look it up it `Crate::paths`. But there, you don't get the full information, only an `ItemSummary`. This tells you the `path` and the `crate_id`.
But knowing the `crate_id` isn't enough to be able to build/find the rustdoc-json output with this item. It's only use is to get a `ExternalCrate` (via `Crate::external_crates`). But that only tells you the `name` (as a string). This isn't enough to uniquely identify a crate, as there could be multiple versions/features [^1] [^2].
This was originally proposed to be solved via `@LukeMathWalker's` `--orchestrator-id` proposal (https://github.com/rust-lang/compiler-team/issues/635). But that requires invasive changes to cargo/rustc. This PR instead implements `@Urgau's` proposal to re-use the path to a crate's rmeta/rlib as a unique identifer. Callers can use that to determine which package it corresponds to in the language of the build-system above rustc. E.g. for cargo, `cargo rustdoc --message-format=json --output-format=json -Zunstable-options`).
(Once you've found the right external crate's rustdoc-json output, you still need to resolve the path->id in that crate. But that's """just""" a matter of walking the module tree. We should probably still make that nicer (by, for example, allowing sharing `Id`s between rustdoc-json document), but that's a future concern)
For some notes from RustWeek 2025, where this was designed, see https://hackmd.io/0jkdguobTnW7nXoGKAxfEQ
CC `@obi1kenobi` (who wants this for cargo-semver-checks [^3]), `@epage` (who's conversations on what and wasn't possible with cargo informed taking this approach to solve this problem)
r? `@GuillaumeGomez`
## TODO:
- [x] Docs: [Done](e4cdd0c24a..457ed4edb1)
- [x] Tests: [Done](2e1b954dc5..4d00c1a7ee)
[^1]: https://github.com/rust-lang/compiler-team/issues/635#issue-1714254865 § Problem
[^2]: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/Identifying.20external.20crates.20in.20Rustdoc.20JSON/with/352701211
[^3]: https://github.com/obi1kenobi/cargo-semver-checks/issues/638
Historically, it's not been possible to robustly resolve a cross-crate
item in rustdoc-json. If you had a `Id` that wasn't in `Crate::index`
(because it was defined in a different crate), you could only look it up
it `Crate::paths`. But there, you don't get the full information, only
an `ItemSummary`. This tells you the `path` and the `crate_id`.
But knowing the `crate_id` isn't enough to be able to build/find the
rustdoc-json output with this item. It's only use is to get a
`ExternalCrate` (via `Crate::external_crates`). But that only tells you
the `name` (as a string). This isn't enough to uniquely identify a
crate, as there could be multiple versions/features [1] [2].
This was originally proposed to be solved via LukeMathWalker's
`--orchestrator-id` proposal
(https://www.github.com/rust-lang/compiler-team/issues/635). But that
requires invasive changes to cargo/rustc. This PR instead implements
Urgau's proposal to re-use the path to a crate's rmeta/rlib as a unique
identifer. Callers can use that to determine which package it
corresponds to in the language of the build-system above rustc. E.g. for
cargo, `cargo rustdoc --message-format=json --output-format=json
-Zunstable-options`).
(Once you've found the right external crate's rustdoc-json output, you
still need to resolve the path->id in that crate. But that's """just"""
a matter of walking the module tree. We should probably still make that
nicer (by, for example, allowing sharing `Id`s between rustdoc-json
document), but that's a future concern)
For some notes from RustWeek 2025, where this was designed, see
https://hackmd.io/0jkdguobTnW7nXoGKAxfEQ
[1]: https://www.github.com/rust-lang/compiler-team/issues/635#issue-1714254865 § Problem
[2]: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/Identifying.20external.20crates.20in.20Rustdoc.20JSON/with/352701211
Check for intrinsic to fn ptr casts in unified coercions
Fixesrust-lang/rust#149143 by ensuring that when coercing multiple expressions to a unified type, the same "intrinsic to fn ptr" check is applied as for other coercions.
Reject `async fn` in `const impl` during AST validation
closesrust-lang/rust#149083
Fixes the ICE when using `async fn` inside `const impl` blocks by adding AST validation.
Currently, inherent `impl`s does not perform any checks to verify whether it contains `async fn` declarations. In this PR, I have modified the `visit_assoc_item` function to call `check_async_fn_in_const_trait_or_impl` within the `TraitOrImpl::Impl` case to handle this requirement. Additionally, this change has introduced three possible contexts for the corresponding error messages, so I have updated to properly distinguish between these different contexts when generating messages.
r? oli-obk
autodiff rlib handling
As I learned recently, we now apparently support rlib builds already in some cases.
With the last hint from saethlin this seems to now cover all cases. To be sure I'll add a few more testcases before I mark it as ready.
Once this PR lands, we should to the best of my knowledge, support autodiff in almost code locations, only vtable/dyn ptr remain unsupported for now.
r? ghost
closes: https://github.com/rust-lang/rust/issues/148856
closes: https://github.com/rust-lang/rust/issues/137520
See if this is the time we can remove `layout::size_align`
This was a bad idea before, but now that `size_of` and `align_of` work completely differently than when removing it was first tried in 2020, maybe it makes sense now.
(Or maybe I'll just add another attempt to the list in the comments...)
r? ghost
Previously copy propagation presumed that there is further unspecified
distinction between move operands and copy operands in assignments and
propagated moves from assignments into terminators. This is inconsistent
with current operational semantics.
Turn moves into copies after copy propagation to preserve existing behavior.
Fixes https://github.com/rust-lang/rust/issues/137936.
Fixes https://github.com/rust-lang/rust/issues/146423.
fix the fragment_in_dst_padding_gets_overwritten test on s390x
on s390x 128bit types have a smaller alignment then on x86[^1]. This leads to smaller structs (24 instead of 32 bytes) and therefore the write_unaligned will write outside of the structs boundary.
To fix the test, change the trailing u32 into a u8. This will generate 7 trailing padding bytes on s390x and 15 on x86_64. Also change the start of the garbage data so it will span over x,y and padding:
```
s390x: XXXXXXXXXXXXXXXXY-------
x86_64: XXXXXXXXXXXXXXXXY---------------
GGGGGGGG
```
[^1]: s390x ELF ABI Table 1.1, Page 12 https://github.com/IBM/s390x-abi
ignore unsized types in mips64 and sparc64 callconvs
Non-rustic calling conventions should not make up an ABI for unsized types (cc https://github.com/rust-lang/rust/pull/148302). The vast majority of our callconv implementations already ignore unsized types, `sparc64` and `mips64` I guess were missed.
r? `````@bjorn3`````
This was a bad idea before, but now that `size_of` and `align_of` work completely differently than when removing it was first tried in 2020, maybe it makes sense now.
(Or maybe I'll just add another attempt to the list in the comments...)
