5667 Commits

Author SHA1 Message Date
Josh Stone d0b5e61fe7 Revert "Stabilize assert_matches"
This reverts commit 2f3b952349.
2026-04-08 14:10:50 -07:00
Jonathan Brouwer 81aa532b7f Rollup merge of #152651 - TaKO8Ki:fix-143872-compare-impl-item-diag-args, r=jdonszelmann
Avoid duplicate `requirement` diag args in `RegionOriginNote`

Fixes rust-lang/rust#143872

`RegionOriginNote::WithRequirement` can be emitted multiple times for one
  diagnostic. I fixed the ICE by scoping per note fluent args in `RegionOriginNote::WithRequirement` with `store_args` and `restore_args`.
2026-02-26 09:57:03 +01:00
mu001999 ff0f239bb1 Remove redundant self usages 2026-02-25 22:51:53 +08:00
Takayuki Maeda 3f76a0db94 avoid duplicate requirement diag args in RegionOriginNote 2026-02-25 01:06:07 +09:00
Jonathan Brouwer b8999f2b20 Rollup merge of #152492 - biscuitrescue:fix-array-valtree-wf, r=BoxyUwU
mGCA: Enforce WF element types for array valtrees

Fixes rust-lang/rust#152125

Extends WellFormedness checking for const generics to validate that array element types in ValTrees match the declared element type.

### Problem
Before commit, this would have incorrectly compiled

``` rust
#![feature(adt_const_params, min_generic_const_args)]

use std::marker::ConstParamTy;

#[derive(Eq, PartialEq, ConstParamTy)]
struct Foo;

struct Bar;

fn foo<const N: [Foo; 1]>() {}

fn main() {
    foo::<{ [Bar] }>();
}
```

### Solution
Added a `ty::Array` arm to checking WellFormedness (similar to the existing `ty::Tuple` arm from rust-lang/rust#150713) which creates `ConstArgHasType` obligations for each array element, ensuring they match the array's declared element type.

I attempted to combine the `Tuple` and `Array` arms into a single arm, but this proved difficult due to pattern matching limitations, and the separate arm is more readable anyway.

### Tests

Added UI test which verifies that the type mismatch is now properly caught, and also returns an appropriate test message

r? @BoxyUwU
2026-02-24 14:41:55 +01:00
mejrs 16661a1121 Use proper find_attr syntax 2026-02-24 10:50:40 +01:00
mejrs 9c68ea0e34 Move diagnostic formatting logic to rustc_hir 2026-02-24 10:50:39 +01:00
mejrs e8069300e4 Delete unused code 2026-02-24 10:50:38 +01:00
mejrs 8d7aa5eb9a Port diagnostic::on_const 2026-02-24 10:50:38 +01:00
mejrs cfc2468969 Port rustc_on_unimplemented attribute 2026-02-24 10:50:38 +01:00
mejrs f944436c29 port over diagnostic::on_unimplemented 2026-02-24 10:50:38 +01:00
mejrs fad53c4ee3 on_unimplemented: split structs and implementations 2026-02-24 10:50:38 +01:00
Jonathan Brouwer 0afd9c3fc1 Rollup merge of #152879 - nnethercote:rm-impl-IntoQueryParam-ref-P, r=oli-obk
Remove `impl IntoQueryParam<P> for &'a P`.

`IntoQueryParam` is a trait that lets query callers be a bit sloppy with the passed-in key.
- Types similar to `DefId` will be auto-converted to `DefId`. Likewise for `LocalDefId`.
- Reference types will be auto-derefed.

The auto-conversion is genuinely useful; the auto-derefing much less so. In practice it's only used for passing `&DefId` to queries that accept `DefId`, which is an anti-pattern because `DefId` is marked with `#[rustc_pass_by_value]`.

This commit removes the auto-deref impl and makes the necessary sigil adjustments. (I generally avoid using `*` to deref manually at call sites, preferring to deref via `&` in patterns or via `*` in match expressions. Mostly because that way a single deref often covers multiple call sites.)

r? @cjgillot
2026-02-22 11:31:16 +01:00
Jonathan Brouwer b3cfe5ec5c Rollup merge of #151871 - jdonszelmann:no-env-with-infer-vars, r=BoxyUwU
don't use env with infer vars

This is a change lcnr added on top of https://github.com/rust-lang/rust/pull/151746/changes/5bd20bbd0ba6c0285664e55a1ffc677d7487c98b but we decided that it's a separate change for a separate problem. So, filed as a separate PR. Lcnr asked me to r? @BoxyUwU to take a look so hiii boxy :3
2026-02-22 11:31:12 +01:00
Nicholas Nethercote a3d590888b Remove impl IntoQueryParam<P> for &'a P.
`IntoQueryParam` is a trait that lets query callers be a bit sloppy with
the passed-in key.
- Types similar to `DefId` will be auto-converted to `DefId`. Likewise
  for `LocalDefId`.
- Reference types will be auto-derefed.

The auto-conversion is genuinely useful; the auto-derefing much less so.
In practice it's only used for passing `&DefId` to queries that accept
`DefId`, which is an anti-pattern because `DefId` is marked with
`#[rustc_pass_by_value]`.

This commit removes the auto-deref impl and makes the necessary sigil
adjustments. (I generally avoid using `*` to deref manually at call
sites, preferring to deref via `&` in patterns or via `*` in match
expressions. Mostly because that way a single deref often covers
multiple call sites.)
2026-02-22 17:58:54 +11:00
Jonathan Brouwer c0fe6943ae Rollup merge of #152759 - jdonszelmann:simpler-get-attrs, r=jonathanbrouwer
Simpler `find_attr!()`

r? @JonathanBrouwer
cc: @jyn514
2026-02-20 13:24:55 +01:00
Jana Dönszelmann 642d9c430b modernize comments about typing modes 2026-02-20 10:49:04 +01:00
Jana Dönszelmann decec173ec remove AttributeKind everywhere 2026-02-20 09:50:16 +01:00
Jana Dönszelmann 04f762d842 allow deprecated for some valid uses 2026-02-20 09:50:16 +01:00
Jana Dönszelmann 63edc913fa change all uses 2026-02-20 09:50:16 +01:00
lcnr c316bdf293 don't use env with infer vars 2026-02-20 09:43:54 +01:00
bors 59fd4ef94d Auto merge of #152747 - nnethercote:bring-back-enum-DepKind, r=Zalathar
Bring back `enum DepKind`.

*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/152747)*

