feat: show what lint was overruled
We can't `#[allow]` a whole lint group if any of its members is forbidden, but the offending member is not currently shown if it was forbidden from the command line.
Before/after:
```diff
$ rustc -F dead_code - <<< '#![allow(unused)]'
error[E0453]: allow(unused) incompatible with previous forbid
--> <anon>:1:10
|
1 | #![allow(unused)]
| ^^^^^^ overruled by previous forbid
|
- = note: `forbid` lint level was set on command line
+ = note: `forbid` lint level was set on command line (`-F dead_code`)
error: aborting due to 1 previous error
```
@rustbot label +A-diagnostics +A-lints +D-terse
Pass alignments through the shim as `Alignment` (not `usize`)
We're using `Layout` on both sides, so might as well skip the transmutes back and forth to `usize`.
The mir-opt test shows that doing so allows simplifying the boxed-slice drop slightly, for example.
Add regression test for #141738Closesrust-lang/rust#141738
- Add a regression test for rust-lang/rust#141738
- Using a struct constructor (`DefKind::Ctor(Struct, Const)`) as an array repeat count with `#![feature(min_generic_const_args)]` used to ICE in const alias normalization
- Fixed by rust-lang/rust#150704, which added const constructor support for mGCA. This test covers the **error path** (struct ctor where `usize` is expected), which was not covered by the tests in rust-lang/rust#150704
Improve write! and writeln! error when called without destination
Fixesrust-lang/rust#152493
Adds catch-all arms to `write!` and `writeln!` macros so that calling them without a destination (e.g., `write!("S")` instead of `write!(f, "S")`) gives a clear error instead of the cryptic "unexpected end of macro invocation" pointing at macro internals.
r? @estebank
diagnostics: add note when param-env shadows global impl
This PR adds a diagnostics note when param-env shadows global impl as discussed in https://github.com/rust-lang/rust/issues/149910
It adds a note explaining that the definition is hidden by the generic bound.
r?lcnr
tests: adapt align-offset.rs for InstCombine improvements in LLVM 23
Upstream [has improved InstCombine](8d2078332c) so that it can shrink added constants using known zeroes, which caused a little bit of change in this test. As far as I can tell either output is fine, so we just accept both.
@rustbot label: +llvm-main
UnsafePinned: implement opsem effects of UnsafeUnpin
This implements the next step for https://github.com/rust-lang/rust/issues/125735: actually making `UnsafePinned` have special opsem effects by suppressing the `noalias` *even if* the type is wrapped in an `Unpin` wrapper.
For backwards compatibility we also still keep the `Unpin` hack, i.e. a type must be both `Unpin` and `UnsafeUnpin` to get `noalias`.
Optimize indexing slices and strs with inclusive ranges
Instead of separately checking for `end == usize::MAX` and `end + 1 > slice.len()`, we can check for `end >= slice.len()`. Also consolidate all the str indexing related panic functions into a single function which reports the correct error depending on the arguments, as the slice indexing code already does.
The downside of all this is that the panic message is slightly less specific when trying to index with `[..=usize::MAX]`: instead of saying "attempted to index str up to maximum usize" it just says "end byte index {end} out of bounds". But this is a rare enough case that I think it is acceptable
Using a struct constructor (DefKind::Ctor(Struct, Const)) as an array
repeat count with `#![feature(min_generic_const_args)]` used to trigger
an ICE in const alias normalization. Add a regression test to ensure
the compiler produces a proper type error instead of panicking.
Don't ICE on layout error in vtable computation
Fixesrust-lang/rust#152030.
Note: I'm including a more general testcase that doesn't use the feature in the original report, but only reproduces with debuginfo disabled. Does it make sense to also include the original testcase?
Make operational semantics of pattern matching independent of crate and module
The question of "when does matching an enum against a pattern of one of its variants read its discriminant" is currently an underspecified part of the language, causing weird behavior around borrowck, drop order, and UB.
Of course, in the common cases, the discriminant must be read to distinguish the variant of the enum, but currently the following exceptions are implemented:
1. If the enum has only one variant, we currently skip the discriminant read.
- This has the advantage that single-variant enums behave the same way as structs in this regard.
- However, it means that if the discriminant exists in the layout, we can't say that this discriminant being invalid is UB. This makes me particularly uneasy in its interactions with niches – consider the following example ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=5904a6155cbdd39af4a2e7b1d32a9b1a)), where miri currently doesn't detect any UB (because the semantics don't specify any):
<details><summary>Example 1</summary>
```rust
#![allow(dead_code)]
use core::mem::{size_of, transmute};
#[repr(u8)]
enum Inner {
X(u8),
}
enum Outer {
A(Inner),
B(u8),
}
fn f(x: &Inner) {
match x {
Inner::X(v) => {
println!("{v}");
}
}
}
fn main() {
assert_eq!(size_of::<Inner>(), 2);
assert_eq!(size_of::<Outer>(), 2);
let x = Outer::B(42);
let y = &x;
f(unsafe { transmute(y) });
}
```
</details>
2. For the purpose of the above, enums with marked with `#[non_exhaustive]` are always considered to have multiple variants when observed from foreign crates, but the actual number of variants is considered in the current crate.
- This means that whether code has UB can depend on which crate it is in: https://github.com/rust-lang/rust/issues/147722
- In another case of `#[non_exhaustive]` affecting the runtime semantics, its presence or absence can change what gets captured by a closure, and by extension, the drop order: https://github.com/rust-lang/rust/issues/147722#issuecomment-3674554872
- Also at the above link, there is an example where removing `#[non_exhaustive]` can cause borrowck to suddenly start failing in another crate.
3. Moreover, we currently make a more specific check: we only read the discriminant if there is more than one *inhabited* variant in the enum.
- This means that the semantics can differ between `foo<!>`, and a copy of `foo` where `T` was manually replaced with `!`: rust-lang/rust#146803
- Moreover, due to the privacy rules for inhabitedness, it means that the semantics of code can depend on the *module* in which it is located.
- Additionally, this inhabitedness rule is even uglier due to the fact that closure capture analysis needs to happen before we can determine whether types are uninhabited, which means that whether the discriminant read happens has a different answer specifically for capture analysis.
- For the two above points, see the following example ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=a07d8a3ec0b31953942e96e2130476d9)):
<details><summary>Example 2</summary>
```rust
#![allow(unused)]
mod foo {
enum Never {}
struct PrivatelyUninhabited(Never);
pub enum A {
V(String, String),
Y(PrivatelyUninhabited),
}
fn works(mut x: A) {
let a = match x {
A::V(ref mut a, _) => a,
_ => unreachable!(),
};
let b = match x {
A::V(_, ref mut b) => b,
_ => unreachable!(),
};
a.len(); b.len();
}
fn fails(mut x: A) {
let mut f = || match x {
A::V(ref mut a, _) => (),
_ => unreachable!(),
};
let mut g = || match x {
A::V(_, ref mut b) => (),
_ => unreachable!(),
};
f(); g();
}
}
use foo::A;
fn fails(mut x: A) {
let a = match x {
A::V(ref mut a, _) => a,
_ => unreachable!(),
};
let b = match x {
A::V(_, ref mut b) => b,
_ => unreachable!(),
};
a.len(); b.len();
}
fn fails2(mut x: A) {
let mut f = || match x {
A::V(ref mut a, _) => (),
_ => unreachable!(),
};
let mut g = || match x {
A::V(_, ref mut b) => (),
_ => unreachable!(),
};
f(); g();
}
```
</details>
In light of the above, and following the discussion at rust-lang/rust#138961 and rust-lang/rust#147722, this PR ~~makes it so that, operationally, matching on an enum *always* reads its discriminant.~~ introduces the following changes to this behavior:
- matching on a `#[non_exhaustive]` enum will always introduce a discriminant read, regardless of whether the enum is from an external crate
- uninhabited variants now count just like normal ones, and don't get skipped in the checks
As per the discussion below, the resolution for point (1) above is that it should land as part of a separate PR, so that the subtler decision can be more carefully considered.
Note that this is a breaking change, due to the aforementioned changes in borrow checking behavior, new UB (or at least UB newly detected by miri), as well as drop order around closure captures. However, it seems to me that the combination of this PR with rust-lang/rust#138961 should have smaller real-world impact than rust-lang/rust#138961 by itself.
Fixesrust-lang/rust#142394Fixesrust-lang/rust#146590Fixesrust-lang/rust#146803 (though already marked as duplicate)
Fixes parts of rust-lang/rust#147722Fixesrust-lang/miri#4778
r? @Nadrieril @RalfJung
@rustbot label +A-closures +A-patterns +T-opsem +T-lang
We're using `Layout` on both sides, so might as well skip the transmutes back and forth to `usize`.
The mir-opt test shows that doing so allows simplifying the boxed-slice drop slightly, for example.
A couple of tiny polonius things
Here's a couple of tiny things I had ready to go @jackh726
- a tiny cleanup to avoid round-tripping through `Location`s to check for liveness, since we're already working with points
- while I was there, I fixed the doc which wasn't showing up properly (maybe a rustdoc or bootstrap bug when we build locally or during dist, either way, both don't show up correctly linked most of the time) for `PointIndex`es.
- and in the second commit slightly expand test coverage with [an example](https://internals.rust-lang.org/t/get-mut-map-back-from-entry-api/24003) that would have needed stdlib changes (cc author @Darksonn for visibility here)
More soon.
r? @jackh726
improve associated-type suggestions from bounds
Should address invalid suggestions I could come up with, but the suggestion is too hand-crafted and invalid patterns may exist.
r? @estebank
Fix https://github.com/rust-lang/rust/issues/73321
Feed `ErrorGuaranteed` from late lifetime resolution errors through to bound variable resolution
If late lifetime resolution fails for whatever reason, forward to RBV the guarantee that an error was emitted - thereby eliminating the need for a "hack" to suppress subsequent/superfluous error diagnostics.
Fixesrust-lang/rust#152014
r? fmease
rustdoc: sort stable items first
Finally tackling this again now that the search system refactor is done. The tests and the general approach were taken from the original PR.
If late lifetime resolution fails for whatever reason, forward to RBV
the guarantee that an error was emitted - thereby eliminating the need
for a "hack" to suppress subsequent/superfluous error diagnostics.
Remove `deprecated_safe` and its corresponding feature gate
This unimplements the feature gate for tracking issue https://github.com/rust-lang/rust/issues/94978
The author of that tracking issue and the MCP seem to no longer exist
Afaik we can just do this, but let me know if I'm wrong
Because this feature has been idle for 3+ years, and it is in the way to finish the attribute refactoring (https://github.com/rust-lang/rust/issues/131229#issuecomment-2971351163)
When someone wants to do work on it the feature gate can be re-added
r? @jdonszelmann
