Rollup of 5 pull requests
Successful merges:
- #134679 (Windows: remove readonly files)
- #136213 (Allow Rust to use a number of libc filesystem calls)
- #136530 (Implement `x perf` directly in bootstrap)
- #136601 (Detect (non-raw) borrows of null ZST pointers in CheckNull)
- #136659 (Pick the max DWARF version when LTO'ing modules with different versions )
r? `@ghost`
`@rustbot` modify labels: rollup
Small resolve refactor
I was looking into how resolve works in order to find a good way for clippy to shorten paths in messages and suggestions, and found a needless `.collect()` and a recursive function that could be written as a loop, also removed a panicky code path.
transmutability: fix ICE when passing wrong ADT to ASSUME
- Remove an incorrect assert that the `ASSUME` parameter has the type `Assume` and delay a bug instead.
- Since we checked the type of `ASSUME` is `Assume` (an ADT), its valtree must be a branch, so we can just unwrap it.
r? ```@jswrenn```
compiler: mostly-finish `rustc_abi` updates
This almost-finishes all the updates in the compiler to use `rustc_abi` and removes some of the reexports of `rustc_abi` items in `rustc_target` that were previously available.
r? ```@compiler-errors```
Pick the max DWARF version when LTO'ing modules with different versions
Currently, when rustc compiles code with `-Clto` enabled that was built
with different choices for `-Zdwarf-version`, a warning will be
reported. It's very easy to observe this by compiling most anything (eg,
"hello world") and specifying `-Clto -Zdwarf-version=5` since the
standard library is distributed with `-Zdwarf-version=4`.
This behavior isn't actually useful for a few reasons:
- From observation, LLVM chooses to pick the highest DWARF version
anyway after issuing the warning.
- Clang specifies that in this case, the max version should be picked
without a warning and as a general principle, we want to support
x-lang LTO with Clang which implies using the same module flag merge
behaviors.
- Debuggers need to be able to handle a variety of versions within the
same debugging session as you can easily have some parts of a binary
(or some dynamic libraries within an application) all compiled with
different DWARF versions.
This commit changes the module flag merge behavior to match Clang and
use the highest version of DWARF. It also adds a test to ensure this
behavior is respected in the case of two crates being LTO'd together and
adds a test to ensure no warning is printed.
Fixes#130041 which fails due to these warnings being printed
cc #103057
Make empty-line-after an early clippy lint
r? ```@y21```
95% a refiling of https://github.com/rust-lang/rust-clippy/pull/13658 but for correctness it needed 2 extra methods in `rust_lint` which made it much easier to apply on `rust-lang/rust` than `rust-lang/rust-clippy`.
Commits have been thoroughly reviewed on `rust-lang/clippy already`. The last two review comments there (about using `Option` and popping for assoc items have been applied here.
Generate correct terminate block under Wasm EH
This fixes failing LLVM assertions during insnsel.
Improves #135665.
r? bjorn3
^ you reviewed the PR bringing Wasm EH in, I assume this is within your area of expertise?
Subtree sync for rustc_codegen_cranelift
The main highlights this time are a Cranelift update and a fix for a warning that the x87 feature is not enabled.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler<!-- homu-ignore:start -->
Currently, when rustc compiles code with `-Clto` enabled that was built
with different choices for `-Zdwarf-version`, a warning will be
reported. It's very easy to observe this by compiling most anything (eg,
"hello world") and specifying `-Clto -Zdwarf-version=5` since the
standard library is distributed with `-Zdwarf-version=4`.
This behavior isn't actually useful for a few reasons:
- from observation, LLVM chooses to pick the highest DWARF version
anyway after issuing the warning
- Clang specifies that in this case, the max version should be picked
without a warning and as a general principle, we want to support
x-lang LTO with Clang which implies using the same module flag merge
behaviors
- Debuggers need to be able to handle a variety of versions withing the
same debugging session as you can easily have some parts of a binary
(or some dynamic libraries within an application) all compiled with
different DWARF versions
This commit changes the module flag merge behavior to match Clang and
use the highest version of DWARF. It also adds a test to ensure this
behavior is respected in the case of two crates being LTO'd together and
updates the test added in the previous commit to ensure no warning is
printed.
Rollup of 6 pull requests
Successful merges:
- #136640 (Debuginfo for function ZSTs should have alignment of 8 bits, not 1 bit)
- #136648 (Add a missing `//@ needs-symlink` to `tests/run-make/libs-through-symlinks`)
- #136651 (Label mismatched parameters at the def site for foreign functions)
- #136691 (Remove Linkage::Private and Linkage::Appending)
- #136692 (add module level doc for bootstrap:utils:exec)
- #136700 (i686-unknown-hurd-gnu: bump baseline CPU to Pentium 4)
r? `@ghost`
`@rustbot` modify labels: rollup
Label mismatched parameters at the def site for foreign functions
Nice and simple. Adds parameter marking for the only missing definition type.
r? ``@compiler-errors``
Debuginfo for function ZSTs should have alignment of 8 bits, not 1 bit
In #116096, function ZSTs were made to have debuginfo that gives them an alignment of “1”. But because alignment in LLVM debuginfo is denoted in *bits*, not bytes, this resulted in an alignment specification of 1 bit instead of 1 byte.
I don't know whether this has any practical consequences, but I noticed that a test started failing when I accidentally fixed the mistake while working on #136632, so I extracted the fix (and the test adjustment) to this PR.
Rollup of 7 pull requests
Successful merges:
- #135179 (Make sure to use `Receiver` trait when extracting object method candidate)
- #136554 (Add `opt_alias_variances` and use it in outlives code)
- #136556 ([AIX] Update tests/ui/wait-forked-but-failed-child.rs to accomodate exiting and idle processes.)
- #136589 (Enable "jump to def" feature on rustc docs)
- #136615 (sys: net: Add UEFI stubs)
- #136635 (Remove outdated `base_port` calculation in std net test)
- #136682 (Move two windows process tests to tests/ui)
r? `@ghost`
`@rustbot` modify labels: rollup
Enable "jump to def" feature on rustc docs
This PR enables the rustdoc "jump to def" feature which is visible on the source code pages.
r? ``@oli-obk``
Add `opt_alias_variances` and use it in outlives code
...so to fix some subtle outlives bugs with precise capturing in traits, and eventually make it easier to compute variances for "forced unconstrained" trait lifetimes.
r? lcnr
Make sure to use `Receiver` trait when extracting object method candidate
In method confirmation, the `extract_existential_trait_ref` function re-extracts the object type by derefing until it reaches an object. If we're assembling methods via the `Receiver` trait, make sure we re-do our work also using the receiver trait.
Fixes#135155
cc ``@adetaylor``
Remove dead code from rustc_codegen_llvm and the LLVM wrapper
First step to clean up the LLVM wrapper: remove existing dead code.
Split out of #135502
r? ``@Zalathar``
Pattern Migration 2024: try to suggest eliding redundant binding modifiers
This is based on #136475. Only the last commit is new.
This is a simpler, more restrictive alternative to #136496, meant to partially address #136047. If a pattern can be migrated to Rust 2024 solely by removing redundant binding modifiers, this will make that suggestion; otherwise, it uses the old suggestion of making the pattern fully explicit.
Relevant tracking issue: #131414
``@rustbot`` label A-diagnostics A-patterns A-edition-2024
r? ``@Nadrieril``
MIR validation: add comment explaining the limitations of CfgChecker
I hope this right but I am not sure.^^
Cc `@compiler-errors` `@lcnr` `@cjgillot` `@oli-obk`
compiler: Clean up weird `rustc_abi` reexports
Just general cleanup in `rustc_target` and `rustc_abi`. I was originally going to make a PR with a larger change that also fixed the last few crates and in doing so removed some clutter from `rustc_abi`, but wound up slightly stuck on it, then figured out how to fix it, and then got distracted by other things... so now I'm trying to figure out what I had figured out earlier.
fix tail call checks wrt `#[track_caller]`
Only check the caller + disallow caller having the attribute.
fixes#134336
r? `@compiler-errors`
<sub>apparently there were no tests for `#[track_caller]` before... ooops</sub>
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
this commit makes `deref_into_dyn_supertrait` lint allow-by-default,
removes future incompatibility (we finally live in a broken world), and
changes the wording in the documentation.
previously documentation erroneously said that it lints against *usage*
of the deref impl, while it actually (since 104742) lints on the impl
itself (oooops, my oversight, should have updated it 2+ years ago...)
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
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
General housekeeping:
- Use less reexports from its rustc_target era
- Unify some imports as a result
- Split the Reg(ister) types into their own files
Generally moving stuff around because it makes the crate more consistent.
rustc_target has had a lot of weird reexports for various reasons, but
now we're at a point where we can actually start reducing their number.
We remove weird shadowing-dependent behavior and import directly from
rustc_abi instead of doing weird renaming imports.
This is only incremental progress and does not entirely fix the crate.
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”.)
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.