It was removed in rust-lang/rust#115920 to enable it being moved to `rustc_query_system`, a move that has recently been reversed. It's much simpler as an enum.

r? @Zalathar
2026-02-20 06:07:20 +00:00
Jonathan Brouwer 9330931a2b Rollup merge of #152596 - estebank:multipart_suggestions, r=petrochenkov
Make all multipart suggestions verbose

The ShowAlways style of suggestions is usually easier to understand than the inline style.
2026-02-19 10:56:37 +01:00
bors fbd6934114 Auto merge of #152825 - JonathanBrouwer:rollup-0YvwE70, r=JonathanBrouwer
Rollup of 18 pull requests

Successful merges:

 - rust-lang/rust#152799 (Subtree sync for rustc_codegen_cranelift)
 - rust-lang/rust#152814 (stdarch subtree update)
 - rust-lang/rust#151059 (x86: support passing `u128`/`i128` to inline assembly)
 - rust-lang/rust#152097 (Suggest local variables for captured format args)
 - rust-lang/rust#152734 (Respect the `--ci` flag in more places in bootstrap)
 - rust-lang/rust#151703 (Fix ICE in transmutability error reporting when type aliases are normalized)
 - rust-lang/rust#152173 (Reflection TypeKind::FnPtr)
 - rust-lang/rust#152564 (Remove unnecessary closure.)
 - rust-lang/rust#152628 (tests: rustc_public: Check const allocation for all variables (1 of 11 was missing))
 - rust-lang/rust#152658 (compiletest: normalize stderr before SVG rendering)
 - rust-lang/rust#152766 (std::r#try! - avoid link to nightly docs)
 - rust-lang/rust#152780 (Remove some clones in deriving)
 - rust-lang/rust#152787 (Add a mir-opt test for alignment check generation [zero changes outside tests])
 - rust-lang/rust#152790 (Fix incorrect target in aarch64-unknown-linux-gnu docs)
 - rust-lang/rust#152792 (Fix an ICE while checking param env shadowing on an erroneous trait impl)
 - rust-lang/rust#152793 (Do no add -no-pie on Windows)
 - rust-lang/rust#152803 (Avoid delayed-bug ICE for malformed diagnostic attrs)
 - rust-lang/rust#152806 (interpret: fix comment typo)
