Ignore derived Clone and Debug implementations during dead code analysis

[FabianWolff]

This pull request fixes#84647. Derived implementations of Clone and Debug always trivially read all fields, so "field is never read" dead code warnings are never triggered. Arguably, though, a user most likely will only be interested in whether their code ever reads those fields, which is the behavior I have implemented here.

Note that implementations of Clone and Debug are only ignored if they are #[derive(...)]d; a custom impl Clone/Debug for ... will still be analyzed normally (i.e. if a custom Clone implementation uses all fields of the struct, this will continue to suppress dead code warnings about unused fields); this seemed like the least intrusive change to me (although it would be easy to change — just drop the && [impl_]item.span.in_derive_expansion() in the if conditions).

The only thing that I am slightly unsure about is that in #84647, @matklad said

Doesn't seem easy to fix though :(

However, it was pretty straightforward to fix, so did I perhaps overlook something obvious? @matklad, could you weigh in on this?

[rust-highfive]

r? @lcnr

(rust-highfive has picked a reviewer for you, use r? to override)

[FabianWolff]

As an argument in favor of this pull request, it has already found a number of unused fields in the compiler code, breaking the bootstrap process. I have now sprinkled a few #[allow(dead_code)] (with comments) throughout the code to make it build again; of course, some of those fields actually should be dropped, but I lack the knowledge about how and where all of those structs are used to make this decision (perhaps instead of dropping the field, it should be used somewhere).

I would have preferred #[warn(dead_code)] instead of #[allow(dead_code)], but this does not work with -D warnings (it always emits errors, even with #[warn(...)], see #75668).

[cjgillot]

For compiler code, it would be better just to drop the fields. For tests, it may be preferrable to add a dummy let just to read the field.

[FabianWolff]

For compiler code, it would be better just to drop the fields.

I've dropped the unused fields from the compiler code now, except for the Error struct in compiler/rustc_mir/src/transform/coverage/mod.rs, where dropping the field amounts to dropping the whole struct:

rust/compiler/rustc_mir/src/transform/coverage/mod.rs

Lines 37 to 47 in 70e52ca

	/// A simple error message wrapper for `coverage::Error`s.
	#[derive(Debug)]
	structError{
	message:String,
	}
	implError{
	pubfnfrom_string<T>(message:String) -> Result<T,Error>{
	Err(Self{ message })
	}
	}

But the struct is used in various places where a Result is returned (e.g. here and here), so I only left a comment there for now.

[matklad]

However, it was pretty straightforward to fix, so did I perhaps overlook something obvious? @matklad, could you weigh in on this?

Looks like I was just mistaken, the impl looks ok to me.

One thing I worry is that, judging by the impact on rustc itself, this would be a noticable user-visible change (ie, big projects are guaranteed to get a couple instances of this at least). So it seems like some design process is needed here, culminating in an FCP.

I don't know whats the specific appropriate process here is, so let me tag a random t-compiled lead for this: @pnkfelix.

[bors]

