Unexpected warning about unused assignment in Rust 1.92 and newer

[Tiwalun]

Code

I tried this code, which is using the docsplay crate:

#[derive(docsplay::Display)]
pub enum DocsplayError {
    /// Use field a: {a}, but not b.
    A { a: usize, b: usize },
    /// Generic error in a tuple
    B(usize),
}

I expected to see this happen:

This code should compile, and no warning should be shown.

Instead, this happened:

I get a warning about an unused assignment:

warning: value assigned to `b` is never read
 --> src/lib.rs:4:19
  |
4 |     A { a: usize, b: usize },
  |                   ^
  |
  = help: maybe it is overwritten before being read?
  = note: `#[warn(unused_assignments)]` (part of `#[warn(unused)]`) on by default

This is unexpected, because there is no visible assignment anywhere. The expanded code for the macro looks like this:

// Expanded version of above code

pub enum DocsplayErrorExpanded {
    /// Use field a: {a}, but not b.
    A { a: usize, b: usize },
    /// Generic error in a tuple
    B(usize),
}
impl ::core::fmt::Display for DocsplayErrorExpanded {
    fn fmt(&self, formatter: &mut ::core::fmt::Formatter) -> ::core::fmt::Result {
        #[allow(unused_imports)]
        use ::docsplay::{DisplayToDisplayDoc, PathToDisplayDoc};
        #[allow(unused_variables)]
        match self {
            Self::A { a, b } => formatter.write_fmt(format_args!(
                "Use field a: {0}, but not b.",
                (&(a)).__displaydoc_display(),
            )),
            Self::B(_0) => formatter.write_fmt(format_args!("Generic error in a tuple")),
        }
    }
}

There is #[allow(unused_variables)], which means that the unused field b does not trigger that warning, but it is unexpected that the unused_assignments warning is triggered.

Version it worked on

It most recently worked on: 1.91

Version with regression

rustc --version --verbose:

rustc 1.92.0 (ded5c06cf 2025-12-08)
binary: rustc
commit-hash: ded5c06cf21d2b93bffd5d884aa6e96934ee4234
commit-date: 2025-12-08
host: x86_64-unknown-linux-gnu
release: 1.92.0
LLVM version: 21.1.3

Also seems to happen on the latest nighly,, rustc 1.95.0-nightly (eda76d9d1 2026-01-21).

Backtrace

Backtrace

<backtrace>

[eggyal]

searched nightlies: from nightly-2025-06-01 to nightly-2026-01-22
regressed nightly: nightly-2025-10-13
searched commit range: be0ade2...2300c2a
regressed commit: ff6dc92

bisected with cargo-bisect-rustc v0.6.11

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --start=2025-06-01 

[Jarcho]

The relevant output of the derive is approximately:

match self {
    Self::A { a, b } => {
        write!(f, "Use field a: {a}, but not b")
    },
    ...
} 

The span of the b identifier in the pattern is the same as the span in the declaration so it's not considered to be from an expansion. I haven't checked what the b pattern has as a span.

---

A roughly equivalent macro_rules macro would define the simple case as approximately Self::$var_name { $($field_names),* } => { write!(f, $msg) }. Note that this ends up with the lint span on $field_names, but I think that's some macro_rules span magic.

[eggyal]

@rustbot label:+L-unused_assignments

[eggyal]

Since there is actually an unused assignment (albeit one that also triggers the unused_variable lint), I'm not sure whether it's correct (and therefore should also be emitted when expanded/not generated by a proc-macro) or not (and therefore should not be emitted when generated by a proc-macro)?

unused_assignments should not be triggered here.

rust/compiler/rustc_mir_transform/src/liveness.rs

Lines 1077 to 1079 in 1655912

	/// Second, report unused assignments that do not correspond to initialization.
	/// Initializations have been removed in the previous loop reporting unused variables.
	fn report_unused_assignments(self) {

@rustbot claim
@rustbot label:-regression-untriaged +regression-from-stable-to-stable

[apiraino]

Assigning priority (discussion on #t-compiler/prioritization/alerts > #151514 Unexpected warning about unused assignment in Rust … @ 💬)

regressed in #142390

cc @cjgillot

@rustbot label -I-prioritize +P-high -needs-triage