Don't reset cast kind without also updating the operand in `simplify_cast` in GVN
Consider this heavily elided segment of the pre-GVN example code that was committed as a test:
```rust
let _4: *const ();
let _5: *const [()];
let mut _6: *const ();
let _7: *mut ();
let mut _8: *const [()];
let mut _9: std::boxed::Box<()>;
let mut _10: *const ();
/* ... */
// Deref a box
_10 = copy ((_9.0: std::ptr::Unique<()>).0: std::ptr::NonNull<()>) as *const () (Transmute);
_4 = copy _10;
_6 = copy _4;
// Inlined body of `slice::from_raw_parts`, to turn a unit pointer into a slice-of-unit pointer
_5 = *const [()] from (copy _6, copy _11);
_8 = copy _5;
// Cast the raw slice-of-unit pointer back to a unit pointer
_7 = copy _8 as *mut () (PtrToPtr);
```
A malformed optimization was changing `_7` (which casted the slice-of-unit ptr to a unit ptr) to:
```
_7 = copy _5 as *mut () (Transmute);
```
...where `_8` was just replaced with `_5` bc of simple copy propagation, that part is not important... the CastKind changing to Transmute is the important part here.
In #133324, two new functionalities were implemented:
* Peeking through unsized -> sized PtrToPtr casts whose operand is `AggregateKind::RawPtr`, to turn it into PtrToPtr casts of the base of the aggregate. In this case, this allows us to see that the value of `_7` is just a ptr-to-ptr cast of `_6`.
* Folding a PtrToPtr cast of an operand which is a Transmute cast into just a single Transmute, which (theoretically) allows us to treat `_7` as a transmute into `*mut ()` of the base of the cast of `_10`, which is the place projection of `((_9.0: std::ptr::Unique<()>).0: std::ptr::NonNull<()>)`.
However, when applying those two subsequent optimizations, we must *not* update the CastKind of the final cast *unless* we also update the operand of the cast, since the operand may no longer make sense with the updated CastKind.
In this case, this is problematic because the type of `_8` is `*const [()]`, but that operand in assignment statement of `_7` does *not* get turned into something like `((_9.0: std::ptr::Unique<()>).0: std::ptr::NonNull<()>)` -- **in other words, `try_to_operand` fails** -- because GVN only turns value nodes into locals or consts, not projections of locals. So we fail to update the operand, but we still update the CastKind to Transmute, which means we now are transmuting types of different sizes (a wide pointer and a thin pointer).
r? `@scottmcm` or `@cjgillot`
Fixes#136361Fixes#135997
Simplify slice indexing in next trait solver
Unless I'm missing something:
- no need to explicitly specify the end of the slice as the end of the index range
- the `assert` is redundant since the indexing will panic for the same condition
I think this change simplifies it a bit. Also replaced the `for` loop of `push`es with a call to `extend` with an iterator. Might improve performance since it knows how many elements will be added beforehand and can pre-reserve room?
r? `@compiler-errors` , I think
Rollup of 7 pull requests
Successful merges:
- #136073 (Always compute coroutine layout for eagerly emitting recursive layout errors)
- #136235 (Pretty print pattern type values with transmute if they don't satisfy their pattern)
- #136311 (Ensure that we never try to monomorphize the upcasting or vtable calls of impossible dyn types)
- #136315 (Use short ty string for binop and unop errors)
- #136393 (Fix accidentally not emitting overflowing literals lints anymore in patterns)
- #136435 (Simplify some code for lowering THIR patterns)
- #136630 (Change two std process tests to not output to std{out,err}, and fix test suite stat reset in bootstrap CI test rendering)
r? `@ghost`
`@rustbot` modify labels: rollup
try-job: aarch64-gnu-debug
Change two std process tests to not output to std{out,err}, and fix test suite stat reset in bootstrap CI test rendering
I don't really know how to test if this unbreaks CI (since #136607 reported that this breaks the CI test rendering *sometimes*).
Fixes#136607.
r? `@ChrisDenton` (two Windows process tests, but feel free to reroll)
Simplify some code for lowering THIR patterns
I've been playing around with some radically different ways of storing THIR patterns, and while those experiments haven't yet produced a clear win, I have noticed various smaller things in the existing code that can be made a bit nicer.
Some of the more significant changes:
- With a little bit of extra effort (and thoughtful use of Arc), we can completely remove an entire layer of `'pat` lifetimes from the intermediate data structures used for match lowering.
- In several places, lists of THIR patterns were being double-boxed for no apparent reason.
Fix accidentally not emitting overflowing literals lints anymore in patterns
This was regressed in https://github.com/rust-lang/rust/pull/134228 (not in beta yet).
The issue was that previously we nested `hir::Expr` inside `hir::PatKind::Lit`, so it was linted by the expression code.
So now I've set it up for visitors to be able to directly visit literals and get all literals
Use short ty string for binop and unop errors
```
error[E0369]: cannot add `(..., ..., ..., ...)` to `(..., ..., ..., ...)`
--> $DIR/binop.rs:10:7
|
LL | x + x;
| - ^ - (..., ..., ..., ...)
| |
| (..., ..., ..., ...)
|
= note: the full name for the type has been written to '$TEST_BUILD_DIR/$FILE.long-type-hash.txt'
= note: consider using `--verbose` to print the full type name to the console
```
```
error[E0600]: cannot apply unary operator `!` to type `(..., ..., ..., ...)`
--> $DIR/binop.rs:14:5
|
LL | !x;
| ^^ cannot apply unary operator `!`
|
= note: the full name for the type has been written to '$TEST_BUILD_DIR/$FILE.long-type-hash.txt'
= note: consider using `--verbose` to print the full type name to the console
```
CC #135919.
Ensure that we never try to monomorphize the upcasting or vtable calls of impossible dyn types
Check for impossible obligations in the `dyn Trait` type we're trying to compute its the vtable upcasting and method call slots.
r? lcnr
Pretty print pattern type values with transmute if they don't satisfy their pattern
Instead of printing `0_u32 is 1..`, we now print the default fallback rendering that we also use for invalid bools, chars, ...: `{transmute(0x00000000): (u32) is 1..=}`.
These cases can occur in mir dumps when const prop propagates a constant across a safety check that would prevent the actually UB value from existing. That's fine though, as it's dead code and we always need to allow UB in dead code.
follow-up to https://github.com/rust-lang/rust/pull/136176
cc ``@compiler-errors`` ``@scottmcm``
r? ``@RalfJung`` because of the interpreter changes
Always compute coroutine layout for eagerly emitting recursive layout errors
Detect recursive coroutine layouts even if we don't detect opaque type recursion in the new solver. This is for two reasons:
1. It helps us detect (bad) recursive async function calls in the new solver, which due to its approach to normalization causes us to not detect this via a recursive RPIT (since the opaques are more eagerly revealed in the opaque body).
* Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/137.
2. It helps us detect (bad) recursive async functions behind AFITs. See the AFIT test that changed for the old solver too.
3. It also greatly simplifies the recursive impl trait check, since I can remove some jankness around how it handles coroutines.
tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc`
tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc`
This is continuation of https://github.com/rust-lang/rust/pull/132282 .
I'm pretty sure I did everything right. In particular, I searched all occurrences of `Lrc` in submodules and made sure that they don't need replacement.
There are other possibilities, through.
We can define `enum Lrc<T> { Rc(Rc<T>), Arc(Arc<T>) }`. Or we can make `Lrc` a union and on every clone we can read from special thread-local variable. Or we can add a generic parameter to `Lrc` and, yes, this parameter will be everywhere across all codebase.
So, if you think we should take some alternative approach, then don't merge this PR. But if it is decided to stick with `Arc`, then, please, merge.
cc "Parallel Rustc Front-end" ( https://github.com/rust-lang/rust/issues/113349 )
r? SparrowLii
`@rustbot` label WG-compiler-parallel
cg_llvm: Remove the `mod llvm_` hack, which should no longer be necessary
This re-export was introduced in c76fc3d804, as a workaround for #53912.
In short, there was/is an assumption in some LLVM LTO code that symbol names would not contain `.llvm.`, but legacy symbol mangling would naturally produce that sequence for symbols in a module named `llvm`.
This was later “fixed” by adding a special case to the legacy symbol mangler in #61195, which detects the sequence `llvm` and emits the `m` in an escaped form. As a result, there should no longer be any need to avoid the module name `llvm` in the compiler itself.
(Symbol mangling v0 avoids this problem by not using `.` in the first place, outside of the “vendor-specific suffix”.)
Fix `unreachable_pub` lint for hermit target
The build for the hermit target (`#[cfg(target_os = "hermit")]`) fails on master as of [8df89d1cb0](8df89d1cb0) (2025-02-05), due to introducing `#[warn(unreachable_pub)]` at the root in https://github.com/rust-lang/rust/pull/134286 (Enable unreachable_pub lint in core, merged 2025-01-20).
Make the relevant visibility modifiers more specific to resolve the warning.
```
$ ./x build --target x86_64-unknown-hermit
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.34s
Building stage0 library artifacts (x86_64-apple-darwin)
Finished `release` profile [optimized] target(s) in 0.15s
Building compiler artifacts (stage0 -> stage1, x86_64-apple-darwin)
Finished `release` profile [optimized] target(s) in 1.67s
Creating a sysroot for stage1 compiler (use `rustup toolchain link 'name' build/host/stage1`)
Building stage1 library artifacts {alloc, core, panic_abort, panic_unwind, proc_macro, std, sysroot, test, unwind} (x86_64-apple-darwin -> x86_64-unknown-hermit)
Compiling panic_unwind v0.0.0 (library/panic_unwind)
error: unreachable `pub` item
--> library/panic_unwind/src/hermit.rs:10:9
|
10 | pub fn __rust_abort() -> !;
| ---^^^^^^^^^^^^^^^^^^^^^^^^
| |
| help: consider restricting its visibility: `pub(crate)`
|
= help: or consider exporting it for use by other crates
= note: `-D unreachable-pub` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(unreachable_pub)]`
error: unreachable `pub` item
--> library/panic_unwind/src/hermit.rs:17:9
|
17 | pub fn __rust_abort() -> !;
| ---^^^^^^^^^^^^^^^^^^^^^^^^
| |
| help: consider restricting its visibility: `pub(crate)`
|
= help: or consider exporting it for use by other crates
error: could not compile `panic_unwind` (lib) due to 2 previous errors
Build completed unsuccessfully in 0:00:39
```
Only highlight unmatchable parameters at the definition site
Followup to #136497
This generally results more focused messages in the same vein as #99635 (see `test/ui/argument-suggestions/complex.rs`). There are still some cases (e.g. `test/ui/argument-suggestions/permuted_arguments.rs`) where it might be worth highlighting the arguments. This is mitigated by the fact that a suggestion with a suggested rearrangement is given.
r? `@compiler-errors`
Document why some "type mismatches" exist
Just something I stumbled over and thought to save myself (and maybe others) the research time when encountering it again.
Document minimum supported host tooling on macOS
In particular we support macOS 10.12 (same as for binaries produced by `rustc`) and Xcode 9.2 (the highest Xcode version that runs on macOS 10.12.6). I have this installed on a MacBook Pro from 2013 that sits below my desk, and am occasionally testing it.
I am documenting this now because it was unclear in https://github.com/rust-lang/rust/issues/136523.
(I'm not inherently against bumping these one day, but that's a separate discussion, let's at least document what we support right now).
`@rustbot` label O-macos
Pass spans around new solver
...so that when we instantiate canonical responses, we can actually have region obligations with the right span.
Within the solver itself, we still use dummy spans everywhere.
Avoid using make_direct_deprecated() in extern "ptx-kernel"
This method will be removed in the future as it produces a broken ABI that depends on cg_llvm implementation details. After this PR wasm32-unknown-unknown is the only remaining user of make_direct_deprecated().
Fixes https://github.com/rust-lang/rust/issues/117271
Blocks https://github.com/rust-lang/rust/issues/38788
