`dead_code` in 1.77 lints against tuple fields with Drop implementations and suggests removing them
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 119k
- Forks
- 16.1k
- PR merge metrics
- PR metrics pending
Description
Code
I tried this code:
struct SignificantDrop {
a: usize,
}
impl Drop for SignificantDrop {
fn drop(&mut self) {
println!("Doing something important to {}", self.a);
}
}
struct OwnsResource(usize, SignificantDrop);
fn main() {
let s = OwnsResource(17, SignificantDrop { a: 999 });
println!("{}", s.0);
}
Current output
field `1` is never read
`#[warn(dead_code)]` on by default (rustc dead_code)
─────────────────────────────────────────────────────────────────────────────
field in this struct (rustc dead_code)
─────────────────────────────────────────────────────────────────────────────
consider changing the field to be of unit type to suppress this warning while
preserving the field numbering, or remove the field: `()` (rustc dead_code)
Desired output
If the unused field has a drop implementation it should at least not suggest removing it entirely. I'm not sure what the best option is. For private types converting it to a struct and naming the field with an underscore works, but that doesn't work for public types.
Rationale and extra context
I use this pattern in a few cases in GUI code to ensure that an event handler is cleaned up when the containing tuple gets dropped. I can avoid the finding, but if I had just accepted the suggestion I'd have accidentally cleaned up my event handlers.
Other cases
For a struct the output is a more reasonable field b is never read (rustc dead_code) without a suggestion to remove it. I think this could, still, benefit from detecting if Drop is implemented since it might have side effects.
struct OwnsResourceTwo {
a: usize,
b: SignificantDrop,
}
Rust Version
rustc 1.77.0 (aedd173a2 2024-03-17)
binary: rustc
commit-hash: aedd173a2c086e558c2b66d3743b344f977621a7
commit-date: 2024-03-17
host: x86_64-unknown-linux-gnu
release: 1.77.0
LLVM version: 17.0.6
Anything else?
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the dead_code lint with the tuple and struct examples using rustc 1.77. Start at the compiler's dead_code lint and suggestion handling; done means the lint no longer suggests removing or unit-typing a field whose type has a Drop implementation, while preserving appropriate diagnostics for other unused fields.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 40/100