1259 Commits

Author SHA1 Message Date
Josh Stone bad24ccbec Replace version placeholders with 1.95.0 2026-03-02 15:00:53 -08:00
Folkert de Vries 14d29f9ae2 Stabilize cfg_select 2026-02-22 19:59:25 +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 8a2c6ea409 Rollup merge of #152778 - mu001999-contrib:fix/final-method, r=fmease
Update tracking issue number for final_associated_functions

From https://github.com/rust-lang/rust/pull/151783#discussion_r2816929026
2026-02-18 17:29:51 +11:00
Stuart Cook e53dd52e16 Rollup merge of #152749 - cyrgani:rustc-allow-const, r=jdonszelmann
make `rustc_allow_const_fn_unstable` an actual `rustc_attrs` attribute

It is already named like one, but used to have its own feature gate, which this PR now removes in favor of just using `#![feature(rustc_attrs)]`.

Most of the diff is just the line number changes in `malformed-attrs.stderr`.
2026-02-18 17:29:49 +11:00
mu001999 d2580fdd58 Update tracking issue number for final_associated_functions 2026-02-18 10:35:02 +08:00
cyrgani 83ef5059d6 make rustc_allow_const_fn_unstable an actual rustc_attrs attribute 2026-02-17 20:16:29 +00:00
cyrgani 609fde8569 remove the issue_5723_bootstrap feature 2026-02-17 10:54:04 +00:00
Stuart Cook 910d4f4c09 Rollup merge of #152206 - tshepang:misc, r=davidtwco
misc doc improvements

These are things I collected as I was looking at code and docs
2026-02-17 13:02:23 +11: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
Kivooeo 964b63f42e if let guard stabilize 2026-02-16 12:24:15 +00:00
Folkert de Vries 981dacc34f feature-gate c-variadic definitions and calls in const contexts 2026-02-15 19:54:25 +01:00
Jonathan Brouwer 42a3c864d2 Remove deprecated_safe and its corresponding feature gate 2026-02-12 22:16:28 +01:00
mu001999 7077797f52 Parse and lower final for methods
Co-authored-by: Michael Goulet <michael@errs.io>
2026-02-12 15:12:29 +08:00
Keith-Cancel 73a991fb9d Allow provisional mgca syntax of type const <IDENT> = <EXPR> to be reconized.
Revert, but without type const.

Update symbol for feature err, then update suggestion output, and lastly update tests that change because of those.

Update these new tests with the correct syntax, and few existing tests with the new outputs the merge with main added.

Fix for tidyfmt and some errors when manually resolving a merge conflicts.

Update these tests to use update error messages and type const syntax.

Update comments and error message to use new syntax instead of old type_const attribute.

Remove the type_const attribute

update some more tests to use the new syntax.

Update these test cases.

update feature gate test

Change gate logic for `mgca_type_const_syntax` to work also if `min_generic_const_args` is enabled.

Create a new feature gate that checks for the feature before expansion.

Make rustfmt handle the `type const` syntax correctly.

Add a convience method to check if a RhsKind is type const.

Rename `Const` discriminant to `Body` for `ConstItemRhsKind`

Give the `TraitItemKind` flag an enum instead of a simple bool to better describe what the flag is for.

Update formatting for these match statements.

Update clippy test to use type const syntax.

Update test to use type const syntax.

update rustfmt to match ast items.

Update clippy to match ast and hir items.

Few more test cases that used old attribute, instead of 'type const'

Update to match the output from the feature gate checks.

tidyfmt adjustments.

Update the is_type_const, so I can constrain record!(..) in encoder.rs

Update conditional compilation test.

Move the feature gate to after expansion to allow for cfg(...) to work.

Update some more tests to use the new syntax.

Update type const tests in associated-const-bindings to use new syntax.

Don't check based off the attribute, but the item here.

Update some tests outside of the const_generics folder that were using #[type_const]

update the tests in associated consts that use #[type_const] to use type const

Update these mgca tests with the type const syntax.

Add a flag to TraitItemKind for detecting type const for now. Maybe later change ItemConstRhs to have optional consts but that touches a lot more lines of code.

Don't need into for these now that it's a query.

Add is_type_const query to handle foreign def ids.

update this test to use type const syntax.

Fix logic here, we only want to lower if there is expression in this case.

Update built-in macros to use ConstItemRhsKind

