Remove importing suggestions when there is a shadowed typo candidate #120966
Conversation
rustbot
added
S-waiting-on-review
chenyukang
changed the title
| @@ -867,6 +875,7 @@ impl<'a: 'ast, 'ast, 'tcx> LateResolutionVisitor<'a, '_, 'ast, 'tcx> { | |||
| following_seg: Option<&Segment>, | |||
| span: Span, | |||
| base_error: &BaseError, | |||
| candidates: &mut Vec<ImportSuggestion>, | |||
There was a problem hiding this comment.
You need, at the very least, to add a comment above fn suggest_typo that describes in what scenarios the input candidates will be modified, and what kind of modification it will undergo.
From reading the code change here, this looks like a very blunt instrument of outright clearing the candidates in the presence of a shadowed name.
Are you planning on doing something more sophisticated to candidates in the long term (e.g. to still suggest some new imports that are based on some small revision to the given symbol)?
If that is not the case, and all you intend is to just clear the candidate set, I think this interface is more confusing than it needs to be. I would consider something else, e.g. returning something richer than a bool as the return value, and then letting the caller interpret that bool in deciding whether to return the candidates, or to return a fresh vec![].
There was a problem hiding this comment.
yes, &mut makes the functions harder to reason.
I think splitting out the code logic about suggesting shadowed names makes it more readable.
I updated the code and removed an outdated comment by the way.
// if we have suggested using pattern matching, then don't add needless suggestions
// for typos.
|
This also fixes #109950. |
| @@ -0,0 +1,5 @@ | |||
| use std::io::Read; | |||
|
|
|||
| fn f<T: Read, U, Read>() {} //~ ERROR expected trait, found type parameter `Read` | |||
There was a problem hiding this comment.
We could suggest explicitly qualifying Read here if feasible: T: std::io::Read or even T: self::Read to pick up the otherwise unused import item. cc #109950 (comment)
There was a problem hiding this comment.
seems it's hard to give a detailed suggestion to fix the code, for this case all these 3 scenarios will compile successfully:
fn f<T: self::Read, U, Read>() {} or
fn f<T: Read, U: Read>() {}or
fn f<T: Read, U>() {}
|
I don't have feedback beyond the request I wrote above regarding the change to function signature. @rustbot label: -S-waiting-on-review +S-waiting-on-author |
rustbot
added
S-waiting-on-author
chenyukang
force-pushed
the
yukang-fix-120599-resolve
branch
2 times, most recently
from
9461800
to
15f1cdc
Compare
This comment has been minimized.
This comment has been minimized.
chenyukang
force-pushed
the
yukang-fix-120599-resolve
branch
from
15f1cdc
to
d33cd2d
Compare
chenyukang
force-pushed
the
yukang-fix-120599-resolve
branch
from
d33cd2d
to
2a229c9
Compare
|
@rustbot ready |
rustbot
added
S-waiting-on-review
| @@ -8,11 +8,6 @@ LL | impl<T: Clone, Add> Add for Foo<T> { | |||
| | --- ^^^ not a trait | |||
There was a problem hiding this comment.
An aside: I'm realizing now, looking at the code in question (and confirmed by the first line of the description of issue #35987):
impl<T: Clone, Add> Add for Foo<T> { ... }that the most likely explanation for what has happened is that someone was trying to put both the Clone and Add bounds onto the type parameter T, and did not realize that the traits needed to be separated by + rather than ,.
In an ideal world, with full LLM linguistic modelling of the user's intent, we might hope to provide a hint that the comma, while syntatically correct, could instead have been a +.
(I know that Vadim already pointed out that the compiler "can't" complain about the comma in all cases, since it is syntactically correct there. I'm just saying to potentially give to the developer.)
|
@bors r+ rollup |
bors
added
S-waiting-on-bors
…llaumeGomez Rollup of 6 pull requests Successful merges: - rust-lang#120893 (Move some tests) - rust-lang#120966 (Remove importing suggestions when there is a shadowed typo candidate) - rust-lang#121035 (Format `async` trait bounds in rustfmt) - rust-lang#121075 (Fix false positive with if let and ranges) - rust-lang#121083 (Extend documentation for `Ty::to_opt_closure_kind` method) - rust-lang#121084 (Make sure `tcx.create_def` also depends on the forever red node, instead of just `tcx.at(span).create_def`) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#120966 - chenyukang:yukang-fix-120599-resolve, r=pnkfelix Remove importing suggestions when there is a shadowed typo candidate Fixes rust-lang#120559
Fixes #120559