field "never read" warning for field that is used by derive(Debug)

[jkarneges]

I tried this code:

use std::str;

#[derive(Debug)]
enum ProcessError {
    Utf8(str::Utf8Error),
    Other,
}

impl From<str::Utf8Error> for ProcessError {
    fn from(e: str::Utf8Error) -> Self {
        Self::Utf8(e)
    }
}

fn process(data: &[u8]) -> Result<(), ProcessError> {
    let s = str::from_utf8(data)?;

    if s != "ok" {
        return Err(ProcessError::Other);
    }

    Ok(())
}

fn main() {
    println!("{:?}", process(&[0xff]));
}

I expected to see this happen: build cleanly

Instead, this happened:

warning: field `0` is never read
 --> src/main.rs:5:10
  |
5 |     Utf8(str::Utf8Error),
  |     ---- ^^^^^^^^^^^^^^
  |     |
  |     field in this variant
  |
  = note: `#[warn(dead_code)]` on by default
help: consider changing the field to be of unit type to suppress this warning while preserving the field numbering, or remove the field
  |
5 |     Utf8(()),
  |          ~~

Running the program shows the field is used:

Err(Utf8(Utf8Error { valid_up_to: 0, error_len: Some(1) }))

Meta

Rust version 1.77.0 (tested in playground)

[clubby789]

Derived code is intentionally ignored for dead code analysis - if you try just

use std::str;

#[derive(Debug)]
enum ProcessError {
    Utf8(str::Utf8Error),
    Other,
}

You'll get a note explaining this. The note doesn't seem to be attached for never read warnings, just never used

[jkarneges]

Ah, so it's intentional. Interesting. I assume the solution is to mark it with allow(dead_code) then.

[krtab]

@rustbot claim

[krtab]

@rustbot release-assignment
so @long-long-float can claim it

[rustbot]

Error: Parsing assign command in comment failed: ...'assignment' | error: expected end of command at >| ' so @long'...

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

[long-long-float]

@rustbot claim

[fjarri]

Note that while getting a warning if Debug is just derived but never explicitly used may be understandable (as discussed in other issues), you will get a warning if you do use it explicitly (see #123562) which, in my opinion, should not be the case.

[Noratrieb]

As mentioned above, the fix for this issue is adding a note about how derived traits are intentionally ignored, not to stop ignoring them.