Parse `impl` restrictions
This PR implements the parsing logic for `impl` restrictions (e.g., `pub impl(crate) trait Foo {}`) as proposed in [RFC 3323](https://rust-lang.github.io/rfcs/3323-restrictions.html).
As the first step of the RFC implementation, this PR focuses strictly on the parsing phase. The new syntax is guarded by the `#![feature(impl_restriction)]` feature gate.
This implementation basically follows the pattern used in rust-lang/rust#141754.
r? @jhpratt
Cleanup of c-variadic link test
Some changes pulled out of https://github.com/rust-lang/rust/pull/152980 that are just cosmetic, but will help make the code run on embedded targets.
r? jieyouxu
Migration of LintDiagnostic - part 5
Part of https://github.com/rust-lang/rust/issues/153099.
With this, `rust_lint` is finally done, although the change of API of `decorate_builtin_lint` impacted a few other crates, although minimal, still needed to be mentioned.
r? @JonathanBrouwer
Remove unhelpful hint from trivial bound errors
The `= help: see issue #48214` hint on trivial bound errors isn't useful, most users hitting these errors aren't trying to use the `trivial_bounds` feature. The `disabled_nightly_features` call already handles suggesting the feature gate on nightly.
Closesrust-lang/rust#152872
rustdoc: make `--emit` and `--out-dir` mimic rustc
The behavior in the test case matches rustc's:
test-dingus % ls
main.rs
test-dingus % mkdir foobar
test-dingus % rustc --emit=dep-info main.rs --out-dir=foobar
test-dingus % ls
foobar main.rs
test-dingus % ls foobar
main.d
test-dingus % rustc --emit=dep-info=testfile.d main.rs --out-dir=foobar
test-dingus % ls
foobar main.rs testfile.d
test-dingus % ls foobar
main.d
CC https://github.com/rust-lang/rust/pull/146220#issuecomment-3936957755
Migrate 11 tests from tests/ui/issues to specific directories
Moved 11 regression tests from `tests/ui/issues` to their relevant subdirectories (`imports`, `pattern`, `lint`, and `typeck`).
* Added standard issue tracking comments at the top of each file.
* Relocated associated `aux-build` files.
* Ran `./x.py test --bless` successfully.
Don’t report missing fields in struct exprs with syntax errors.
@Noratrieb [told me](https://internals.rust-lang.org/t/custom-cargo-command-to-show-only-errors-avoid-setting-rustflags-every-time/24032/7?u=kpreid) that “it is a bug if this recovery causes follow-up errors that would not be there if the user fixed the first error.” So, here’s a contribution to hide a follow-up error that annoyed me recently.
Specifically, if the user writes a struct literal with a syntax error, such as
```rust
StructName { foo: 1 bar: 2 }
```
the compiler will no longer report that the field `bar` is missing in addition to the syntax error.
This is my first time attempting any change to the parser or AST; please let me know if there is a better way to do what I’ve done here. ~~The part I’m least happy with is the blast radius of adding another field to `hir::ExprKind::Struct`, but this seems to be in line with the style of the rest of the code. (If this were my own code, I would consider changing `hir::ExprKind::Struct` to a nested struct, the same way it is in `ast::ExprKind`.)~~ The additional information is now stored as an additional variant of `ast::StructRest` / `hir::StructTailExpr`.
**Note to reviewers:** I recommend reviewing each commit separately, and in the case of the first one with indentation changes ignored.
Implement AST -> HIR generics propagation in delegation
This PR adds support for generics propagation during AST -> HIR lowering and is a part of rust-lang/rust#118212.
# High-level design overview
## Motivation
The task is to generate generics for delegations (i.e. in this context we assume a function that is created for `reuse` statements) during AST -> HIR lowering. Then we want to propagate those generated params to generated method call (or default call) in delegation. This will help to solve issues like the following:
```rust
mod to_reuse {
pub fn consts<const N: i32>() -> i32 {
N
}
}
reuse to_reuse::consts;
//~^ ERROR type annotations needed
// DESUGARED CURRENT:
#[attr = Inline(Hint)]
fn consts() -> _ { to_reuse::consts() }
// DESUGARED DESIRED:
#[attr = Inline(Hint)]
fn consts<const N: i32>() -> _ { to_reuse::consts::<N>() }
```
Moreover, user can specify generic args in `reuse`, we need to propagate them (works now) and inherit signature with substituted generic args:
```rust
mod to_reuse {
pub fn foo<T>(t: T) -> i32 {
0
}
}
reuse to_reuse::foo::<i32>;
//~^ ERROR mismatched types
fn main() {
foo(123);
}
error[E0308]: mismatched types
--> src/main.rs:24:17
|
19 | pub fn foo<T>(t: T) -> i32 {
| - found this type parameter
...
24 | reuse to_reuse::foo::<i32>;
| ^^^
| |
| expected `i32`, found type parameter `T`
| arguments to this function are incorrect
|
= note: expected type `i32`
found type parameter `T`
```
In this case we want the delegation to have signature that have one `i32` parameter (not `T` parameter).
Considering all other cases, for now we want to preserve existing behavior, which was almost fully done (at this stage there are changes in behavior of delegations with placeholders and late-bound lifetimes).
## Main approach overview
The main approach is as follows:
- We determine generic params of delegee parent (now only trait can act as a parent as delegation to inherent impls is not yet supported) and delegee function,
- Based on presence of user-specified args in `reuse` statement (i.e. `reuse Trait::<'static, i32, 123>::foo::<String>`) we either generate delegee generic params or not. If not, then we should include user-specified generic args into the signature of delegation,
- The general order of generic params generation is as following:
`[DELEGEE PARENT LIFETIMES, DELEGEE LIFETIMES, DELEGEE PARENT TYPES AND CONSTS, DELEGEE TYPES AND CONSTS]`,
- There are two possible generic params orderings (they differ only in a position of `Self` generic param):
- When Self is after lifetimes, this happens only in free to trait delegation scenario, as we need to generate implicit Self param of the delegee trait,
- When Self is in the beginning and we should not generate Self param, this is basically all other cases if there is an implicit Self generic param in delegation parent.
- Considering propagation, we do not propagate lifetimes for child, as at AST -> HIR lowering stage we can not know whether the lifetime is late-bound or early bound, so for now we do not propagate them at all. There is one more hack with child lifetimes, for the same reason we create predicates of kind `'a: 'a` in order to preserve all lifetimes in HIR, so for now we can generate more lifetimes params then needed. This will be partially fixed in one of next pull requests.
## Implementation details
- We obtain AST generics either from AST of a current crate if delegee is local or from external crate through `generics_of` of `tcx`. Next, as we want to generate new generic params we generate new node ids for them, remove default types and then invoke already existent routine for lowering AST generic params into HIR,
- If there are user-specified args in either parent or child parts of the path, we save HIR ids of those segments and pass them to `hir_analysis` part, where user-specified args are obtained, then lowered through existing API and then used during signature and predicates inheritance,
- If there are no user-specified args then we propagate generic args that correspond to generic params during generation of delegation,
- During signature inheritance we know whether parent or child generic args were specified by the user, if so, we should merge them with generic params (i.e. cases when parent args are specified and child args are not: `reuse Trait::<String>::foo`), next we use those generic args and mapping for delegee parent and child generic params into those args in order to fold delegee signature and delegee predicates.
## Tests
New tests were developed and can be found in `ast-hir-engine` folder, those tests cover all cases of delegation with different number of lifetimes, types, consts in generic params and different user-specified args cases (parent and child, parent/child only, none).
## Edge cases
There are some edge cases worth mentioning.
### Free to trait delegation.
Consider this example:
```rust
trait Trait<'a, T, const N: usize> {
fn foo<'x: 'x, A, B>(&self) {}
}
reuse Trait::foo;
```
As we are reusing from trait and delegee has `&self` param it means that delegation must have `Self` generic param:
```rust
fn foo<'a, 'x, Self, T, const N: usize, A, B>(self) {}
```
We inherit predicates from Self implicit generic param in `Trait`, thus we can pass to delegation anything that implements this trait. Now, consider the case when user explicitly specifies parent generic args.
```rust
reuse Trait::<'static, String, 1>::foo;
```
In this case we do not need to generate parent generic params, but we still need to generate `Self` in delegation (`DelegationGenerics::SelfAndUserSpecified` variant):
```rust
fn foo<'x, Self, A, B>(self) {}
```
User-specified generic arguments should be used to replace parent generic params in delegation, so if we had param of type `T` in `foo`, during signature inheritance we should replace it with user-specified `String` type.
### impl trait delegation
When we delegate from impl trait to something, we want the delegation to have signature that matches signature in trait. For this reason we already resolve delegation not to the actual delegee but to the trait method in order to inherit its signature. That is why when processing user-specified args when the caller kind is `impl trait` (`FnKind::AssocTraitImpl`), we discard parent user-specified args and replace them with those that are specified in trait header. In future we will also discard `child_args` but we need proper error handling for this case, so it will be addressed in one of future pull requests that are approximately specified in "Nearest future work" section.
## Nearest future work (approximate future pull requests):
- Late-bound lifetimes
- `impl Trait` params in functions
- Proper propagation of parent generics when generating method call
- ~Fix diagnostics duplication during lowering of user-specified types~
- Support for recursive delegations
- Self types support `reuse <u8 as Trait<_>>::foo as generic_arguments2`
- Decide what to do with infer args `reuse Trait::<_, _>::foo::<_>`
- Proper error handling when there is a mismatch between actual and expected args (impl trait case)
r? @petrochenkov
tests: codegen-llvm: vec-calloc: do not require the uwtable attribute
The `uwtable` attribute does not get emitted on targets that don't have unwinding tables, such as `x86_64-unknown-hermit`.
don't emit `unused_results` lint for tuples of "trivial" types
r? @jdonszelmann
Fixesrust-lang/rust#153144.
So it turns out rust-lang/rust#153018 had a sneaky behavior change in the way tuples are handled and the old behavior wasn't tested.
Consider these tuples:
```rust
((), ());
((), 1);
```
Neither of them is `must_use`, so they are potential candidates for `unused_results`. So the question is whatever said tuples are considered "trivial" and thus if they end up emitting `unused_results` or not.
Here is a comparison table between PRs:
<table>
<tr><td>stable</td><td>After #153018</td><td>After this PR</td></tr><tr><td>
```rust
((), ()); // trivial
((), 1); // trivial
```
</td>
<td>
```rust
((), ()); //~ warn: unused_results
((), 1); //~ warn: unused_results
```
</td>
<td>
```rust
((), ()); // trivial
((), 1); //~ warn: unused_results
```
</td>
</tr>
<tr>
<td>
tuples are trivial if **any** of their fields are trivial
</td>
<td>
tuples are never trivial
</td>
<td>
tuples are trivial if **all** of their fields are trivial
</td>
</tr>
</table>
core: make atomic primitives type aliases of `Atomic<T>`
Tracking issue: https://github.com/rust-lang/rust/issues/130539
This makes `AtomicI32` and friends type aliases of `Atomic<T>` by encoding their alignment requirements via the use of an internal `Storage` associated type. This is also used to encode that `AtomicBool` store a `u8` internally.
Modulo the `Send`/`Sync` implementations, this PR does not move any trait implementations, methods or associated functions – I'll leave that for another PR.
Updated slice tests to pass for big endian hosts for `multiple-option-or-permutations.rs`
It was discovered that the FileCheck tests when performing an `Option::or` operation on a slice was failing when tested on a big endian host.
The compiler explorer link is here outlining the codegen output differences - https://rust.godbolt.org/z/qdE7d3G4f
This MR relaxes the constraints for the `*slice_u8` variants of the test (by changing `CHECK-NEXT` to `CHECK-DAG`), whilst still maintaining the check for the necessary `or` logic.
Huge thanks to @Gelbpunkt for identifying this issue! It has been confirmed that this fix passes on a big endian target now as well.
Closesrust-lang/rust#151718
add tests for thumb interworking
fixes https://github.com/rust-lang/rust/issues/151946
thumb programs (using a 16-bit instruction encoding) can call arm (32-bit instruction encoding) code. Doing so requires switching from thumb mode to arm mode, executing, then switching back. Test that this happens correctly, in particular for naked functions.
cc @thejpster can you confirm the output looks good here and that we're testing all of the relevant things
r? jieyouxu because this is doing some interesting things testing-wise
I believe that we need run-make here because we need to look at the assembly after the linker has run. It will correct calls from thumb to arm: depending on the thumb version this either uses a special instruction or inserts a call to a thunk that handles switching between thumb and arm mode.
test: add regression test for fuzzy_provenance_casts lint ICE
This PR adds a regression test for an ICE in `draw_code_line` that occurred when emitting a `fuzzy_provenance_casts` lint diagnostic for code with an inner attribute spanning the entire file, causing a panic on an empty `file_lines` from a dummy span.
The ICE no longer reproduces on the latest main. This PR only adds a regression test to prevent future regressions.
The test is based on the auto-reduced code from the issue.
rust-lang/rust#137588
tests/ui/asm: add annotations for reference rules
r? ehuss
Replaced rust-lang/rust#152881 which got closed when the branch was renamed
@rustbot label +A-docs
Re-add `#[inline]` to `Eq::assert_fields_are_eq`
Fixes a compile-time regression in https://github.com/rust-lang/rust/pull/149978: non-inline methods are generally codegen'd while inline methods are deferred (and this function should never be called, so deferring is the right choice).
r? JonathanBrouwer
CC @cyrgani
Revert "resolve: Downgrade `ambiguous_glob_imports` to warn-by-default"
This reverts commit cd05071ec4.
Revert of https://github.com/rust-lang/rust/pull/151130.
This will need to be merged after ~February 27 2026, when Rust 1.95 branches out from the main branch.
This prevents spurious errors when a field is intended to be present
but a preceding syntax error caused it not to be parsed. For example,
StructName { foo: 1 bar: 2 }
will not successfully parse a field `bar`, and we will report the syntax
error but not the missing field.
perf(codegen): Restore `noundef` On `PassMode::Cast` Args In Rust ABI
### Summary:
#### Problem:
Small aggregate arguments passed via `PassMode::Cast` in the Rust ABI (e.g. `[u32; 2]` cast to `i64`) are missing `noundef` in the emitted LLVM IR, even when the type contains no uninit bytes:
```rust
#[no_mangle]
pub fn f(v: [u32; 2]) -> u32 { v[0] }
```
```llvm
; expected: define i32 @f(i64 noundef %0)
; actual: define i32 @f(i64 %0) ← noundef missing
```
This blocks LLVM from applying optimizations that require value-defined semantics on function arguments.
#### Root Cause:
`adjust_for_rust_abi` calls `arg.cast_to(Reg::Integer)`, which internally creates a `CastTarget` with `ArgAttributes::new()` — always empty. Any validity attribute that was present before the cast is silently dropped.
This affects all `PassMode::Cast` arguments and return values in the Rust ABI: plain arrays, newtype wrappers, and any `BackendRepr::Memory` type small enough to fit in a register.
A prior attempt (rust-lang/rust#127210) used `Ty`/`repr` attributes to detect padding.
#### Solution:
After `adjust_for_rust_abi`, iterate all `PassMode::Cast` args and the return value. For each, call `layout_is_noundef` on the original layout; if it returns `true`, set `NoUndef` on the `CastTarget`'s `attrs`.
`layout_is_noundef` uses only the computed layout — `BackendRepr`, `FieldsShape`, `Variants`, `Scalar::is_uninit_valid()` — and never touches `Ty` or repr attributes. **Anything it cannot prove returns `false`.**
Covered cases:
- `Scalar` / `ScalarPair` (both halves initialized, fields contiguous)
- `FieldsShape::Array` (element type recursively uninit-free)
- `FieldsShape::Arbitrary` with `Variants::Single` (fields cover `0..size` with no gaps, each recursively uninit-free) — handles newtype wrappers, multi-field structs, single-variant enums, `repr(transparent)`, `repr(C)` wrappers
Conservatively excluded with FIXMEs:
- Multi-variant enums (per-variant padding analysis needed)
- Foreign-ABI casts (cast target may exceed layout size, needs a size guard)
### Changes:
- `compiler/rustc_ty_utils/src/abi.rs`: add restoration loop after `adjust_for_rust_abi`; add `layout_is_noundef` and `fields_cover_layout`.
- `tests/codegen-llvm/abi-noundef-cast.rs`: new FileCheck test covering arrays, newtype wrappers (`repr(Rust)`, `repr(transparent)`, `repr(C)`), multi-field structs, single-variant enums, return values, and negative cases (`MaybeUninit`, struct with trailing padding).
- `tests/codegen-llvm/debuginfo-dse.rs`: update one CHECK pattern — `Aggregate_4xi8` (`struct { i8, i8, i8, i8 }`) now correctly gets `noundef`.
Fixesrust-lang/rust#123183.
r? @RalfJung
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#146989 (Inhibit all-absent-variant optimization for all enum reprs that inhibit layout optimization, not just repr(C).)
- rust-lang/rust#151991 (std: sys: pal: uefi: os: Implement split_paths)
- rust-lang/rust#152794 (Fix ICE in `try_to_raw_bytes` when array elements have mismatched)
- rust-lang/rust#153052 (std random.rs: update link to RTEMS docs)
- rust-lang/rust#153054 (docs: note env var influence on `temp_dir` and `env_clear` on Windows)
- rust-lang/rust#153061 (cleanup `tests/ui/box`, part 2)
- rust-lang/rust#153197 (style: Update doctests for `TryFrom<integer> for bool` and `From<bool> for float`)
- rust-lang/rust#153210 (Fix ICE on empty file with -Zquery-dep-graph)
- rust-lang/rust#153228 (Remove `TranslationError`)
Fix ICE on empty file with -Zquery-dep-graph
added a guard in `DepGraph::register_dep_node_debug_str` so it early-returns
when `self.data` is still `None`. this happens for the first few dep-nodes
in an empty crate with `-Z query-dep-graph`, which caused the previous
`unwrap()` panic.
fixesrust-lang/rust#153199
cleanup `tests/ui/box`, part 2
Followup to rust-lang/rust#152868.
I merged some of the slightly less trivial tests into `basic-operations.rs` and deleted several others entirely.
r? @Kivooeo (since you claimed the last one, but feel free to reassign)
Part of https://github.com/rust-lang/rust/issues/133895.
Fix ICE in `try_to_raw_bytes` when array elements have mismatched
close: rust-lang/rust#152683
After rust-lang/rust#152001, suffixed integer literals preserve their own type during const lowering, so `try_to_raw_bytes` could call `.to_u8()` on a scalar with size > 1, causing an ICE. Fix by using `try_to_bits(Size::from_bytes(1)).ok()` instead.
r? BoxyUwU
refactor(mgca): Change `DefKind::Const` and `DefKind::AssocConst` to have a `is_type_const` flag
Addresses rust-lang/rust#152940
- Changed `DefKind::Const` and `DefKind::AssocConst` to have a `is_type_const` flag.
- changed `is_type_const` query to check for this flag
- removed `is_rhs_type_const` query
r? @BoxyUwU
* refactor: add `is_type_const` flag to `DefKind::Const` and `AssocConst`
* refactor(cleanup) remove the `rhs_is_type_const` query
* style: fix formatting
* refactor: refactor stuff in librustdoc for new Const and AssocConst
* refactor: refactor clippy for the changes
* chore: formatting
* fix: fix test
* fix: fix suggestions
* Update context.rs
Co-authored-by: Boxy <rust@boxyuwu.dev>
* changed AssocKind::Const to store data about being a type const
Jonathan Brouwer