Add a diagnostic for similarly named traits

[rperier]

cc #133123

This is a first proposal, suggestions are welcome

[rustbot]

r? @lcnr

rustbot has assigned @lcnr.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

This PR modifies run-make tests.

cc @jieyouxu

[rperier]

Fixed by using predicate_must_hold_modulo_regions

[rperier]

The current version is the following. I no longer browse the impls, so it is no longer per impl. It's mostly working (other::Trait or other::Trait<T> are working), however I still get weird behaviours with super traits and the GenericArgs . That's why I did not push the commit yet, some tests are broken, I am investigating.

UPDATE: switch to the last commit directly and see update below regarding generics and ICE

pub(crate) fn suggest_impl_similarly_named_trait(
        &self,
        err: &mut Diag<'_>,
        obligation: &PredicateObligation<'tcx>,
        trait_predicate: ty::PolyTraitPredicate<'tcx>,
    ) {
        let trait_def_id = trait_predicate.def_id();
        let trait_name = self.tcx.item_name(trait_def_id);
        if let Some(other_trait_def_id) = self.tcx.all_traits_including_private().find(|def_id| {
            if trait_def_id != *def_id && trait_name == self.tcx.item_name(def_id) {
                if let Some(pred) = self.tcx.predicates_of(*def_id).instantiate(self.tcx, trait_predicate.skip_binder().trait_ref.args).predicates.iter().find(|clause| {
                    clause.as_trait_clause().map_or(false, |trait_clause| trait_clause.def_id() == *def_id)
                })
                {
                    let pred = pred.as_trait_clause().unwrap();
                    self.predicate_must_hold_modulo_regions(&Obligation::new(
                        self.tcx,
                        obligation.cause.clone(),
                        obligation.param_env,
                        pred,
                    ))
                } else {
                    false
                }
            } else {
                false
            }
        }) {
            err.note(format!(
                "`{}` implements similarly named `{}`, but not `{}`",
                trait_predicate.self_ty(),
                self.tcx.def_path_str(other_trait_def_id),
                trait_predicate.print_modifiers_and_trait_path()
            ));
        }
        ()
    }

[rperier]

This is another proposal, feedbacks are welcomed. I am not convinced about the part regarding the generic args. The idea being that you cannot select a similarly named trait with different generics (or different constraints), it does not makes sense and might cause ICE.

[rperier]

This is another proposal, I have simplified the code. This is to show you the code before I merge it with the other suggestion. I have to analyze the other suggestion you were talking about and try to merge my code with it now.

[lcnr]

the impl lgtm now, I don't think we should have these two similar suggestions however (similarly named trait vs similarly named trait from different crate version), and believe they should be merged into 1

[rperier]

OK, thanks for your feedbacks. I will merge with the other suggestion and fix param.kind during the weekend

[rperier]

Merged into the suggestion we have discussed above. I have kept each note/notice independent, because I have the feeling that the three notes/notices might still be emitted independently when you think about it. You might have similarly named traits within the same crate but also in different crates. You might have cases when similarly named traits are found but not traits with the same path (this is typically the case in some ui tests)

[lcnr]

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[rperier]

@lcnr I am a bit confused because we have:

• "there are multiple different versions of crate {krate} in the dependency graph" , in rustc_hir_typeck

and

• "perhaps two different versions of crate {trait_crate} are being used?", in rustc_trait_selection

which one are we talking about ? both ? Because currently my suggestion in the note_version_mismatch() function (into rustc_trait_selection). I can easily be exclusive with the second one (as I am in the same function), the first suggestion being inside another compiler crate. There is way to know that a suggestion was already emitted from another compiler crate ? (rustc_hir_typeck in our case)

[lcnr]

❤️

maybe even split the function into two sub-functions here

• check_same_trait_different_version
• check_same_name_different_path

and only call teh second one if the first one didn't say anything

View changes since this review

[rperier]

Fixed, see the replies to your questions above

[bors]

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

[rperier]

Fixed the merge conflicts and the remark about:

let Some(rcvr_ty) = rcvr_ty else {
    return;
}

[rperier]

A first proposal by using ExternCrateSource::Extern. What do you think ?

[rperier]

Fixed by adding "you can use cargo tree to explore your dependency tree" at the end of the diagnostic. I have also introduced a new generic function check_same_definition_different_crate, so I can merge the following diagnostic https://github.com/rust-lang/rust/blob/master/compiler/rustc_trait_selection/src/error_reporting/infer/mod.rs#L218 with mine. What do you think ?

[lcnr]

nits, otherwise sgtm :> cool that's you're deduplicating these functions now

View changes since this review

[rperier]

OK cool, I will take into account your feedbacks this weekend (vacations)

[bors]

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

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[rperier]

Fixed merge conflicts, and I took your comments into accounts.