Update more instance of the old ConstItemRhs.

Rename ConstItemKind to ConstItemRhsKind, I noticed there is a typed called ConstantItemKind, so add the Rhs to the name to avoid confusion.

Update lower to use ConstItemKind

Add an other helper method to check if the rhs kinda has an expr.

Update item parse to use ConstItemKind enum.

Felt the field name could a be little clear when editing a few other things.

Change the ConstItem struct see know if we have a type const or regular const.

Make sure this syntax is properly feature gated.
2026-02-09 07:59:24 -08:00
Noah Lev 9a30ec8149 Implement MVP for opaque generic const arguments
This is meant to be the interim successor to generic const expressions.
Essentially, const item RHS's will be allowed to do arbitrary const
operations using generics. The limitation is that these const items will
be treated opaquely, like ADTs in nominal typing, such that uses of them
will only be equal if the same const item is referenced. In other words,
two const items with the exact same RHS will not be considered equal.

I also added some logic to check feature gates that depend on others
being enabled (like oGCA depending on mGCA).

= Coherence =

During coherence, OGCA consts should be normalized ambiguously because
they are opaque but eventually resolved to a real value. We don't want
two OGCAs that have the same value to be treated as distinct for
coherence purposes. (Just like opaque types.)

This actually doesn't work yet because there are pre-existing
fundamental issues with equate relations involving consts that need to
be normalized. The problem is that we normalize only one layer of the
const item and don't actually process the resulting anon const. Normally
the created inference variable should be handled, which in this case
would cause us to hit the anon const, but that's not happening.
Specifically, `visit_const` on `Generalizer` should be updated to be
similar to `visit_ty`.
2026-02-08 18:15:11 +00:00
Jonathan Brouwer 972a53167c Rollup merge of #149960 - folkertdev:cfg-select-unreachable-lint, r=JonathanBrouwer
add `unreachable_cfg_select_predicates` lint

tracking issue: https://github.com/rust-lang/rust/issues/115585

Split out from https://github.com/rust-lang/rust/pull/149783. This lint is emitted on branches of a `cfg_select!` that are statically known to be unreachable. The lint is only emitted when the feature is enabled, so this change specifically does not need an FCP, and the lint will be stabilized alongside the feature (see https://github.com/rust-lang/rust/pull/149783#issuecomment-3648000286).
2026-02-07 16:04:40 +01:00
Tshepang Mbambo 3be2843107 make docs render better by separating intro from rest of paragraph 2026-02-07 04:25:02 +02:00
Tshepang Mbambo 6bb8cc619e obsolete comment
`since` is now a field of one of the parameters
2026-02-07 04:25:02 +02:00
Folkert de Vries 8aea4b1775 add unreachable_cfg_select_predicates lint
This is emitted on branches of a `cfg_select!` that are statically known
to be unreachable.
2026-02-07 02:19:42 +01:00
Taiki Endo 8cbc623c3a Add avr_target_feature 2026-02-05 19:58:41 +09:00
Deadbeef 02e10b2d90 fix issues and ui tests, address reviews 2026-01-30 15:59:34 +00:00
Deadbeef 38ee80d48e add #[rustc_non_const_trait_method] 2026-01-30 15:52:38 +00:00
bors 75963ce795 Auto merge of #151065 - nagisa:add-preserve-none-abi, r=petrochenkov
abi: add a rust-preserve-none calling convention

This is the conceptual opposite of the rust-cold calling convention and is particularly useful in combination with the new `explicit_tail_calls` feature.

For relatively tight loops implemented with tail calling (`become`) each of the function with the regular calling convention is still responsible for restoring the initial value of the preserved registers. So it is not unusual to end up with a situation where each step in the tail call loop is spilling and reloading registers, along the lines of:

    foo:
        push r12
        ; do things
        pop r12
        jmp next_step

This adds up quickly, especially when most of the clobberable registers are already used to pass arguments or other uses.

I was thinking of making the name of this ABI a little less LLVM-derived and more like a conceptual inverse of `rust-cold`, but could not come with a great name (`rust-cold` is itself not a great name: cold in what context? from which perspective? is it supposed to mean that the function is rarely called?)
2026-01-25 02:49:32 +00:00
Simonas Kazlauskas 6db94dbc25 abi: add a rust-preserve-none calling convention
This is the conceptual opposite of the rust-cold calling convention and
is particularly useful in combination with the new `explicit_tail_calls`
feature.