2026-02-19 04:18:20 +00:00
Nicholas Nethercote c4a69d4712 Bring back enum DepKind.
It was removed in #115920 to enable it being moved to
`rustc_query_system`, a move that has recently been reversed. It's much
simpler as an enum.

Also:
- Remove the overly complicated `Debug` impl for `DepKind`.
- Remove the trivial `DepKind` associated constants (`NULL` et al.)
- Add an assertion to ensure that the number of `DepKinds` fits within a
  `u16`.
- Rename `DEP_KIND_VARIANTS` as `DEP_KIND_NUM_VARIANTS`, to make it
  clearer that it's a count, not a collection.
- Use `stringify!` in one place to make the code clearer.
2026-02-19 09:05:37 +11:00
Jonathan Brouwer a28a4845e7 Rollup merge of #152792 - ShoyuVanilla:issue-152663, r=petrochenkov
Fix an ICE while checking param env shadowing on an erroneous trait impl

Fixes https://github.com/rust-lang/rust/issues/152663
2026-02-18 22:19:53 +01:00
Jonathan Brouwer d7ad9f7ec9 Rollup merge of #151703 - zedddie:fix-151462-ice, r=jdonszelmann
Fix ICE in transmutability error reporting when type aliases are normalized

Fixes rust-lang/rust#151462

Transmutability error reporting hit an ICE when type aliases were normalized for diagnostics. For example, when type
 `JustUnit = ()` normalizes to `()`, the check passes unexpectedly even though the original check with `JustUnit` failed.

Fixed by adding a retry in the `Answer::Yes` arm that checks with the root obligation's types before panicking. The retry only occurs when the root obligation differs and is a Transmute trait predicate.

Also added a test that reproduces the original ICE.
2026-02-18 22:19:48 +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
Esteban Küber 37684bdfc5 Make all multipart suggestions verbose
The ShowAlways style of suggestions is usually easier to understand than the inline style.
2026-02-18 18:33:35 +00:00
Shoyu Vanilla fb94e5883e Fix an ICE while checking param env shadowing on an erroneous trait impl 2026-02-18 19:14:26 +09:00
Stuart Cook e8327b0a79 Rollup merge of #152745 - TaKO8Ki:fix-ice-suggest-param-env-shadowing-incompatible-args, r=Kivooeo
Fix ICE in `suggest_param_env_shadowing` with incompatible args

Fixes rust-lang/rust#152684
2026-02-18 17:29:49 +11:00
Stuart Cook 9e38745532 Rollup merge of #152637 - JohnTitor:issue-65866, r=estebank
Add a note about elided lifetime

Fixes rust-lang/rust#65866
r? @estebank
2026-02-18 17:29:42 +11:00
bors 3f6250a7bb Auto merge of #152738 - workingjubilee:revert-unsound-ice-patch, r=mati865
Revert "Fix an ICE in the vtable iteration for a trait reference"

The ICE fix appears to be unsound, causing a miscompilation involving `dyn Trait` and `async {}` which induces segfaults in safe Rust code. As the patch only hid an ICE, it does not seem worth the risk.

This addresses the problem in rust-lang/rust#152735 but it may still merit team discussion even if this PR is merged.

This reverts commit 8afd63610b, reversing changes made to 19122c03c7.
2026-02-17 09:36:10 +00:00
Takayuki Maeda cbfa215893 fix ICE in suggest_param_env_shadowing with incompatible args
remove comments
2026-02-17 16:48:57 +09:00
Stuart Cook dc77672e9a Rollup merge of #152698 - Zalathar:zforce, r=jieyouxu
Suppress unstable-trait notes under `-Zforce-unstable-if-unmarked`

- Fixes https://github.com/rust-lang/rust/issues/152692.
---

https://github.com/rust-lang/rust/pull/151036 adds extra diagnostic text (“the nightly-only, unstable trait”) to note when a not-implemented trait is unstable.

However, that extra text is usually unhelpful when building a crate graph with `-Zforce-unstable-if-unmarked` (such as the compiler or stdlib), because *any* trait not explicitly marked stable will be treated as unstable.