☔ The latest upstream changes (presumably #85328) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #85335) made this pull request unmergeable. Please resolve the merge conflicts.

[lcnr]

I think this change makes sense. It does have some incorrect warnings if a struct adds a field solely for the sideeffects of that structs Clone impl, but that seems like a fine tradeoff to me.

It might also make sense to extend this to all impls with the syn::automatically_derived attribute. But the pattern of using fields for their behavior in derived impls is probably more prevalent for traits like Hash.

[lcnr]

nominated for @rust-lang/lang signoff

[scottmcm]

This seems good to me -- the compiler examples of how much this has been hiding is quite strong justification 👍

If a field is really only for a Clone side effect, it getting a _name to hide the warning seems totally fine.

One thing I was pondering: What it is about Clone and Debug specifically that makes it worth excluding them, but not others? Why wouldn't it make sense to also exclude a derived PartialEq, for example?

[matklad]

One thing I was pondering: What it is about Clone and Debug specifically that makes it worth excluding them, but not others?

Answer, as usual, history -- it was the two traits that preventing the useful unused warning from firing in the case which prompted me to crate the issue.

I think, if we are to do this, we should do this for all build-in derives at least.

[nikomatsakis]

I'm in favor of the concept, I think extending it to all automatically derived traits is pretty logical.

[FabianWolff]

Thanks for your comments everyone, and thanks for your review and suggestions @lcnr!

I have implemented them now, along with the suggestion to ignore all automatically derived impls, not just those of Clone and Debug. Predictably, this caused more warnings in the compiler and library code, and as it turned out, many of the fields now (correctly, when ignoring automatically derived impls) marked as "never read" are actually necessary. One example is ordering versions: The fields major, minor, and patch are never explicitly read, but versions are compared, so the fields do have an effect:

rust/compiler/rustc_attr/src/builtin.rs

Lines 597 to 601 in a5560a6

	if sess.assume_incomplete_release{
	rustc_version > min_version
	}else{
	rustc_version >= min_version
	}

I have prefixed such field names with underscores for now to silence the warning. I think that's acceptable, because the underscore makes explicit that the field is needed only for its "side-effects" (e.g. on ordering).

Also keep in mind that I have already removed most of the actually unnecessary fields in an earlier commit, so the above doesn't mean that this change causes unreasonably many false positives.

[richkadel]

It doesn't make sense (to me) to qualify the coverage::Error struct or field. The struct and the message field are used. If Rust thinks it isn't used, then something else is wrong with how this is being compiled.

If you must annotate it to workaround another problem, maybe you can add a FIXME comment with a bug ID, so this annotation can eventually be removed?

[joshtriplett]

I do think it's appropriate to exclude Debug and Clone and similar. However, I think PartialEq and PartialOrd are actually legitimate "uses" if and only if the instances are called. It's valid to have a struct with fields that are only used in equality/ordering comparisons, and nowhere else; I think those shouldn't need an underscore.

[nikomatsakis]

@joshtriplett

I think PartialEq and PartialOrd are actually legitimate "uses" if and only if the instances are called

Agree.

[nikomatsakis]

I hadn't actually looked at the diff before, but I agree that we need to be considering PartialEq, Hash, and friends as using the fields. I think a good goal for the PR should be that "no false warnings" and right now there are a lot, but almost all seem to be linked to PartialEq / Eq / Hash.

The case of the Error struct with the message field is interesting and a bit more complex.

[FabianWolff]

So should I go back to just Clone and Debug for now? Or should I keep the warning for all automatically derived traits except Eq, PartialEq, Ord, PartialOrd, and Hash?

[nikomatsakis]

I'm inclined to go back to an "opt-in" scheme, with just Clone and Debug. I'm trying to put my finger on what makes those traits different. I'd like to articulate the logic behind the heuristic. It seems to be just more true in practice that people rarely add fields "just for the purpose of cloning them or having the appear in debug output", although you can certainly imagine the latter (the former is a stretch, in my opinion-- though of course not impossible).

That said, this is only a lint. I think that both of those kinds of cases are ones where it'd be reasonable to put a comment explaining what the field is doing there

I think the difference with (e.g.) PartialEq is that you could be using the thing a a key in a BTreeMap, and therefore making use of those fields in a very intentional way.

[FabianWolff]

I'm inclined to go back to an "opt-in" scheme, with just Clone and Debug.

Thanks for the clarification! I have now gone back to just Clone and Debug again. I've also rebased and squashed my previous commits, so I'd say this is ready for re-review (@lcnr).

[nikomatsakis]

This is looking quite good to me. I'm going to go ahead and start an FCP merge.

@rfcbot fcp merge

[shepmaster]

I'd like to see an attribute on these derived impls

it'd be nice to have the code use a #[rustc_foo] attribute

Is there another issue I can follow to track the stabilization of this attribute? One of my crates uses derives to create structures and those structures effectively disable the dead code lint. I believe this attribute might help me in my case.