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)

[rperier]

Renaming the fonction to note_impl_ambiguous_trait() . What about the rest ? Do you want that I investigate something ?

[lcnr]

Suggested change

	fn note_impl_ambiguous_trait(
	fn note_different_trait_with_same_name(

[lcnr]

Can you change this to a FIXME and explicitly mention FnCtxt::detect_and_explain_multiple_crate_versions_of_trait_item 🤔

I don't really understand when this doesn't trigger but the method one does 🤔 I feel like the method one is just a subset of the above note and should be removed 🤔

moving this to zulip https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/.28PR.20.23144674.29.20Merge.20multiple.20suggestions.20into.20a.20single/with/536652274

[rperier]

So to continue the discussion, as dicussed on zulip , by disabling detect_and_explain_multiple_crate_versions_of_trait_item (it returns false) and updating note_different_trait_with_same_name (the new note_version_mismatch) my suggestion is emitted in tests/run-make. But only for E0599 , not for E0277. for E0277 the old disabled suggestion "note: there are multiple different versions of crate dependency in the dependency graph" is still shown... Suppose that depending on the constrainst on the instanciated DiagCtxt (when instanciating the err) the span_note might be attached or ignored for a given error... let's admit that... but how is it technically possible to still see the message ? It is disabled in the code... I think I need help to understand this

[rperier]

The other CCed PR, is quit similar no ? ^^

[rperier]

@rustbot ready

[rperier]

So I have basically no ideas why the output of the compiler is not completly updated when I disable the suggestion in detect_and_explain_multiple_crate_versions_of_trait_item . So I propose to merge this PR like this, and refactorize merge with the note in rustc_hir_typeck in a second time (I can add this to my TODO list).

EDIT: see #t-compiler/help > (PR #144674) Merge multiple suggestions into a single @ 💬

I am gonna to test by removing the 3nd diagnostic

@rustbot author

[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]

@rustbot ready

This is a proposal of a first refactoring. I have voluntarily kept things simple, so it is maintainable. The idea being to not report exactly the same messages as before, but to report a single diagnostic about possible different crate versions instead, and this in all cases. Otherwises, in the other case, if we find another trait with the same name and the same "interface", which is implemented by the Ty, we report a similarly named trait. I am opened to suggestions.

[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

[lcnr]

if you've always returning false if the argument is None, i generally prefer doing this in the caller. Is this method call code even reachable? I remember you saying that even replacing it with a panic never triggers?

[rperier]

This is reachable by the error E0599 "no method named foo found for struct dep_2_reexport::Typein the current scope" from the test tests/run-make/crate-loading/multiple-dep-versions

[lcnr]

when is self.tcx.crate_name(trait_def_id.krate) == krate && self.tcx.item_name(trait_def_id) == name false but self.tcx.def_path_str(trait_def_id) == required_trait_path holds?

[rperier]

It used by tests/ui/traits/bound/same-crate-name.rs , disabling this case makes the test fail.

[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.