For relatively tight loops implemented with tail calling (`become`) each
of the function with the regular calling convention is still responsible
for restoring the initial value of the preserved registers. So it is not
unusual to end up with a situation where each step in the tail call loop
is spilling and reloading registers, along the lines of:

    foo:
        push r12
        ; do things
        pop r12
        jmp next_step

This adds up quickly, especially when most of the clobberable registers
are already used to pass arguments or other uses.

I was thinking of making the name of this ABI a little less LLVM-derived
and more like a conceptual inverse of `rust-cold`, but could not come
with a great name (`rust-cold` is itself not a great name: cold in what
context? from which perspective? is it supposed to mean that the
function is rarely called?)
2026-01-24 19:23:17 +02:00
Matthias Krüger 0bb15457de Rollup merge of #149174 - GrigorenkoPV:const_block_item, r=me,ytmimi
`const` blocks as a `mod` item

Tracking issue: rust-lang/rust#149226

This adds support for writing `const { ... }` as an item in a module. In the current implementation, this is a unique AST item that gets lowered to `const _: () = const { ... };` in HIR.

rustfmt support included.

TODO:
- `pub const { ... }` does not make sense (see rust-lang/rust#147136). Reject it. Should this be rejected by the parser or smth?
- Improve diagnostics (preferably they should not mention the fake `_` ident).
2026-01-24 15:35:08 +01:00
Jacob Pratt 4a983e0900 Rollup merge of #151439 - Mark-Simulacrum:bootstrap-bump, r=nnethercote
Bump bootstrap compiler to 1.94

https://forge.rust-lang.org/release/process.html#default-branch-bootstrap-update-tuesday
2026-01-22 00:37:43 -05:00
Pavel Grigorenko 8439fda014 Sugar for const _: () = 2026-01-21 18:12:21 +03:00
Mark Rousskov bc611ce5f1 Replace version placeholders with 1.94 2026-01-20 21:17:10 -05:00
Zachary S c3205f98dd Replace #[rustc_do_not_implement_via_object] with #[rustc_dyn_incompatible_trait], which makes the marked trait dyn-incompatible.
Removes the attribute from `MetaSized` and `PointeeSized`, with a special case in the trait solvers for `MetaSized`.

`dyn MetaSized` is a perfectly cromulent type, and seems to only have had #[rustc_do_not_implement_via_object] so the builtin object
candidate does not overlap with the builtin MetaSized impl that all `dyn` types get.
Resolves this with a special case by checking `is_sizedness_trait` where the trait solvers previously checked `implement_via_object`.

`dyn PointeeSized` alone is rejected for other reasons (since `dyn PointeeSized` is considered to have no principal trait because `PointeeSized`
is removed at an earlier stage of the compiler), but `(dyn PointeeSized + Send)` is valid and equivalent to `dyn Send`.

Add suggestions from code review

Update compiler/rustc_trait_selection/src/traits/dyn_compatibility.rs and tests

Co-authored-by: lcnr <rust@lcnr.de>
2026-01-20 12:54:40 -06:00
Jonathan Brouwer b7f6e85fa0 Remove #[rustc_lint_diagnostics] 2026-01-19 17:40:42 +01:00
Deadbeef 216ca145fd remove trailing periods in built-in attribute gate messages 2026-01-17 21:43:50 -05:00
Jana Dönszelmann 6d0f23adad rename extern item to foreign item 2026-01-12 08:07:23 +01:00
oncecelll 14c6e602f4 Add missing documentation for globs feature
Signed-off-by: oncecelll <oncecell@outlook.com>
2026-01-10 13:25:31 +08:00
Zachary S 5466c6b255 Move feature(multiple_supertrait_upcastable) to the actual feature gates section (from the internal feature gates section) and give it a tracking issue. 2026-01-08 14:57:32 -06:00
AprilNEA 4421270516 Merge associated_const_equality feature gate into MGCA
This removes `associated_const_equality` as a separate feature gate and makes it part of `min_generic_const_args` (mgca).

Key changes:
  - Remove `associated_const_equality` from unstable features, add to removed
  - Update all test files to use `min_generic_const_args` instead
  - Preserve the original "associated const equality is incomplete" error message by specially handling `sym::associated_const_equality` spans in `feature_gate.rs`
  - Rename FIXME(associated_const_equality) to FIXME(mgca)
2026-01-05 12:31:42 +08:00
reddevilmidzy 3fc3226069 Move pattern_types and unqualified_local_imports to the tracking
issue group
2026-01-03 10:24:02 +09:00
reddevilmidzy c7bb49458f Add tracking issue for sized_hierarchy 2026-01-03 00:16:02 +09:00
Jonathan Brouwer 71b17c5c18 Rollup merge of #150264 - RalfJung:target-feature-tracking-split, r=Amanieu
split up tracking issue for target feature feature gates

https://github.com/rust-lang/rust/issues/44839 is tracking too many things at once. We usually have a separate tracking issue for each feature gate, so let's do that here as well:

-  rust-lang/rust#150244
- rust-lang/rust#150245
- rust-lang/rust#150246
- rust-lang/rust#150247
- rust-lang/rust#150248
- rust-lang/rust#150249
- rust-lang/rust#150250
- rust-lang/rust#150251
- rust-lang/rust#150252
- rust-lang/rust#150253
- rust-lang/rust#150254
- rust-lang/rust#150255
- rust-lang/rust#150256
- rust-lang/rust#150257
- rust-lang/rust#150258
- rust-lang/rust#150259
- rust-lang/rust#150260
- rust-lang/rust#150261

Closes https://github.com/rust-lang/rust/issues/44839 in favor of the ones listed above.

r? `@Amanieu`
2026-01-01 02:47:20 +01:00
Zalathar ef8d943ecd Remove feature(string_deref_patterns) 2025-12-31 14:21:38 +11:00
Ralf Jung a8e5693797 split up tracking issue for target feature feature gates 2025-12-22 13:29:11 +01:00
bors 838a912ced Auto merge of #150177 - matthiaskrgr:rollup-4cw3gdw, r=matthiaskrgr
Rollup of 6 pull requests

Successful merges:

 - rust-lang/rust#149633 (Enable `outline-atomics` by default on AArch64 FreeBSD)
 - rust-lang/rust#149788 (Move shared offload globals and define per-kernel globals once)
 - rust-lang/rust#149989 (Improve filenames encoding and misc)
 - rust-lang/rust#150012 (rustc_target: Add `efiapi` ABI support for LoongArch)
 - rust-lang/rust#150116 (layout: Store inverse memory index in `FieldsShape::Arbitrary`)
 - rust-lang/rust#150159 (Split eii macro expansion code)

r? `@ghost`
`@rustbot` modify labels: rollup
2025-12-20 05:17:27 +00:00
Boxy Uwu 90a33f69f4 replace version placeholder 2025-12-19 15:04:30 -08:00
Matthias Krüger 508c382080 Rollup merge of #149788 - Sa4dUs:offload-cleanup, r=ZuseZ4
Move shared offload globals and define per-kernel globals once

This PR moves the shared LLVM global variables logic out of the `offload` intrinsic codegen and generates kernel-specific variables only ont he first call of the intrinsic.

r? `@ZuseZ4`

tracking:
- https://github.com/rust-lang/rust/issues/131513
2025-12-19 23:38:57 +01:00
Marcelo Domínguez 3e4944d573 Split runtime global logic and cache kernel specific one 2025-12-19 13:27:13 +01:00
Daniel Scherzer 9571693990 unstable.rs: fix typos in comments (implementatble -> implementable) 2025-12-18 01:32:49 -08:00
David Wood 78b06057ef attr: parse rustc_scalable_vector(N)
Extend parsing of `ReprOptions` with `rustc_scalable_vector(N)` which
optionally accepts a single literal integral value - the base multiple of
lanes that are in a scalable vector. Can only be applied to structs.

Co-authored-by: Jamie Cunliffe <Jamie.Cunliffe@arm.com>
2025-12-16 11:00:11 +00:00
Jana Dönszelmann 5768b234de use our own alternative to STD_INTERNAL_SYMBOL and make sure we mangle EIIs properly 2025-12-12 12:14:54 +01:00
Jana Dönszelmann 52e0bfccb0 rename feature gate to extern_item_impls 2025-12-12 11:32:35 +01:00
Jana Dönszelmann 3d38d9fdba EII add feature gate 2025-12-12 11:17:33 +01:00