trait_added_supertrait
should eventually use importable paths, not supertrait names
#922
Labels
trait_added_supertrait
should eventually use importable paths, not supertrait names
#922
Due to #638, the
trait_added_supertrait
lint (#441, #892) is unable to do precise-enough analysis of foreign traits, and can have both false positives and false negatives.Foreign crate's supertrait
An easy false-negative is the case where a foreign crate's supertrait is added:
We can't see the info for
another_crate
so this bound is "invisible" tocargo-semver-checks
. There's a limited exception for common built-in traits (Debug, Clone, Send, Sync, PartialOrd, Ord, PartialEq, Eq, Hash, UnwindSafe, RefUnwindSafe, Unpin, Sized
) which we "manually inline" to make them available for analysis. But any other trait bound on another crate's trait is invisible.Name comparisons
The best way to currently implement the
trait_added_supertrait
lint is by comparing supertrait names (theImplementedTrait.name
property. This is insufficiently precise, and the correct way (blocked by #638) would be to goImplementedTrait -> Trait -> ImportablePath
and compare based on those names instead.Here's a false-negative caused by this problem:
The newly-defined local
Debug
trait here has the same name asstd::fmt::Debug
(so the lint won't trigger), but obviously isn't the same trait.Here's a false-positive caused by the same problem:
Here, the trait isn't named the same across old & new, but is the same trait since it's available at the same importable path.
The text was updated successfully, but these errors were encountered: