1209 Commits

Author SHA1 Message Date
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
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
Ralf Jung 5e65109f21 add write_box_via_move intrinsic and use it for vec!
This allows us to get rid of box_new entirely
2026-02-16 17:27:40 +01:00
Kivooeo 964b63f42e if let guard stabilize 2026-02-16 12:24:15 +00:00
Jonathan Brouwer 33c2a6eba9 Rollup merge of #151365 - RalfJung:unsafe-unpin-opsem, r=BoxyUwU
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`.
2026-02-14 22:11:53 +01:00
Jonathan Brouwer 5ae6bb3faf Rollup merge of #152001 - reddevilmidzy:mgca-i, r=BoxyUwU
mGCA: Validate const literal against expected type

close: rust-lang/rust#151625
close: rust-lang/rust#150983

also fix: https://github.com/rust-lang/rust/issues/133966 (moved crashes test)
2026-02-14 18:55:35 +01:00
reddevilmidzy 01d48c62a5 Move LitToConstInput into ty::consts
Relocate LitToConstInput and const_lit_matches_ty from mir::interpret
to ty::consts::lit
2026-02-14 04:12:46 +00:00
reddevilmidzy 8af02e230a mGCA: Validate const literal against expected type
Co-authored-by: Boxy <rust@boxyuwu.dev>
2026-02-14 04:12:40 +00:00
lcnr b3d9fbc172 ICE to delayed bug 2026-02-13 13:50:43 +00:00
Ralf Jung 590c1c9966 UnsafePinned: implement opsem effects of UnsafeUnpin 2026-02-12 09:09:35 +01:00