field is never read warning doesn't consider Drop implementation

[lvella]

Code

struct PrintOnDrop(&'static str);
impl Drop for PrintOnDrop {
    fn drop(&mut self) {
        println!("{}", self.0);
    }
}

pub struct A {
    act_on_drop: PrintOnDrop,
}

impl A {
    pub fn new(msg: &'static str) -> A {
        A {
            act_on_drop: PrintOnDrop(msg),
        }
    }
}

Current output

warning: field `act_on_drop` is never read
 --> <source>:9:5
  |
8 | pub struct A {
  |            - field in this struct
9 |     act_on_drop: PrintOnDrop,
  |     ^^^^^^^^^^^
  |
  = note: `#[warn(dead_code)]` on by default

warning: 1 warning emitted

Compiler returned: 0

Desired output

Nothing.

Rationale and extra context

Since the struct A is public and constructible, the compiler should assume that the drop for all its Drop fields will be called, which in this case makes the issued warning wrong.

Other cases

No response

Anything else?

Tested on 1.70.0 and on today's nightly (398fa21 2023-06-03).

[SkiFire13]

There's a thin line here between what's technically correct and what's useful.

Would you also expect this to not throw a warning?

pub struct Foo {
    pub bar: String
}

After all String does has drop glue that ultimately call a Drop implementation, it would be more useful to detect cases like this as unused. A way to do this is pretend that values are never used only for their destructor side-effects, even though this is sometimes the case like in your example.

[lvella]

There's a thin line here between what's technically correct and what's useful.

Would you also expect this to not throw a warning?

pub struct Foo {
    pub bar: String
}

After all String does has drop glue that ultimately call a Drop implementation, it would be more useful to detect cases like this as unused. A way to do this is pretend that values are never used only for their destructor side-effects, even though this is sometimes the case like in your example.

Well, not a good example, because the field is pub so there isn't a warning. But point taken: having a field just for its drop is an exceptional case.

[Noratrieb]

I think we should err on the side of false positives here. For your case, you can just #[allow] (and soon, #[expect]) the lint on the field. This also makes the code clearer by telling the reader that the field is indeed just here for its drop.

[asquared31415]

the compiler should assume that the drop for all its Drop fields will be called

This is not strictly true because mem::forget, Box::leak, Rc cycles, etc.