Skip to content

Erase type params when suggesting fully qualified path #96347

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

Merged
merged 3 commits into from
Apr 30, 2022

Conversation

estebank
Copy link
Contributor

When suggesting the use of a fully qualified path for a method call that
is ambiguous because it has multiple candidates, erase type params in
the resulting code, as they would result in an error when applied. We
replace them with _ in the output to rely on inference. There might be
cases where this still produces slighlty incomplete suggestions, but it
otherwise produces many more errors in relatively common cases.

Fix #96292

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Apr 23, 2022
@rust-highfive
Copy link
Contributor

r? @cjgillot

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Apr 23, 2022
When suggesting the use of a fully qualified path for a method call that
is ambiguous because it has multiple candidates, erase type params in
the resulting code, as they would result in an error when applied. We
replace them with `_` in the output to rely on inference. There might be
cases where this still produces slighlty incomplete suggestions, but it
otherwise produces many more errors in relatively common cases.

Fix rust-lang#96292
@rust-log-analyzer

This comment has been minimized.

{
let mut eraser = TypeParamEraser(self.tcx);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if this is overkill, but we could know exactly what generic types need to be erased if we returned the impl's DefId from find_similar_impl_candidates instead of just the TraitRef, then we might just be able to use subst instead of erasing all type params

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 maybe, but that'd end up being a relatively larger change, right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, but it might allow us to erase fewer type variables when we're calling one generic method from another generic method with type variables.

but probably not worth the effort...

@cjgillot
Copy link
Contributor

r? @compiler-errors

@compiler-errors
Copy link
Member

For now this is fine!

@bors r+

@bors
Copy link
Collaborator

bors commented Apr 30, 2022

📌 Commit a721383 has been approved by compiler-errors

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 30, 2022
@bors
Copy link
Collaborator

bors commented Apr 30, 2022

⌛ Testing commit a721383 with merge 7c4b476...

@bors
Copy link
Collaborator

bors commented Apr 30, 2022

☀️ Test successful - checks-actions
Approved by: compiler-errors
Pushing 7c4b476 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 30, 2022
@bors bors merged commit 7c4b476 into rust-lang:master Apr 30, 2022
@rustbot rustbot added this to the 1.62.0 milestone Apr 30, 2022
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (7c4b476): comparison url.

Summary:

  • Primary benchmarks: no relevant changes found
  • Secondary benchmarks: mixed results
Regressions 😿
(primary)
Regressions 😿
(secondary)
Improvements 🎉
(primary)
Improvements 🎉
(secondary)
All 😿 🎉
(primary)
count1 0 2 0 2 0
mean2 N/A 0.4% N/A -0.3% N/A
max N/A 0.4% N/A -0.3% N/A

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

Footnotes

  1. number of relevant changes

  2. the arithmetic mean of the percent change

@estebank estebank deleted the issue-96292 branch November 9, 2023 05:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Inappropriate Self type name in "use the fully qualified path for the potential candidates" suggestion
8 participants