Check uniqueness of impl items by trait item when applicable.

[cjgillot]

When checking uniqueness of item names in impl blocks, we currently use the same definition of hygiene as for toplevel items. This means that a plain item and one generated by a macro 2.0 do not collide.

This hygiene rule does not match with how impl items resolve to associated trait items. As a consequence, we misdiagnose the trait impls.

This PR proposes to consider that trait impl items are uses of the corresponding trait items during resolution, instead of checking for duplicates later. An error is emitted when a trait impl item is used twice.

There should be no stable breakage, since macros 2.0 are still unstable.

r? @petrochenkov
cc @RalfJung

Fixes #71614.

[petrochenkov]

I need to refresh hygiene details in my memory before reviewing this PR and #99445, I'll try to do it some time during the next couple of weeks.

[petrochenkov]

Let's focus on trait impls first (as opposed to inherent impls).

Names in a trait impl (trait impl items) are considered uses referring to their definitions in the trait.
So they are resolved as uses - code in fn check_trait_item does it manually, but it should be equivalent to resolve_ident_in_module (with the trait being the module).

This PR doesn't change that scheme.
So I guess for traits we can check both completeness of trait items (that should consider specialization?) and the lack of duplicates in the same place, using only their DefIds obtained early during name resolution and not names.

[petrochenkov]

As for inherent items, I don't think something like enforce_impl_items_are_distinct makes sense for them.
We need an additional overlap check to catch cases like

impl S { fn f() {} }
impl S { fn f() {} }

as well, so the same overlap check should be able to report

impl S {
    fn f() {}
    fn f() {}
}

too.

What should be considered a duplicate in this case (in presence of macros 2.0), I'm honestly not sure.
Inherent impl items are themselves definitions unlike trait impl items, so they should use the normalize_to_macros_2_0 approach to duplicates, but inherent impls for the same type can also be defined in totally different contexts (parent modules and expansions), how that fact affects the comparison?
I suggest just using whatever the overlap check uses now.
(And also splitting the changes for trait impls and inherent impls to 2 different PRs.)

@rustbot author

[cjgillot]

@petrochenkov I split the PR in 2 parts.
This PR keeps the change for trait impl items.
#102856 moves the check for duplicate inherent impl items work with overlap check.

[petrochenkov]

PR description also needs an update.
@rustbot author

[petrochenkov]

r=me after squashing commits.
@rustbot author

[cjgillot]

@bors r=petrochenkov

[bors]

📌 Commit 152cd63 has been approved by petrochenkov

It is now in the queue for this repository.