(For typical compiler contributors using the stage0 compiler, this fix won't take effect until the next bootstrap beta bump.)
2026-02-17 13:02:24 +11:00
Stuart Cook 572b53fdaf Rollup merge of #152661 - BartSimpson001:fix-next-solver-from-ice, r=petrochenkov
Avoid ICE in From/TryFrom diagnostic under -Znext-solver

Fixes rust-lang/rust#152518.

Under `-Znext-solver=globally`, `trait_ref.args` may contain fewer
elements than expected. The diagnostic logic in
`fulfillment_errors.rs` assumed at least two elements and
unconditionally called `type_at(1)`, which could lead to an
index out-of-bounds panic during error reporting.

This change adds a defensive check before accessing the second
argument to avoid the ICE. A UI regression test has been added.
2026-02-17 13:02:22 +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
Jubilee Young 18a707fc8e Revert "Fix an ICE in the vtable iteration for a trait reference"
The ICE fix appears to be unsound, causing a miscompilation involving
`dyn Trait` and `async {}` which induces segfaults in safe Rust code.
As the patch only hid an ICE, it does not seem worth the risk.

This reverts commit 8afd63610b, reversing
changes made to 19122c03c7.
2026-02-16 17:52:06 -08:00
Kivooeo 964b63f42e if let guard stabilize 2026-02-16 12:24:15 +00:00
Zalathar 125e69e862 Suppress unstable-trait notes under -Zforce-unstable-if-unmarked 2026-02-16 17:19:05 +11:00
bors fef627b1eb Auto merge of #152636 - nnethercote:big-cleanups, r=Zalathar
Big query system cleanups

Recent PRs have moved a lot of code from `rustc_query_system` to `rustc_middle` and `rustc_query_impl`, where this code now has access to `TyCtxt`, e.g. rust-lang/rust#152419, rust-lang/rust#152516. As a result, a lot of abstraction and indirection that existed to work around this limitation is no longer necessary. This PR removes a lot of it.

r? @Zalathar
2026-02-16 04:20:25 +00:00
THARUN b55673bd76 Avoid ICE in From/TryFrom diagnostic under -Znext-solver 2026-02-15 19:02:44 +05:30
lapla 88f0ac34dc Fix const normalization for generic const items with trait assoc consts 2026-02-15 22:05:27 +09:00
Jacob Pratt 79adcd1375 Rollup merge of #150424 - xonx4l:suggest_param_env_shadowing, r=lcnr
diagnostics: add note when param-env shadows global impl

 This PR adds a diagnostics note when param-env shadows global impl as discussed in https://github.com/rust-lang/rust/issues/149910

It adds a note explaining that the definition is hidden by the generic bound.

r?lcnr
2026-02-14 23:17:30 -05:00
Yuki Okushi 71dff62449 Add a note about elided lifetime 2026-02-15 11:32:46 +09:00
Nicholas Nethercote 7c877d994b Remove DepContext.
It's no longer needed now that we can access `TyCtxt` directly.
2026-02-15 13:07:40 +11:00
xonx 1be41648d4 move and add comment 2026-02-14 21:32:57 +00:00
Jonathan Brouwer 018a5efcf7 Rename inline_fluent! to msg! 2026-02-14 13:47:52 +01:00
Jonathan Brouwer e91d02a8c3 Rollup merge of #152392 - TaKO8Ki:missing-generics-in-traits-used-in-const, r=jieyouxu
Fix ICE in supertrait_vtable_slot when supertrait has missing generics

Fixes rust-lang/rust#151330
2026-02-13 13:35:01 +01:00
Jonathan Brouwer f1b935d08f Rollup merge of #152356 - JonathanBrouwer:inline_diag4, r=jdonszelmann
Improve the `inline_fluent!` macro

For https://github.com/rust-lang/rust/issues/151366

This PR turns `inline_fluent!` into a proc macro, so we can run validation on the messages in this macro :)
I started a thread here because I don't like the name of the macro, but that's for a future PR: [#t-compiler > Bikeshed the new &#96;inline_fluent!&#96; macro](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Bikeshed.20the.20new.20.60inline_fluent!.60.20macro/with/572646242)
2026-02-13 13:35:01 +01:00