Commit Graph

1217 Commits

Author SHA1 Message Date
Oli Scherer 11d88ee42b Rip out rustc_layout_scalar_valid_range_* attribute support 2026-05-03 10:59:52 +02:00
bors a3e96d8cb8 Auto merge of #155767 - adwinwhite:eager-norm-outside, r=lcnr
`-Znext-solver` Eager normalization outside of solver 




This PR adds a normalization routine for the next solver that behaves the same as the normalization in the old solver.
The new routine is used to normalize eagerly outside of the next solver.

This is [part 2](https://rust-lang.zulipchat.com/#narrow/channel/364551-t-types.2Ftrait-system-refactor/topic/Eager.20normalization.2C.20ahoy.21/near/582996783) of modifying the next solver to support eager normalization.

Those test changes are mostly wording changes, duplicating some errors or reducing some duplicates. But I could have overlooked something.
Notably it fixes the first, third and fourth examples in https://github.com/rust-lang/trait-system-refactor-initiative/issues/191, but not the second variant.

It's probably easier to review commit by commit.

Fixes rust-lang/rust#151308
Fixes rust-lang/rust#101557
Fixes rust-lang/rust#119692
Fixes rust-lang/rust#136859
2026-05-02 20:56:41 +00:00
Ralf Jung e402c1edf0 miri: remove retag statements, make typed copies retag implicitly instead 2026-05-02 17:40:33 +02:00
Adwin White dbba04e032 use the new routine to eagerly normalize 2026-05-02 16:11:12 +08:00
Jonathan Brouwer e683a17f80 Rollup merge of #154896 - cijiugechu:fix-unsafe-binder-layout-ice, r=TaKO8Ki
Fix ICE: Scalar layout for non-primitive non-enum type unsafe binder

`UnsafeBinder` uses the inner layout, but the debug layout check still looked at the outer type. Check the inner type first so this does not ICE.

Tracking issue: rust-lang/rust#130516
Closes: rust-lang/rust#154426
2026-04-27 19:54:47 +02:00
Jonathan Brouwer e8ad7f25e4 Rollup merge of #155702 - mejrs:itemkind_trait-fields, r=petrochenkov
Change `ItemKind::Trait` to a field variant.

This changes `ItemKind::Trait` from an octuple(!!) to an enum variant with fields. Their names were chosen to match up with existing usage and minimize renaming.

I'm leaning towards renaming `ident` to `name` as well; let me know if that's desired.
2026-04-27 19:54:46 +02:00
mejrs 9515f52d61 Change ItemKind::Trait to have named fields. 2026-04-24 19:03:16 +02:00
Oli Scherer bfb085da9f All generated associated types for opaque types in traits/impls have the same parent 2026-04-24 12:55:11 +02:00
aerooneqq 2e6a082513 Use per-parent disambiguators 2026-04-21 18:23:40 +03:00
cijiugechu dface0a9cf Fix ICE: Scalar layout for non-primitive non-enum type unsafe binder 2026-04-21 21:29:56 +08:00
Adwin White 6279106e72 fix all errors 2026-04-20 00:18:28 +08:00
bors 6f109d8a2d Auto merge of #155223 - teor2345:fndef-refactor, r=mati865
Refactor FnDecl and FnSig non-type fields into a new wrapper type





#### Why this Refactor?

This PR is part of an initial cleanup for the [arg splat experiment](https://github.com/rust-lang/rust/issues/153629), but it's a useful refactor by itself.

It refactors the non-type fields of `FnDecl`, `FnSig`, and `FnHeader` into a new packed wrapper types, based on this comment in the `splat` experiment PR:
https://github.com/rust-lang/rust/pull/153697#discussion_r3004637413

It also refactors some common `FnSig` creation settings into their own methods. I did this instead of creating a struct with defaults.

#### Relationship to `splat` Experiment

I don't think we can use functional struct updates (`..default()`) to create `FnDecl` and `FnSig`, because we need the bit-packing for the `splat` experiment.

Bit-packing will avoid breaking "type is small" assertions for commonly used types when `splat` is added.
This PR packs these types:
- ExternAbi: enum + `unwind` variants (38) -> 6 bits
- ImplicitSelfKind: enum variants (5) -> 3 bits
- lifetime_elision_allowed, safety, c_variadic: bool -> 1 bit

#### Minor Changes

Fixes some typos, and applies rustfmt to clippy files that got skipped somehow.
2026-04-18 23:46:37 +00:00
bors 1b8f2e46e1 Auto merge of #155207 - quiode:writable, r=RalfJung
add llvm writable attribute conditionally




This PR tries to address https://github.com/rust-lang/unsafe-code-guidelines/issues/584#issue-3440604811. It is part of a bachelor thesis supervised by @JoJoDeveloping and @RalfJung, for more information, see: [Project_Description.pdf](https://github.com/user-attachments/files/26537277/Project_Description.pdf).
If the new `-Zllvm-writable` flag is set, the [llvm writable attribute](https://llvm.org/docs/LangRef.html#writable) is inserted for all mutable borrows. This can be conditionally turned off on a per-function basis using the `#[rustc_no_writable]` attribute. The new Undefined Behaviour introduced by this can detected by Miri, which is implemented here: https://github.com/rust-lang/miri/pull/4947.

Two library functions already received the `#[rustc_no_writable]` attribute, as they are known to cause problems under the Tree Borrows aliasing model with implicit writes enabled.
2026-04-17 04:13:36 +00:00
Dominik Schwaiger da2bbfbbec add llvm writable attribute conditionally 2026-04-16 12:29:39 +00:00
teor dafb6bb801 Refactor FnDecl and FnSig flags into packed structs 2026-04-16 07:08:08 +10:00
WilliamTakeshi dbb83b65b0 remove calls to AliasTyKind::def_id 2026-04-15 21:23:02 +02:00
WilliamTakeshi a133bb8f27 replace @ ty::AliasTy matches with just args 2026-04-11 18:00:32 +00:00
Jana Dönszelmann 63c212e62b make typing_mode getter 2026-04-10 11:42:02 +02:00
Jana Dönszelmann 0e0d12ccb3 introduce TypingModeEqWrapper and make TypingMode !Eq 2026-04-10 11:40:01 +02:00
Waffle Lapkin 0f767084b8 ty::Alias refactor: fixup all the compiler code 2026-04-07 10:08:12 +02:00
David Wood a2f7f3c1eb ty_utils: lower tuples to ScalableVector repr
Instead of just using regular struct lowering for these types, which
results in an incorrect ABI (e.g. returning indirectly), use
`BackendRepr::ScalableVector` which will lower to the correct type and
be passed in registers.

This also enables some simplifications for generating alloca of scalable
vectors and greater re-use of `scalable_vector_parts`.

A LLVM codegen test demonstrating the changed IR this generates is
included in the next commit alongside some intrinsics that make these
tuples usable.
2026-04-03 10:27:30 +00:00
Daria Sukhonina 1b68d921a7 Add typeck_root_def_id_local 2026-03-27 15:36:28 +03:00
Nicholas Nethercote 90ea993083 Rename various query cycle things.
The existing names have bugged me for a while. Changes:

- `CycleError` -> `Cycle`. Because we normally use "error" for a `Diag`
  with `Level::Error`, and this type is just a precursor to that. Also,
  many existing locals of this type are already named `cycle`.

- `CycleError::cycle` -> `Cycle::frames`. Because it is a sequence of
  frames, and we want to avoid `Cycle::cycle` (and `cycle.cycle`).

- `cycle_error` -> `find_and_handle_cycle`. Because that's what it does.
  The existing name is just a non-descript noun phrase.

- `mk_cycle` -> `handle_cycle`. Because it doesn't make the cycle; the
  cycle is already made. It handles the cycle, which involves (a)
  creating the error, and (b) handling the error.

- `report_cycle` -> `create_cycle_error`. Because that's what it does:
  creates the cycle error (i.e. the `Diag`).

- `value_from_cycle_error` -> `handle_cycle_error_fn`. Because most
  cases don't produce a value, they just emit an error and quit.
  And the `_fn` suffix is for consistency with other vtable fns.

- `from_cycle_error` -> `handle_cycle_error`. A similar story for this
  module.
2026-03-24 08:47:34 +11:00
Zalathar 70f3e09225 Always call check_representability with tcx.ensure_ok()
This was previously not possible because `check_representability` was `anon`.
2026-03-21 14:22:10 +11:00
human9000 5113488163 Improve ty::Infer handling during const literal lowering
Co-authored-by: BoxyUwU <rust@boxyuwu.dev>
2026-03-17 21:02:09 +05:00
Nicholas Nethercote 1d7b332143 Remove Representability.
Its last meaningful uses were removed in #153493.
2026-03-13 21:48:51 +11:00
David Wood db5e2dc248 abi: s/ScalableVector/SimdScalableVector
Renaming to remove any ambiguity as to what "vector" refers to in this
context
2026-03-10 11:52:22 +00:00
Zalathar 985b41d387 Remove the rustc_data_structures::assert_matches! re-exports 2026-03-08 22:02:23 +11:00
bors c7b206bba4 Auto merge of #153383 - nnethercote:overhaul-ensure_ok, r=Zalathar
Overhaul `ensure_ok`

The interaction of `ensure_ok` and the `return_result_from_ensure_ok` query modifier is weird and hacky. This PR cleans it up. Details in the individual commits.

r? @Zalathar
2026-03-08 07:03:35 +00:00
Nicholas Nethercote d4503b017e Overhaul ensure_ok.
`ensure_ok` provides a special, more efficient way of calling a query
when its return value isn't needed. But there is a complication: if the
query is marked with the `return_result_from_ensure_ok` modifier, then
it will return `Result<(), ErrorGuaranteed`. This is clunky and feels
tacked on. It's annoying to have to add a modifier to a query to declare
information present in its return type, and it's confusing that queries
called via `ensure_ok` have different return types depending on the
modifier.

This commit:

- Eliminates the `return_result_from_ensure_ok` modifier. The proc macro
  now looks at the return type and detects if it matches `Result<_,
  ErrorGuarantee>`. If so, it adds the modifier
  `returns_error_guaranteed`. (Aside: We need better terminology to
  distinguish modifiers written by the user in a `query` declaration
  (e.g. `cycle_delayed_bug`) from modifiers added by the proc macro
  (e.g. `cycle_error_handling`.))

- Introduces `ensure_result`, which replaces the use of `ensure_ok` for
  queries that return `Result<_, ErrorGuarantee>`. As a result,
  `ensure_ok` can now only be used for the "ignore the return value"
  case.
2026-03-08 09:39:39 +11:00
Josh Stone eb093cfd5d Reformat with the new stage0 2026-03-07 10:42:02 -08:00
Josh Stone 32bae1353e Update cfg(bootstrap) 2026-03-07 10:42:02 -08:00
bors 64b72a1fa5 Auto merge of #150447 - WaffleLapkin:maybe-dangling-semantics, r=RalfJung
Implement `MaybeDangling` compiler support



Tracking issue: https://github.com/rust-lang/rust/issues/118166



cc @RalfJung
2026-03-05 12:21:27 +00:00
Waffle Lapkin d6ca5c3dc0 strip readonly/captures from MaybeDangling<&T> 2026-03-05 11:53:38 +01:00
Waffle Lapkin 8aafa53504 add semantics to MaybeDangling 2026-03-05 11:53:38 +01:00
Waffle Lapkin 11bcf3759e make PointeeInfo::align non-optional
Instead of defaulting to `None` it now defaults to `Align::ONE` i.e.
no alignment restriction. Codegen test changes are due to us now skipping
`align 1` annotations (they are useless; not skipping them makes all the
raw pointers gain an `align 1` annotation which doesn't seem any good)
2026-03-05 11:53:38 +01:00
Waffle Lapkin 312055fad5 refactor PointeeInfo
Make `size`/`align` always correct rather than conditionally on the
`safe` field. This makes it less error prone and easier to work with for
`MaybeDangling` / potential future pointer kinds like `Aligned<_>`.
2026-03-05 11:53:38 +01:00
bors f8704be04f Auto merge of #153416 - JonathanBrouwer:rollup-eezxWTV, r=JonathanBrouwer
Rollup of 12 pull requests



Successful merges:

 - rust-lang/rust#153402 (miri subtree update)
 - rust-lang/rust#152164 (Lint unused features)
 - rust-lang/rust#152801 (Refactor WriteBackendMethods a bit)
 - rust-lang/rust#153196 (Update path separators to be available in const context)
 - rust-lang/rust#153204 (Add `#[must_use]` attribute to `HashMap` and `HashSet` constructors)
 - rust-lang/rust#153317 (Abort after `representability` errors)
 - rust-lang/rust#153276 (Remove `cycle_fatal` query modifier)
 - rust-lang/rust#153300 (Tweak some of our internal `#[rustc_*]` TEST attributes)
 - rust-lang/rust#153396 (use `minicore` in some `run-make` tests)
 - rust-lang/rust#153401 (Migrationg of `LintDiagnostic` - part 7)
 - rust-lang/rust#153406 (Remove a ping for myself)
 - rust-lang/rust#153414 (Rename translation -> formatting)
2026-03-05 00:14:57 +00:00
Alan Egerton f460bb1abc Only invoke query that deduces attrs in full, opt builds
As a performance optimization, we altogether avoid ever invoking the
query that computes an Instance fn's fully optimized ABI in cases where
the build will not actually deduce parameter attributes.
2026-03-04 16:38:36 +00:00
Alan Egerton 55509a9fe4 Do not deduce parameter attributes during CTFE
`fn_abi_of_instance` can look at function bodies to deduce codegen
optimization attributes (namely `ArgAttribute::ReadOnly` and
`ArgAttribute::CapturesNone`) of indirectly-passed parameters.  This can
lead to cycles when performed during typeck, when such attributes are
irrelevant.

This patch breaks a subquery out from `fn_abi_of_instance`,
`fn_abi_of_instance_no_deduced_attrs`, which returns the ABI before such
parameter attributes are deduced; and that new subquery is used in CTFE
instead.
2026-03-04 16:38:36 +00:00
Nicholas Nethercote ff3d308966 Eliminate Representability::Infinite.
This variant was a fallback value used to continue analysis after a
`Representability` error, but it's no longer needed thanks to the
previous commit. This means `Representability` can now be reduced to a
unit type that exists just so `FromCycleError` can exist for the
`representability` query. (There is potential for additional cleanups
here, but those are beyond the scope of this PR.)

This means the `representability`/`representability_adt_ty` queries no
longer have a meaningful return value, i.e. they are check-only queries.
So they now have a `check_` prefix added. And the `rtry!` macro is no
longer needed.
2026-03-04 07:02:39 +11:00
bors c2c6f74fd2 Auto merge of #152864 - TKanX:bugfix/123183-array-cast-abi-noundef, r=RalfJung
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`.

Fixes rust-lang/rust#123183.

r? @RalfJung
2026-03-01 01:50:36 +00:00
bors 38c0de8dcb Auto merge of #153050 - JayanAXHF:refactor/change-is-type-const, 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
2026-02-28 18:27:06 +00:00
JayanAXHF efc150e5b3 refactor(mgca): Change DefKind::Const and DefKind::AssocConst to have a is_type_const flag
* 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
2026-02-28 17:27:46 +00:00
Tony Kan 97bd985467 fix(abi): Restore noundef on PassMode::Cast args in Rust ABI
`adjust_for_rust_abi` was casting small aggregates to an integer register
without propagating `noundef`, causing a performance regression (#123183)
— LLVM could no longer assume the bits were fully defined.

Add `layout_is_noundef` (conservative) + `fields_are_noundef` helper,
then use `cast_to_with_attrs` to forward `NoUndef` when proven:

  Scalar     → `!is_uninit_valid()`
  ScalarPair → both scalars valid + `s1.size + s2.size == layout.size`
               (size equality rejects layouts with inter-scalar padding)
  Array      → recurse into element; empty arrays unconditionally noundef
  Arbitrary  → `Variants::Single` required; walk fields in offset order —
               any gap, non-noundef field, or trailing pad returns false
  Union / Primitive / Simd → false (conservative)

Bless `pass-indirectly-attr.stderr` and `debuginfo-dse.rs` for the new
attribute on Cast args. Add `tests/codegen-llvm/abi-noundef-cast.rs`
covering positive Cast cases (arrays, plain structs, single-variant enum)
and negative Cast cases (MaybeUninit, multi-variant enum, field/pair gap,
trailing padding).

Fixes #123183.

Co-authored-by: Ralf Jung <post@ralfj.de>
2026-02-27 12:08:59 -08:00
Benno Lossin 7b428597ff add field representing types 2026-02-27 15:54:20 +01:00
Jana Dönszelmann decec173ec remove AttributeKind everywhere 2026-02-20 09:50:16 +01:00
Jana Dönszelmann 63edc913fa change all uses 2026-02-20 09:50:16 +01:00
bors e0cb264b81 Auto merge of #141295 - Kivooeo:if-let-guard-stable, r=fee1-dead,est31
Stabilize `if let` guards (`feature(if_let_guard)`)



## Summary

This proposes the stabilization of `if let` guards (tracking issue: rust-lang/rust#51114, RFC: rust-lang/rfcs#2294). This feature allows `if let` expressions to be used directly within match arm guards, enabling conditional pattern matching within guard clauses.

## What is being stabilized

The ability to use `if let` expressions within match arm guards.

Example:

```rust
enum Command {
    Run(String),
    Stop,
    Pause,
}

fn process_command(cmd: Command, state: &mut String) {
    match cmd {
        Command::Run(name) if let Some(first_char) = name.chars().next() && first_char.is_ascii_alphabetic() => {
            // Both `name` and `first_char` are available here
            println!("Running command: {} (starts with '{}')", name, first_char);
            state.push_str(&format!("Running {}", name));
        }
        Command::Run(name) => {
            println!("Cannot run command '{}'. Invalid name.", name);
        }
        Command::Stop if state.contains("running") => {
            println!("Stopping current process.");
            state.clear();
        }
        _ => {
            println!("Unhandled command or state.");
        }
    }
}
```

## Motivation

The primary motivation for `if let` guards is to reduce nesting and improve readability when conditional logic depends on pattern matching. Without this feature, such logic requires nested `if let` statements within match arms:

```rust
// Without if let guards
match value {
    Some(x) => {
        if let Ok(y) = compute(x) {
            // Both `x` and `y` are available here
            println!("{}, {}", x, y);
        }
    }
    _ => {}
}

// With if let guards
match value {
    Some(x) if let Ok(y) = compute(x) => {
        // Both `x` and `y` are available here
        println!("{}, {}", x, y);
    }
    _ => {}
}
```

## Implementation and Testing

The feature has been implemented and tested comprehensively across different scenarios:

### Core Functionality Tests

**Scoping and variable binding:**
- [`scope.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/scope.rs) - Verifies that bindings created in `if let` guards are properly scoped and available in match arms
- [`shadowing.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/shadowing.rs) - Tests that variable shadowing works correctly within guards
- [`scoping-consistency.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/scoping-consistency.rs) - Ensures temporaries in guards remain valid for the duration of their match arms

**Type system integration:**
- [`type-inference.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/type-inference.rs) - Confirms type inference works correctly in `if let` guards  
- [`typeck.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/typeck.rs) - Verifies type mismatches are caught appropriately

**Pattern matching semantics:**
- [`exhaustive.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/exhaustive.rs) - Validates that `if let` guards are correctly handled in exhaustiveness analysis
- [`move-guard-if-let.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/move-guard-if-let.rs) and [`move-guard-if-let-chain.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/move-guard-if-let-chain.rs) - Test that conditional moves in guards are tracked correctly by the borrow checker

### Error Handling and Diagnostics

- [`warns.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/warns.rs) - Tests warnings for irrefutable patterns and unreachable code in guards
- [`parens.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/parens.rs) - Ensures parentheses around `let` expressions are properly rejected
- [`macro-expanded.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/macro-expanded.rs) - Verifies macro expansions that produce invalid constructs are caught
- [`guard-mutability-2.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/guard-mutability-2.rs) - Tests mutability and ownership violations in guards
- [`ast-validate-guards.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2497-if-let-chains/ast-validate-guards.rs) - Validates AST-level syntax restrictions

### Drop Order and Temporaries

**Key insight:** Unlike `let_chains` in regular `if` expressions, `if let` guards do not have drop order inconsistencies because:
1. Match guards are clearly scoped to their arms
2. There is no "else block" equivalent that could cause temporal confusion

- [`drop-order.rs`](https://github.com/rust-lang/rust/blob/5796073c134eaac30475f9a19462c4e716c9119c/tests/ui/rfcs/rfc-2294-if-let-guard/drop-order.rs) - Check drop order of temporaries create in match guards
- [`compare-drop-order.rs`](https://github.com/rust-lang/rust/blob/aef3f5fdf052fbbc16e174aef5da6d50832ca316/tests/ui/rfcs/rfc-2294-if-let-guard/compare-drop-order.rs) - Compares drop order between `if let` guards and nested `if let` in match arms, confirming they behave identically across all editions
- rust-lang/rust#140981 - A complicated drop order test involved `let chain` was made by @est31
- [`drop-order-comparisons-let-chains.rs`](https://github.com/rust-lang/rust/blob/902b4d28783e03e231d8513082cc30c4fcce5d95/tests/ui/drop/drop-order-comparisons-let-chains.rs) - Compares drop order between `let chains` in `if let guard` and regular `if` expressions
- [`if-let-guards.rs`](https://github.com/rust-lang/rust/blob/5650d716e0589e2e145ce9027f35bd534e5f862a/tests/ui/drop/if-let-guards.rs) - Test correctness of drop order for bindings and temporaries
- [`if-let-guards-2`](https://github.com/rust-lang/rust/blob/3a6c8c8f3d7ae654fdb6ce1255182bda21680655/tests/ui/drop/if-let-guards-2.rs) - The same test as above but more comprehensive and tests more interactions between different features and their drop order, checking that drop order is correct, created by @traviscross 

## Edition Compatibility

This feature stabilizes on all editions, unlike `let chains` which was limited to edition 2024. This is safe because:

1. `if let` guards don't suffer from the drop order issues that affected `let chains` in regular `if` expressions
2. The scoping is unambiguous - guards are clearly tied to their match arms
3. Extensive testing confirms identical behavior across all editions

## Interactions with Future Features

The lang team has reviewed potential interactions with planned "guard patterns" and determined that stabilizing `if let` guards now does not create obstacles for future work. The scoping and evaluation semantics established here align with what guard patterns will need.

## Unresolved Issues

- [x] - rust-lang/rust#140981
- [x] - added tests description by @jieyouxu request
- [x] - Concers from @scottmcm about stabilizing this across all editions
- [x] - check if drop order in all edition when using `let chains` inside `if let` guard is the same
- [x] - interactions with guard patters
- [x] - pattern bindings drops before guard bindings https://github.com/rust-lang/rust/pull/143376
- [x] - documentaion (https://github.com/rust-lang/reference/pull/1957)
- [ ] (non-blocking) add tests for [this](https://github.com/rust-lang/rust/issues/145237) and [this](https://github.com/rust-lang/rust/pull/141295#issuecomment-3173059821)

---

**Related:**
- Tracking Issue: rust-lang/rust#51114  
- RFC: rust-lang/rfcs#2294
- Documentation PR: https://github.com/rust-lang/reference/pull/1957
2026-02-18 20:49:50 +00:00
Stuart Cook 1367126837 Rollup merge of #151783 - mu001999-contrib:impl/final-method, r=fee1-dead
Implement RFC 3678: Final trait methods

Tracking: https://github.com/rust-lang/rust/issues/131179

This PR is based on rust-lang/rust#130802, with some minor changes and conflict resolution.

Futhermore, this PR excludes final methods from the vtable of a dyn Trait.

And some excerpt from the original PR description:
> Implements the surface part of https://github.com/rust-lang/rfcs/pull/3678.
>
> I'm using the word "method" in the title, but in the diagnostics and the feature gate I used "associated function", since that's more accurate.

cc @joshtriplett
2026-02-17 13:02:21 +11:00