Reorder stack spills so that constants come later.
Currently constants are "pulled forward" and have their stack spills emitted first. This confuses LLVM as to where to place breakpoints at function entry, and results in argument values being wrong in the debugger. It's straightforward to avoid emitting the stack spills for constants until arguments/etc have been introduced in debug_introduce_locals, so do that.
Example LLVM IR (irrelevant IR elided):
Before:
```
define internal void `@_ZN11rust_1289457binding17h2c78f956ba4bd2c3E(i64` %a, i64 %b, double %c) unnamed_addr #0 !dbg !178 { start:
%c.dbg.spill = alloca [8 x i8], align 8
%b.dbg.spill = alloca [8 x i8], align 8
%a.dbg.spill = alloca [8 x i8], align 8
%x.dbg.spill = alloca [4 x i8], align 4
store i32 0, ptr %x.dbg.spill, align 4, !dbg !192 ; LLVM places breakpoint here.
#dbg_declare(ptr %x.dbg.spill, !190, !DIExpression(), !192)
store i64 %a, ptr %a.dbg.spill, align 8
#dbg_declare(ptr %a.dbg.spill, !187, !DIExpression(), !193)
store i64 %b, ptr %b.dbg.spill, align 8
#dbg_declare(ptr %b.dbg.spill, !188, !DIExpression(), !194)
store double %c, ptr %c.dbg.spill, align 8
#dbg_declare(ptr %c.dbg.spill, !189, !DIExpression(), !195)
ret void, !dbg !196
}
```
After:
```
define internal void `@_ZN11rust_1289457binding17h2c78f956ba4bd2c3E(i64` %a, i64 %b, double %c) unnamed_addr #0 !dbg !178 { start:
%x.dbg.spill = alloca [4 x i8], align 4
%c.dbg.spill = alloca [8 x i8], align 8
%b.dbg.spill = alloca [8 x i8], align 8
%a.dbg.spill = alloca [8 x i8], align 8
store i64 %a, ptr %a.dbg.spill, align 8
#dbg_declare(ptr %a.dbg.spill, !187, !DIExpression(), !192)
store i64 %b, ptr %b.dbg.spill, align 8
#dbg_declare(ptr %b.dbg.spill, !188, !DIExpression(), !193)
store double %c, ptr %c.dbg.spill, align 8
#dbg_declare(ptr %c.dbg.spill, !189, !DIExpression(), !194)
store i32 0, ptr %x.dbg.spill, align 4, !dbg !195 ; LLVM places breakpoint here.
#dbg_declare(ptr %x.dbg.spill, !190, !DIExpression(), !195)
ret void, !dbg !196
}
```
Note in particular the position of the "LLVM places breakpoint here" comment relative to the stack spills for the function arguments. LLVM assumes that the first instruction with with a debug location is the end of the prologue. As LLVM does not currently offer front ends any direct control over the placement of the prologue end reordering the IR is the only mechanism available to fix argument values at function entry in the presence of MIR optimizations like SingleUseConsts. Fixes#128945
r? `@michaelwoerister`
Collect relevant item bounds from trait clauses for nested rigid projections
Rust currently considers trait where-clauses that bound the trait's *own* associated types to act like an item bound:
```rust
trait Foo where Self::Assoc: Bar { type Assoc; }
// acts as if:
trait Foo { type Assoc: Bar; }
```
### Background
This behavior has existed since essentially forever (i.e. before Rust 1.0), since we originally started out by literally looking at the where clauses written on the trait when assembling `SelectionCandidate::ProjectionCandidate` for projections. However, looking at the predicates of the associated type themselves was not sound, since it was unclear which predicates were *assumed* and which predicates were *implied*, and therefore this was reworked in #72788 (which added a query for the predicates we consider for `ProjectionCandidate`s), and then finally item bounds and predicates were split in #73905.
### Problem 1: GATs don't uplift bounds correctly
All the while, we've still had logic to uplift associated type bounds from a trait's where clauses. However, with the introduction of GATs, this logic was never really generalized correctly for them, since we were using simple equality to test if the self type of a trait where clause is a projection. This leads to shortcomings, such as:
```rust
trait Foo
where
for<'a> Self::Gat<'a>: Debug,
{
type Gat<'a>;
}
fn test<T: Foo>(x: T::Gat<'static>) {
//~^ ERROR `<T as Foo>::Gat<'a>` doesn't implement `Debug`
println!("{:?}", x);
}
```
### Problem 2: Nested associated type bounds are not uplifted
We also don't attempt to uplift bounds on nested associated types, something that we couldn't really support until #120584. This can be demonstrated best with an example:
```rust
trait A
where Self::Assoc: B,
where <Self::Assoc as B>::Assoc2: C,
{
type Assoc; // <~ The compiler *should* treat this like it has an item bound `B<Assoc2: C>`.
}
trait B { type Assoc2; }
trait C {}
fn is_c<T: C>() {}
fn test<T: A>() {
is_c::<<Self::Assoc as B>::Assoc2>();
//~^ ERROR the trait bound `<<T as A>::Assoc as B>::Assoc2: C` is not satisfied
}
```
Why does this matter?
Well, generalizing this behavior bridges a gap between the associated type bounds (ATB) feature and trait where clauses. Currently, all bounds that can be stably written on associated types can also be expressed as where clauses on traits; however, with the stabilization of ATB, there are now bounds that can't be desugared in the same way. This fixes that.
## How does this PR fix things?
First, when scraping item bounds from the trait's where clauses, given a trait predicate, we'll loop of the self type of the predicate as long as it's a projection. If we find a projection whose trait ref matches, we'll uplift the bound. This allows us to uplift, for example `<Self as Trait>::Assoc: Bound` (pre-existing), but also `<<Self as Trait>::Assoc as Iterator>::Item: Bound` (new).
If that projection is a GAT, we will check if all of the GAT's *own* args are all unique late-bound vars. We then map the late-bound vars to early-bound vars from the GAT -- this allows us to uplift `for<'a, 'b> Self::Assoc<'a, 'b>: Trait` into an item bound, but we will leave `for<'a> Self::Assoc<'a, 'a>: Trait` and `Self::Assoc<'static, 'static>: Trait` alone.
### Okay, but does this *really* matter?
I consider this to be an improvement of the status quo because it makes GATs a bit less magical, and makes rigid projections a bit more expressive.
Ban combination of GCE and new solver
These do not work together. I don't want anyone to have the impression that they do.
I reused the conflicting features diagnostic but I guess I could make it more tailored to the new solver? OTOH I don't really about the presentation of diagnostics here; these are nightly features after all.
r? `@BoxyUwU` thoughts on this?
Fix: ices on virtual-function-elimination about principal trait
Extract `load_vtable` function to ensure the `virtual_function_elimination` option is always checked.
It's okay not to use `llvm.type.checked.load` to load the vtable if there is no principal trait.
Fixes#123955Fixes#124092
rustdoc: inherit parent's stability where applicable
It is currently not possible for a re-export to have a different stability (https://github.com/rust-lang/rust/issues/30827). Therefore the standard library uses a hack when moving items like `std::error::Error` or `std::net::IpAddr` into `core` by marking the containing module (`core::error` / `core::net`) as unstable or stable in a later version than the items the module contains.
Previously, rustdoc would always show the *stability as declared* for an item rather than the *stability as publicly reachable* (i.e. the features required to actually access the item), which could be confusing when viewing the docs. This PR changes it so that we show the stability of the first unstable parent or the most recently stabilized parent instead, to hopefully make things less confusing.
fixes https://github.com/rust-lang/rust/issues/130765
screenshots:
 
Separate collection of crate-local inherent impls from error tracking
#119895 changed the return type of the `crate_inherent_impls` query from `CrateInherentImpls` to `Result<CrateInherentImpls, ErrorGuaranteed>` to avoid needing to use the non-parallel-friendly `track_errors()` to track if an error was reporting from within the query... This was mostly fine until #121113, which stopped halting compilation when we hit an `Err(ErrorGuaranteed)` in the `crate_inherent_impls` query.
Thus we proceed onwards to typeck, and since a return type of `Result<CrateInherentImpls, ErrorGuaranteed>` means that the query can *either* return one of "the list inherent impls" or "error has been reported", later on when we want to assemble method or associated item candidates for inherent impls, we were just treating any `Err(ErrorGuaranteed)` return value as if Rust had no inherent impls defined anywhere at all! This leads to basically every inherent method call failing with an error, lol, which was reported in #127798.
This PR changes the `crate_inherent_impls` query to return `(CrateInherentImpls, Result<(), ErrorGuaranteed>)`, i.e. returning the inherent impls collected *and* whether an error was reported in the query itself. It firewalls the latter part of that query into a new `crate_inherent_impls_validity_check` just for the `ensure()` call.
This fixes#127798.
Improve assembly test for CMSE ABIs
Tracking issues: #75835#81391
This ensures the code-gen for these ABIs does not change silently. There is a small chance that this code-gen might change, however even GCC (https://godbolt.org/z/16arxab5x and https://godbolt.org/z/16arxab5x) generates almost the same assembly for these ABIs. I hope the notes in the comments should help fix the tests if it ever breaks.
Fix cargo staging for run-make tests
Follow-up to https://github.com/rust-lang/rust/pull/130642#issuecomment-2366891866 to make sure that when
```
$ COMPILETEST_FORCE_STAGE0=1 ./x test run-make --stage 0
```
is used, bootstrap cargo is used in order to avoid building stage 1 rustc. Note that run-make tests are usually not written with `--stage 0` in mind and some tests may rely on stage1 rustc (nightly) behavior, and it is expected that some tests will fail under this invocation.
This PR also fixes `tool::Cargo` staging in compiletest when preparing for `run-make` test mode, by chopping off a stage from the `compiler` passed to `tool::Cargo` such that when the user invokes with stage `N`
```
./x test run-make --stage N
```
the `run-make` test suite will be tested against the cargo built by stage `N` compiler. Let's take `N=1`, i.e. `--stage 1`, without chopping off a stage, previously `./x test run-make --stage 1` will cause stage 1 rustc + std to be built, then stage 2 rustc, and cargo will be produced by the stage 2 rustc, which is clearly not what we want. By chopping off a stage, it means that cargo will be produced by the stage 1 rustc.
cc #119946, #59864.
See discussions regarding the tool staging at https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/.E2.9C.94.20stage1.20run-make.20tests.20now.20need.20stage2.20rustc.20built.20for.20c.2E.2E.2E.
This changes the remaining span for the cast, because the new `Cast`
category has a higher priority (lower `Ord`) than the old `Coercion`
category, so we no longer report the region error for the "unsizing"
coercion from `*const Trait` to itself.
Revert "Apply EarlyOtherwiseBranch to scalar value #129047"
This reverts PR #129047, commit a772336fb3, reversing changes made to 702987f75b.
cc `@DianQK` and `@cjgillot` as the PR author and reviewer of #129047 respectively.
It seems [Apply EarlyOtherwiseBranch to scalar value #129047](https://github.com/rust-lang/rust/pull/129047) may have lead to several nightly regressions:
- https://github.com/rust-lang/rust/issues/130769
- https://github.com/rust-lang/rust/issues/130774
- https://github.com/rust-lang/rust/issues/130771
Example test that would ICE with changes in #129047 (this test is included in this PR):
```rs
//@ compile-flags: -C opt-level=3
//@ check-pass
use std::task::Poll;
pub fn poll(val: Poll<Result<Option<Vec<u8>>, u8>>) {
match val {
Poll::Ready(Ok(Some(_trailers))) => {}
Poll::Ready(Err(_err)) => {}
Poll::Ready(Ok(None)) => {}
Poll::Pending => {}
}
}
```
Since this is a mir-opt ICE that seems to quite easy to trigger with real-world crates being affected, let's revert for now and reland the mir-opt after these are fixed.
Revert "Add recursion limit to FFI safety lint"
It's not necessarily clear if warning when we hit the recursion limit is the right thing to do, first of all.
**More importantly**, this PR was implemented incorrectly in the first place; it was not decrementing the recursion limit when stepping out of a type, so it would trigger when a ctype has more than RECURSION_LIMIT fields *anywhere* in the type's set of recursively reachable fields.
Reverts #130598Reopens#130310Fixes#130757
Rework `non_local_definitions` lint to only use a syntactic heuristic
This PR reworks the `non_local_definitions` lint to only use a syntactic heuristic, i.e. not use a type-system logic for whenever an `impl` is local or not.
Instead the new logic wanted by T-lang in https://github.com/rust-lang/rust/issues/126768#issuecomment-2192634762, which is to consider every paths in `Self` and `Trait` and to no longer use the type-system inference trick.
`@rustbot` labels +L-non_local_definitions
Fixes#126768
add unqualified_local_imports lint
This lint helps deal with https://github.com/rust-lang/rustfmt/issues/4709 by having the compiler detect imports of local items that are not syntactically distinguishable from imports from other cates. Making them syntactically distinguishable ensures rustfmt can consistently apply the desired import grouping.
Fix `break_last_token`.
It currently doesn't handle the three-char tokens `>>=` and `<<=` correctly. These can be broken twice, resulting in three individual tokens. This is a latent bug that currently doesn't cause any problems, but does cause problems for #124141, because that PR increases the usage of lazy token streams.
r? `@petrochenkov`
