Repository navigation
Add lints for all common traits #58066
Description
The interoperability API guidelines suggest that all of the following traits should be eagerly implemented for types where it's appropriate:
CopyCloneEqPartialEqOrdPartialOrdHashDebugDisplayDefault
Both Debug and Copy have corresponding missing_${TRAIT}_implementations lints in rustc for checking that they exist. These lints have recently become of interest for libc because of RFC2235. However, since some of these traits rely on manual implementations, it'd be useful to have lints to fail CI should any desired lints be missed in a PR.
Given that two of these lints already exist and the API guidelines lay out a clear standard practice, I'm not certain if an RFC is required to add the rest of these lints, so I'm raising this issue. My plan is to work through adding the lints for Clone, Eq, Hash, and PartialEq, as they're required for rust-lang/libc#1217.
Activity
Susurrus commentedon Feb 2, 2019
cc @gnzlbg
Susurrus commentedon Feb 2, 2019
Note that Clippy has discussed adding some of these same lints in rust-lang/rust-clippy#1798
scottmcm commentedon Feb 3, 2019
This makes we want to be able to say
impl !Eq for f32;as a way to say "no, I really don't want that and never will" without having to allow the lint on those types.gnzlbg commentedon Feb 4, 2019
I think these lints belong in clippy more like in rustc, as in they catch a bad idiom, instead of something that's "inheretely dangerous" or that can lead to incorrect programs (e.g. missing a trait impl, as long as you don't use it, isn't really that big of a deal).
Susurrus commentedon Feb 4, 2019
@gnzlbg I've been wondering if these should go in Clippy versus here in Rust, but since the lints for
DebugandCopyalready exist in rustc, that'd it'd make sense to put them all here. I can't think of a reason that these types should be split between rustc and clippy, however, so what do we do with the existingDebugandCopylints? Should I reimplement all of this in clippy and propose removing them from rustc? Is removing an allow-by-default lint backwards a reasonable thing to do?gnzlbg commentedon Feb 4, 2019
I don't know why these lints are in rustc and not clippy - @oli-obk might know ? Maybe the reason is only historical (clippy did not exist back then when these were added).
oli-obk commentedon Feb 5, 2019
The reason definitely is historical. If we move the existing lints to clippy, then we should figure out the transition story. I think it would be fine to just deprecate the lints and move them to clippy entirely.
Susurrus commentedon Feb 8, 2019
Hmm, this is a pain, we now have 3 separate conversations going on about this in three separate locations. The big issue I have right now is this (quoted from #8070):
If I could get rough consensus that adding those traits is appropriate, I can alter #58070 to just add those
lang_items and mark these lints as deprecated. Then I can finish my PR for Clippy, which I haven't submit yet. I'm trying to reduce the amount of code I write that then gets thrown away.RodBurman commentedon Mar 8, 2026
This issue seems to have been forgotten for 7 years, does anyone have knowledge of its current state? Can we close it?