Improve runtest revision redundant cfg check
While attempting to ingest https://github.com/rust-lang/rust/pull/148034 via https://github.com/ferrocene/ferrocene/pull/2172 we noticed a test failure, as we add some `compile_flags` to tests.
We saw a failure looking like this:
```
Testing stage1 with compiletest suite=mir-opt mode=mir-opt (x86_64-unknown-linux-gnu)
running 2 tests
2026-02-20T20:21:28.846102Z ERROR compiletest::runtest: redundant cfg argument `copy` is already created by the revision
[mir-opt] tests/mir-opt/pre-codegen/copy_and_clone.rs#COPY ... F
.
```
While my Rust checkout passed:
```
Testing stage1 with compiletest suite=mir-opt mode=mir-opt (x86_64-unknown-linux-gnu)
running 2 tests
..
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 381 filtered out; finished in 107.10ms
```
This caused me to add some debugging statements.
Ferrocene:
```
2026-02-20T21:05:39.808427Z ERROR compiletest::runtest: "copy": does ["--edition=2015", "--cfg=copy"] contain `"--cfg=copy"` or `["--cfg", "copy"]`? true
2026-02-20T21:05:39.808427Z ERROR compiletest::runtest: "clone": does ["--edition=2015"] contain `"--cfg=clone"` or `["--cfg", "clone"]`? false
2026-02-20T21:05:39.808435Z ERROR compiletest::runtest: redundant cfg argument `copy` is already created by the revision
```
Rust:
```
2026-02-20T21:04:18.493158Z ERROR compiletest::runtest: "copy": does ["--cfg=copy"] contain `"--cfg=copy"` or `["--cfg", "copy"]`? false
2026-02-20T21:04:18.493158Z ERROR compiletest::runtest: "clone": does [] contain `"--cfg=clone"` or `["--cfg", "clone"]`? false
```
I noticed while reviewing the related functionality that there is a call to `.windows(2)` in the relevant check for redundant cfgs:
https://github.com/rust-lang/rust/blob/0376d43d443cba463a0b6a6ec9140ea17d7b7130/src/tools/compiletest/src/runtest.rs#L507-L511
Noting:
https://github.com/rust-lang/rust/blob/0376d43d443cba463a0b6a6ec9140ea17d7b7130/library/core/src/slice/mod.rs#L1064-L1066
Because of this, the revision check was getting an empty iterator when `self.props.compile_flags` was length 0 or 1.
This fix adjusts the check to handle such cases.
I went ahead and fixed the relevant test (4b3cd9b289ce0a36bda2756321f5fe455ea301e1) that was impacted by this. I do not suspect there are others, at least within the scope that Ferrocene tests, as we have not previously seen this failure.
Error on attempt to construct scalable vector type
If you attempt to construct a scalable vector type rust will ICE.
E.g.:
```rust
#[rustc_scalable_vector(4)]
#[allow(non_camel_case_types)]
struct svint32_t(i32);
fn main() {
let foo = svint32_t(1);
// This will ICE
}
```
This PR adds a check that will emit an error if you attempt to use a SV constructor and a test to ensure it works.
Tighten the `!range` bounds on alignments in vtables
Right now we're only telling LLVM that they're non-zero, but alignments must be powers of two so can't be more than `isize::MAX+1`. And we actually never emit anything beyond LLVM's limit of 2²⁹, so outside of 16-bit targets the limit is that.
(Pulled out from rust-lang/rust#152867 which is starting to have too much in it.)
Add tests for delegation generics
This PR adds tests from rust-lang/rust#151864 as discussed in this [comment](https://github.com/rust-lang/rust/pull/151864#issuecomment-3928053049). Part of rust-lang/rust#118212.
The majority of new tests are added in `mapping` folder, (`ast-hir-engine` folder in rust-lang/rust#151864), those tests test mapping between generic params of delegee and our generated function for delegation (that is why the name of the folder was changed, I think it better reflects what those tests testing). In each mapping test comments were added to each test case and one comment describing the goal of mapping tests was added at the top of each file.
Next, tests for defaults in generic params (`generic-params-defaults.rs`), params with the same name (`generic-params-same-names`), errors in providing user-specified generic args (`generics-gen-args-errors.rs`) and wrong signature of a generated function in impl trait case (`impl-trait-wrong-args-count.rs`, renamed from `wrong-args-count-ice.rs` in rust-lang/rust#151864). `generic-aux-pass.rs` test was not added, as all reuses in this test produce known ICE `DefId::expect_local DefId(..) isn't local` rust-lang/rust#143498 (which will be fixed in rust-lang/rust#151864, however it will not close mentioned issue, as synthetic generic params are not yet supported in new generics implementation).
r? @petrochenkov
Support importing path-segment keyword with renaming
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/146972)*
#### Reference PR
- https://github.com/rust-lang/reference/pull/2010
- https://github.com/rust-lang/reference/pull/2136
#### Description
This PR unifies and extends the behavior of importing path-segment keywords (`crate`/`$crate`/`super`/`self`), resolving several long-standing inconsistencies.
Previously, Rust only allowed `use crate as name;` without renaming support for other path keywords. This PR enables importing these keywords with explicit renaming. And it also denies importing these keywords without renaming.
##### What's now allowed
For **`crate`** and **`$crate`**:
- `use crate as name;`
- `use crate::{self as name};`
- `use $crate as name;`
- `use $crate::{self as name};`
For **`super`** (including chained `super::super`):
- `use super as name;`
- `use super::{self as name};`
- `use super::super as name;`
- `use super::super::{self as name};`
For **`self`**:
- `use self as name;`
- `use self::{self as name};`
##### Removed error codes
Two error codes are no longer emitted:
- **E0430**: Previously emitted for duplicate `self` imports like `std::fmt::{self, self}`. The existing E0252 ("name defined multiple times") provides sufficient guidance.
- **E0431**: Previously emitted for `use {self [as name]};` and `use ::{self [as name]};`. These patterns are now allowed or denied but with new clearer errors.
- For `use {self as name};` and `use ::{self as name};` (in edition 2015), they are allowed now and equivalent to `use crate as name`;
- For `use {self};` and `use ::{self};` (in edition 2015) without renaming, they are equivalent to `use crate;`, the new clearer error suggests adding an explicit rename.
- For `use ::{self [as name]};` after edition 2015, it is equivalent to `use ${extern-prelude} [as name];`, it is denied with new errors.
##### Future
We plan to remove error [E0429](https://doc.rust-lang.org/stable/error_codes/E0429.html#error-code-e0429) and support `self` at the end of paths (https://github.com/rust-lang/rust/pull/146972#issuecomment-3719825627). This language extension and lint for redundant `::self` instead of hard error `E0429` will be landed separately in the future.
---
Fixesrust-lang/rust#29036Fixesrust-lang/rust#35612Fixesrust-lang/rust#37156Fixesrust-lang/rust#146967Fixesrust-lang/rust#149811
r? petrochenkov
Not linting irrefutable_let_patterns on let chains
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/146832)*
# Description
this PR makes the lint `irrefutable_let_patterns` not check for `let chains`,
only check for single `if let`, `while let`, and `if let guard`.
# Motivation
Since `let chains` were stabilized, the following code has become common:
```rust
fn max() -> usize { 42 }
fn main() {
if let mx = max() && mx < usize::MAX { /* */ }
}
```
This code naturally expresses "please call that function and then do something if the return value satisfies a condition".
Putting the let binding outside the if would be bad as then it remains in scope after the if, which is not the intent.
Current Output:
```bash
warning: leading irrefutable pattern in let chain
--> src/main.rs:7:8
|
7 | if let mx = max() && mx < usize::MAX {
| ^^^^^^^^^^^^^^
|
= note: this pattern will always match
= help: consider moving it outside of the construct
= note: `#[warn(irrefutable_let_patterns)]` on by default
```
Another common case is progressively destructuring a struct with enum fields, or an enum with struct variants:
```rust
struct NameOfOuterStruct {
middle: NameOfMiddleEnum,
other: (),
}
enum NameOfMiddleEnum {
Inner(NameOfInnerStruct),
Other(()),
}
struct NameOfInnerStruct {
id: u32,
}
fn test(outer: NameOfOuterStruct) {
if let NameOfOuterStruct { middle, .. } = outer
&& let NameOfMiddleEnum::Inner(inner) = middle
&& let NameOfInnerStruct { id } = inner
{
/* */
}
}
```
Current Output:
```bash
warning: leading irrefutable pattern in let chain
--> src\main.rs:17:8
|
17 | if let NameOfOuterStruct { middle, .. } = outer
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this pattern will always match
= help: consider moving it outside of the construct
= note: `#[warn(irrefutable_let_patterns)]` on by default
warning: trailing irrefutable pattern in let chain
--> src\main.rs:19:12
|
19 | && let NameOfInnerStruct { id } = inner
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this pattern will always match
= help: consider moving it into the body
```
To avoid the warning, the readability would be much worse:
```rust
fn test(outer: NameOfOuterStruct) {
if let NameOfOuterStruct {
middle: NameOfMiddleEnum::Inner(NameOfInnerStruct { id }),
..
} = outer
{
/* */
}
}
```
# related issue
* rust-lang/rust#139369
# possible questions
1. Moving the irrefutable pattern at the head of the chain out of it would cause a variable that was intended to be temporary to remain in scope, so we remove it.
However, should we keep the check for moving the irrefutable pattern at the tail into the body?
2. Should we still lint `entire chain is made up of irrefutable let`?
---
This is my first time contributing non-documentation code to Rust. If there are any irregularities, please feel free to point them out.
: )
resolve: do not suggest `_` for unresolved imports
Fix invalid unresolved-import suggestion when a module contains an item named `_`.
`use _` is never valid syntax, so `_` should not be suggested as a similar name.
Closesrust-lang/rust#152812
As far as I can tell it was introduced to allow fat LTO with
-Clinker-plugin-lto. Later a change was made to automatically disable
ThinLTO summary generation when -Clinker-plugin-lto -Clto=fat is used,
so we can safely remove it.
Simplify `size/align_of_val<T: Sized>` to `size/align_of<T>` instead
This is relevant to things like `Box<[u8; 1024]>` where the drop looks at the `size_of_val` (since obviously it might be DST in general) but where we don't actually need to do that since it's always that same value for the `Sized` type.
(Equivalent to rust-lang/rust#152681, but flipped in the rebase so it can land before rust-lang/rust#152641 instead of depending on it.)
Perform many const checks in typeck
Some smaller diagnostic changes, the biggest ones avoided by https://github.com/rust-lang/rust/pull/148641
We should be able to move various checks in mir const checking to using `span_bug!` instead of reporting an error, just like mir typeck does as a sanity check. I would like to start doing so separately though, as this PR is a big enough (in what effects it causes, pun intended).
r? @fee1-dead
rustc_expand: improve diagnostics for non-repeatable metavars in repetition
Enhance `NoSyntaxVarsExprRepeat` by suggesting similarly named metavariables, distinguishing repeatable vs non-repeatable bindings, and listing available repeatable variables when no match exists.
Simplify the canonical enum clone branches to a copy statement
I have overhauled MatchBranchSimplification in this PR. This pass tries to unify statements one by one, which is more readable and extensible.
This PR also unifies the following pattern that is mostly generated by GVN into one basic block that contains the copy statement:
```rust
match a {
Foo::A(_) => *a,
Foo::B => Foo::B
}
```
Fixes https://github.com/rust-lang/rust/issues/128081.
Avoid delayed-bug ICE for malformed diagnostic attrs
Fixesrust-lang/rust#152744
Skip suggestions in `expected_lit` when parsing with `Recovery::Forbidden`, since this may later cancel `InvalidMetaItem`. This avoids creating delayed bugs that can be promoted to ICE.
Add a mir-opt test for alignment check generation [zero changes outside tests]
I wrote this as part of rust-lang/rust#152641 which it looks like I'm going to just close, so submitting the new test separately since we didn't have any mir-opt testing of this pass that I could find (at least `x test tests/mir-opt` didn't fail when I broke them) so figured it's something that should exist.
tests: rustc_public: Check const allocation for all variables (1 of 11 was missing)
In the test `tests/ui-fulldeps/rustc_public/check_allocation.rs` there is a check for constant allocations of local variables of this function:
fn other_consts() {{
let _max_u128 = u128::MAX;
let _min_i128 = i128::MIN;
let _max_i8 = i8::MAX;
let _char = 'x';
let _false = false;
let _true = true;
let _ptr = &BAR;
let _null_ptr: *const u8 = NULL;
let _tuple = TUPLE;
let _char_id = const {{ type_id::<char>() }};
let _bool_id = const {{ type_id::<bool>() }};
}}
The current test only finds 10 out of 11 allocations. The constant allocation for
let _ptr = &BAR;
is not checked, because the `SingleUseConsts` MIR pass does not optimize away that assignment. Add code to also collect constant allocation from assignment rvalues to find the constant allocation for that last variable.
Not only does this change make sense on its own, it also makes the test pass both with and without the `SingleUseConsts` pass.
Discovered while investigating ways to avoid [this tests/ui-fulldeps/rustc_public/check_allocation.rs](https://github.com/Enselic/rust/commit/d7fffabc31904434cd41304c2f419f8b4abc6e70#diff-c4a926f9e8ba22bcfb1e6f2491b79b80608ab018641f85f66d6718d7f3716a5e) hack from https://github.com/rust-lang/rust/pull/151426 which wants to stop running `SingleUseConsts` for non-optimized builds.
Fix ICE in transmutability error reporting when type aliases are normalized
Fixesrust-lang/rust#151462
Transmutability error reporting hit an ICE when type aliases were normalized for diagnostics. For example, when type
`JustUnit = ()` normalizes to `()`, the check passes unexpectedly even though the original check with `JustUnit` failed.
Fixed by adding a retry in the `Answer::Yes` arm that checks with the root obligation's types before panicking. The retry only occurs when the root obligation differs and is a Transmute trait predicate.
Also added a test that reproduces the original ICE.
Enhance `NoSyntaxVarsExprRepeat` by suggesting similarly named
metavariables, distinguishing repeatable vs non-repeatable bindings,
and listing available repeatable variables when no match exists.
Co-authored-by: Esteban Küber <esteban@kuber.com.ar>
Signed-off-by: Usman Akinyemi <usmanakinyemi202@gmail.com>
make `rustc_allow_const_fn_unstable` an actual `rustc_attrs` attribute
It is already named like one, but used to have its own feature gate, which this PR now removes in favor of just using `#![feature(rustc_attrs)]`.
Most of the diff is just the line number changes in `malformed-attrs.stderr`.
bors