-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: dedup static_candidates
before report
#111872
Conversation
r? @jackh726 (rustbot has picked a reviewer for you, use r? to override) |
@@ -473,6 +473,9 @@ impl<'a, 'tcx> FnCtxt<'a, 'tcx> { | |||
let mut custom_span_label = false; | |||
|
|||
let static_candidates = &mut no_match_data.static_candidates; | |||
|
|||
static_candidates.dedup(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a comment why we cannot remove the duplicated call to record_static_candidate
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have two questions:
- 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
? - 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?
Thanks! |
Rollup of 7 pull requests Successful merges: - rust-lang#107916 (fix comment on Allocator trait) - rust-lang#111543 (Uplift `clippy::invalid_utf8_in_unchecked` lint) - rust-lang#111872 (fix: dedup `static_candidates` before report) - rust-lang#111955 (bootstrap: Various Step refactors) - rust-lang#112060 (`EarlyBinder::new` -> `EarlyBinder::bind`) - rust-lang#112064 (Migrate GUI colors test to original CSS color format) - rust-lang#112100 (Don't typecheck recovered method call from suggestion) r? `@ghost` `@rustbot` modify labels: rollup
Fixes #103646
record_static_candidate
had been executed twice, resulting in the presence of two identicalCandidateSource::Trait(Cat)
in static_candidates. This PR aims to deduplication thestatic_candidates
list, allowing it to executesuggest_associated_call_syntax
properly.