Give a message with a span on MIR validation error
It was handy to get a source+line link for rust-lang/rust#143833, even if it's just to the function and not necessarily to the statement.
r? mir
Fix `-Ctarget-feature`s getting ignored after `crt-static`
The current behaviour introduced by commit a50a3b8e31 would discard any target features specified after `crt-static` (the only member of `RUSTC_SPECIFIC_FEATURES`). This is because it returned instead of continuing processing the next feature.
I wasn't entirely sure how the regression test should look like, but this one should do. If anyone has some suggestions, I'm happy to learn, it's my first test :)
I've confirmed that the test fails without the fix on `powerpc64le-unknown-linux-musl` and `x86_64-unknown-linux-gnu`.
cc ``@RalfJung``
Allow `Rvalue::Repeat` to return true in `rvalue_creates_operand` too
The conversation in https://github.com/rust-lang/rust/pull/143502#discussion_r2189410911 made be realize how easy this is to handle, since the only possibilty is ZSTs -- everything else ends up with the destination being `LocalKind::Memory` and thus doesn't call `codegen_rvalue_operand` at all.
This gets us perilously close to a world where `rvalue_creates_operand` only ever returns true. (See rust-lang/rust#143860 for more.)
Fixes for LLVM 21
This fixes compatibility issues with LLVM 21 without performing the actual upgrade. Split out from https://github.com/rust-lang/rust/pull/143684.
This fixes three issues:
* Updates the AMDGPU data layout for address space 8.
* Makes emit-arity-indicator.rs a no_core test, so it doesn't fail on non-x86 hosts.
* Explicitly sets the exception model for wasm, as this is no longer implied by `-wasm-enable-eh`.
The conversation in 143502 made be realize how easy this is to handle, since the only possibilty is ZSTs -- everything else ends up with the destination being `LocalKind::Memory` and thus doesn't call `codegen_rvalue_operand` at all.
This gets us perilously close to a world where `rvalue_creates_operand` only ever returns true. I'll try out such a world next :)
Prepare revert of 144013
This is a possible revert for rust-lang/rust#144013 causing issue rust-lang/rust#144168 (imo p-crit) to give us time to figure out a correct fix for rust-lang/rust#144013 without pressure. Feel free to close if it's an easy fix instead: r? `@petrochenkov`
Simplify discriminant codegen for niche-encoded variants which don't wrap across an integer boundary
Inspired by rust-lang/rust#139729, this attempts to be a much-simpler and more-localized change while still making a difference. (Specifically, this does not try to solve the problem with select-sinking, leaving that to be fixed by https://github.com/llvm/llvm-project/issues/134024 -- once it gets released -- instead of in rustc's codegen.)
What this *does* improve is checking for the variant in a 3+ variant enum when that variant is the type providing the niche. Something like `if let Foo::WithBool(_) = ...` previously compiled to `ugt(add(x, -2), 2)`, which is non-trivial to think about because it's depending on the unsigned wrapping to shift the 0/1 up above 2. With this PR it compiles to just `ult(x, 2)`, which is probably what you'd have written yourself if you were doing it by hand to look for "is this byte a bool?".
That's done by leaving most of the codegen alone, but adding a couple new special cases to the `is_niche` check. The default looks at the relative discriminant, but in the common cases where there's no wraparound involved, we can just check the original value, rather than the offsetted one.
The first commit just adds some tests, so the best way to see the effect of this change is to look at the second commit and how it updates the test expectations.
Rename `emit_unless` to `emit_unless_delay`
`emit_unless` is very unintuitive and confusing. The first impression is as if it will only emit if the parameter is true, without the altnative "delay as a bug".
`emit_unless_delay` expresses two things:
1. emit unless the `delay` parameter is true
2. either *emit immediately* or *delay as bug*
r? `@compiler-errors`
Be a bit more careful around exotic cycles in in the inliner
Copied from the comment here: https://github.com/rust-lang/rust/issues/143700#issuecomment-3053810353
---
```rust
#![feature(fn_traits)]
#[inline]
pub fn a() {
FnOnce::call_once(a, ());
FnOnce::call_once(b, ());
}
#[inline]
pub fn b() {
FnOnce::call_once(b, ());
FnOnce::call_once(a, ());
}
```
This should demonstrate the issue. For ease of discussion, I'm gonna call the two fn-def types `{a}` and `{b}`.
When collecting the cyclic local callees in `mir_callgraph_cyclic` for `a`, we first check the first call terminator in `a`. We end up calling process on `<{a} as FnOnce>::call_once`, which ends up visiting `a`'s instance again. This is cyclical. However, we don't end up marking `FnOnce::call_once` as a cyclical def id because it's a foreign item. That's fine.
When visiting the second call terminator in `a`, which is `<{b} as FnOnce>::call_once`, we end up recursing into `b`. We check the first terminator, which is `<{b} as FnOnce>::call_once`, but although that is its own mini cycle, it doesn't consider itself a cycle for the purpose of this query because it doesn't involve the *root*. However, when we visit the *second* terminator in `b`, which is `<{a} as FnOnce>::call_once`, we end up **erroneously** *not* considering that call to be cyclical since we've already inserted it into our set of seen instances, and as a consequence we don't recurse into it. This means that we never collect `b` as recursive.
Do this in the flipped case too, and we end up having two functions which mututally do not consider each other to be recursive participants. This leads to a query cycle.
---
I ended up also renaming some variables so I could more clearly understand their responsibilities in this code. Let me know if the renames are not welcome.
Fixes https://github.com/rust-lang/rust/issues/143700
r? `@cjgillot`
Generalize `unsize` and `unsize_into` destinations
Just something that I noticed during other work. We do this for most such functions, so let's do it here, too.
r? ``@RalfJung``
Refactor `CrateLoader` into the `CStore`
Removes the `CrateLoader` and moves the code to `CStore`. Now, if you want to use the `CrateLoader`, you can just use `CStore`.
Should we rename `creader.rs` to `cstore.rs`?
r? ``@petrochenkov``
Fix encoding of link_section and no_mangle cross crate
Fixes https://github.com/rust-lang/rust/issues/144004
``@bjorn3`` suggested using the `codegen_fn_attrs` query but given that these attributes are not that common it's probably fine to just always encode them. I can also go for that solution if it is preferred but that would require more changes.
r? ``@jdonszelmann`` ``@fmease`` (whoever feels like it)
Show the offset, length and memory of uninit read errors
r? ``@RalfJung``
I want to improve memory dumps in general. Not sure yet how to do so best within rust diagnostics, but in a perfect world I could generate a dummy in-memory file (that contains the rendered memory dump) that we then can then provide regular rustc `Span`s to. So we'd basically report normal diagnostics for them with squiggly lines and everything.
The current behaviour introduced by commit
a50a3b8e31 would discard any
target features specified after crt-static (the only member of
RUSTC_SPECIFIC_FEATURES). This is because it returned instead of
continuing processing the next flag.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
According to
https://discourse.llvm.org/t/rfc-volatile-access-to-non-dereferenceable-memory-may-be-well-defined/86303/4,
LLVM allows volatile operations on null and handles it correctly. This
should be allowed in Rust as well, because I/O memory may be hard-coded
to address 0 in some cases, like the AVR chip ATtiny1626.
A test case that ensured a failure when passing null to volatile was
removed, since it's now valid.
Due to the addition of `maybe_is_aligned` to `ub_checks`,
`maybe_is_aligned_and_not_null` was refactored to use it.
docs: revise restrictions on volatile operations
A distinction between usage on Rust memory vs. non-Rust memory was
introduced. Documentation was reworded to explain what that means, and
make explicit that:
- No trapping can occur from volatile operations;
- On Rust memory, all safety rules must be respected;
- On Rust memory, the primary difference from regular access is that
volatile always involves a memory dereference;
- On Rust memory, the only data affected by an operation is the one
pointed to in the argument(s) of the function;
- On Rust memory, provenance follows the same rules as non-volatile
access;
- On non-Rust memory, any address known to not contain Rust memory is
valid (including 0 and usize::MAX);
- On non-Rust memory, no Rust memory may be affected (it is implicit
that any other non-Rust memory may be affected, though, even if not
referenced by the pointer). This should be relevant when, for example,
reading register A causes a flag to change in register B, or writing
to A causes B to change in some way. Everything affected mustn't be
inside an allocation.
- On non-Rust memory, provenance is irrelevant and a pointer with none
can be used in a valid way.
fix: don't lint null as UB for volatile
Also remove a now-unneeded `allow` line.
fix: additional wording nits
Split-up stability_index query
This PR aims to move deprecation and stability processing away from the monolithic `stability_index` query, and directly implement `lookup_{deprecation,stability,body_stability,const_stability}` queries.
The basic idea is to:
- move per-attribute sanity checks into `check_attr.rs`;
- move attribute compatibility checks into the `MissingStabilityAnnotations` visitor;
- progressively dismantle the `Annotator` visitor and the `stability_index` query.
The first commit contains functional change, and now warns when `#[automatically_derived]` is applied on a non-trait impl block. The other commits should not change visible behaviour.
Perf in https://github.com/rust-lang/rust/pull/143845#issuecomment-3066308630 shows small but consistent improvement, except for unused-warnings case. That case being a stress test, I'm leaning towards accepting the regression.
This PR changes `check_attr`, so has a high conflict rate on that file. This should not cause issues for review.
resolve: Make disambiguators for underscore bindings module-local
Disambiguators attached to underscore name bindings (like `const _: u8 = something;`) do not need to be globally unique, they just need to be unique inside the module in which they live, because the bindings in a module are basically kept as `Map<BindingKey, SomeData>`.
Also, the specific values of the disambiguators are not important, so a glob import of `const _` may have a different disambiguator than the original `const _` itself.
So in this PR the disambiguator is just set to the current number of bindings in the module.
This removes one more piece of global mutable state from resolver and unblocks https://github.com/rust-lang/rust/pull/143884.
Use $crate in macros for rustc_public (aka stable_mir)
This makes `#[macro_use] extern crate rustc_public` unnecessary (which brings all of `rustc_public`'s macros into scope for the entire crate); instead, now you can simply use `rustc_public::run!()`.
Make slice comparisons const
This needed a fix for `derive_const`, too, as it wasn't usable in libcore anymore as trait impls need const stability attributes. I think we can't use the same system as normal trait impls while `const_trait_impl` is still unstable.
r? ```@fee1-dead```
cc rust-lang/rust#143800
Having multiple relaxed bounds like `?Sized + ?Iterator` is actually *fine*.
We actually want to reject *duplicate* relaxed bounds like `?Sized + ?Sized`
because these most certainly represent a user error.
Note that this doesn't mean that we accept more code because a bound like
`?Iterator` is still invalid as it's not relaxing a *default* trait and
the only way to define / use more default bounds is under the experimental
and internal feature `more_maybe_bounds` plus `lang_items` plus unstable
flag `-Zexperimental-default-bounds` (historical context: for the longest
time, bounds like `?Iterator` were actually allowed and lead to a hard
warning).
Ultimately, this simply *reframes* the diagnostic. The scope of
`more_maybe_bounds` / `-Zexperimental-default-bounds` remains unchanged
as well.
* The phrasing "only does something for" made sense back when this
diagnostic was a (hard) warning. Now however, it's simply a hard
error and thus completely rules out "doing something".
* The primary message was way too long
* The new wording more closely mirrors the wording we use for applying
other bound modifiers (like `const` and `async`) to incompatible
traits.
* "all other traits are not bound by default" is no longer accurate
under Sized Hierarchy. E.g., traits and assoc tys are (currently)
bounded by `MetaSized` by default but can't be relaxed using
`?MetaSized` (instead, you relax it by adding `PointeeSized`).
* I've decided against adding any diagnositic notes or suggestions
for now like "trait `Trait` can't be relaxed as it's not bound by
default" which would be incorrect for `MetaSized` and assoc tys
as mentioned above) or "consider changing `?MetaSized` to
`PointeeSized`" as the Sized Hierarchy impl is still WIP)
