fix: dedup static_candidates before report

[bvanjoi]

Fixes #103646

record_static_candidate had been executed twice, resulting in the presence of two identical CandidateSource::Trait(Cat) in static_candidates. This PR aims to deduplication the static_candidates list, allowing it to execute suggest_associated_call_syntax properly.

[rustbot]

r? @jackh726

(rustbot has picked a reviewer for you, use r? to override)

[cjgillot]

Could you add a comment why we cannot remove the duplicated call to record_static_candidate?

[bvanjoi]

inherent and extension may append the same item to static_candidates.

For example:

trait Cat { fn nya() {} } fn uwu<T: Cat>(c: T) { c.nya(); }

Both <T as Cat> (inherent) and <_ as Cat> (extension) had been tried.

And another:

trait Cat { fn nya() {} } fn uwu<T>(c: T) { c.nya(); }

<_ as Cat> (extension) should be tried.

Therefore, we can't remove duplicated call of record_static_candidate.

[cjgillot]

The comment you added says that in order to improve the diagnostic, we record both inherent and extension cases. But this PR does the opposite: we deduplicate to improve the diagnostic.
You don't need to link to the PR. The 2 lines-long explanation is enough.

[bvanjoi]

I have two questions:

1. Is it correct to say that we cannot remove the duplicated call of record_static_candidate? Also, is it intended behavior that the unexpected diagnostic of Unhelpful help when calling associated trait function as method #103646 was caused by invoking record_static_candidate for the same item in both assemble_extension_candidates_for_trait and assemble_inherent_impl_probe?
2. Is static_candidates.dedup() the right approach here? If this statement has too broad impact, can we change the condition to !self.has_applicable_self(&item) && !self.static_candidates.contains(&item) in extension_candidates?

[cjgillot]

Thanks!
@bors r+

[bors]

📌 Commit f78369b has been approved by cjgillot

It is now in the queue for this repository.