fix refining_impl_trait suggestion with return_type_notation
using `#![feature(return_type_notation)] `on top of `refining_impl_trait` made the lint suggest a pretty wild “wrap the body in `<Self as Trait>::f(..)”` fix instead of the simple “just copy the return type from the trait”. this patch makes the lint always suggest the plain return-type replacement based on the trait signature (by grabbing the original snippet when possible), so you don’t get RTN-style desugarings in the help
new test here
fixesrust-lang/rust#151663
extend unpin noalias tests to cover mutable references
https://github.com/rust-lang/rust/pull/152946 made a change to the logic for this attribute that the test should have flagged as problematic -- but the test only checked `Box`, not `&mut`, and those have independent code paths. So extend the test to also cover `&mut`.
@b-naber would be nice if you could confirm that the added tests do fail with your PR.
Index expressions rendered the index: subexpression as the id, instea…
…d of actually showing the content of the subexpression
This meant the content of the subexpression was completely missing from tree view (as the id did not reference anything)
Feature gate for defaulted associated type_consts with associated_type_defaults
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/152385)*
This PR for issue rust-lang/rust#130288 extends a feature gate that was already present for defaulted associated types to defaulted type consts under associated_type_defaults.
Code added:
```
if ctxt == AssocCtxt::Trait && rhs.is_some() {
gate!(
&self,
associated_type_defaults,
i.span,
"associated type defaults are unstable"
);
}
```
Error produced:
```
error[E0658]: associated type defaults are unstable
--> $DIR/type-const-associated-default.rs:4:5
|
LL | type const N: usize = 10;
| ^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #29661 <https://github.com/rust-lang/rust/issues/29661> for more information
= help: add `#![feature(associated_type_defaults)]` to the crate attributes to enable
= note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date
warning: the feature `min_generic_const_args` is incomplete and may not be safe to use and/or cause compiler crashes
--> $DIR/type-const-associated-default.rs:1:12
|
LL | #![feature(min_generic_const_args)]
| ^^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #132980 <https://github.com/rust-lang/rust/issues/132980> for more information
= note: `#[warn(incomplete_features)]` on by default
error: aborting due to 1 previous error; 1 warning emitted
For more information about this error, try `rustc --explain E0658`.
```
Thanks to @BoxyUwU for the guidance on this issue.
fix(codegen): Use `body_codegen_attrs` For Caller In `adjust_target_feature_sig`
### Summary:
#### Problem:
Coercing a `#[target_feature]` `const fn` to a function pointer inside a `const` body triggers an ICE (debug builds only):
```rust
#[target_feature(enable = "sse2")]
const fn with_target_feature() {}
const X: () = unsafe {
let _: unsafe fn() = with_target_feature; // ICE
};
```
```text
assertion failed: def_kind.has_codegen_attrs()
unexpected `def_kind` in `codegen_fn_attrs`: Const
```
#### Root Cause:
Introduced in rust-lang/rust#135504 (2025-01-14, commit `8fee6a77394`). `adjust_target_feature_sig` unconditionally calls `codegen_fn_attrs(caller)` to get the caller's target features. `codegen_fn_attrs` requires that the `DefId` satisfies `has_codegen_attrs()`. `DefKind::Const`, `AssocConst`, and `InlineConst` do not — they have no codegen attributes by design. The debug assertion fires.
In release builds the call "worked" accidentally: `codegen_fn_attrs` on a const would reach the query machinery and happen to return empty attributes, producing a correct (but unguaranteed) result. The bug was latent until debug builds exposed it.
#### Solution:
Replace `codegen_fn_attrs(caller)` with `body_codegen_attrs(caller)`. `body_codegen_attrs` exists precisely for this case: it delegates to `codegen_fn_attrs` for function-like `DefKind`s and returns `CodegenFnAttrs::EMPTY` for const items. A const body has no target features, so returning empty is semantically correct.
Also fix the pre-existing variable name `callee_features` → `caller_features` (the variable holds the *caller*'s features, not the callee's).
### Changes:
- `compiler/rustc_middle/src/ty/context.rs`: `adjust_target_feature_sig` — use `body_codegen_attrs` for `caller`; rename `callee_features` → `caller_features`.
- `tests/ui/target-feature/const-target-feature-fn-ptr-coercion.rs`: regression test covering `Const`, `AssocConst`, and `InlineConst` caller contexts.
Fixesrust-lang/rust#152340.
reduce the amount of panics in `{TokenStream, Literal}::from_str` calls
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/147859)*
Before this PR, calling `TokenStream::from_str` or `Literal::from_str` with an invalid argument would always cause a compile error, even if the `TokenStream` is not used afterwards at all.
This PR changes this so it returns a `LexError` instead in some cases.
This is very theoretically a breaking change, but the doc comment on the impl already says
```
/// NOTE: some errors may cause panics instead of returning `LexError`. We reserve the right to
/// change these errors into `LexError`s later.
```
Fixes some cases of rust-lang/rust#58736.
Simplify internals of `{Rc,Arc}::default`
This commit simplifies the internal implementation of `Default` for these two pointer types to have the same performance characteristics as before (a side effect of changes in rust-lang/rust#131460) while avoid use of internal private APIs of Rc/Arc. To preserve the same codegen as before some non-generic functions needed to be tagged as `#[inline]` as well, but otherwise the same IR is produced before/after this change.
The motivation of this commit is I was studying up on the state of initialization of `Arc` and `Rc` and figured it'd be nicer to reduce the use of internal APIs and instead use public stable APIs where possible, even in the implementation itself.
Fix ICE in const eval of packed SIMD types with non-power-of-two element counts
fixesrust-lang/rust#151537
const evaluation of packed SIMD types with non-power-of-two element counts (like `Simd<_, 3>`) was hitting an ICE. the issue was in `check_simd_ptr_alignment` - it asserted that `backend_repr` must be `BackendRepr::SimdVector`, but for packed SIMD types with non-power-of-two counts the compiler uses `BackendRepr::Memory` instead (as mentioned in `rustc_abi/src/layout.rs:1511`).
was fixed by making `check_simd_ptr_alignment` accept both `BackendRepr::SimdVector` and `BackendRepr::Memory` for SIMD types. added a check to ensure we're dealing with a SIMD type, and the alignment logic works the same for both representations.
also i added a test that reproduces the original ICE.
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.
Stuart Cook