-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Improve suggestions for importing out-of-scope traits reexported as _
#91412
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @jackh726 (or someone else) soon. Please see the contribution instructions for more information. |
What about |
I don't think this factors in |
☔ The latest upstream changes (presumably #91354) made this pull request unmergeable. Please resolve the merge conflicts. |
ab9cd46
to
4a1b1b3
Compare
☔ The latest upstream changes (presumably #91491) made this pull request unmergeable. Please resolve the merge conflicts. |
4a1b1b3
to
906787b
Compare
(rebased onto master) |
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'm not really familiar with this code and not comfortable doing a final review, but I left some initial comments.
return Ok((self, false)); | ||
} | ||
} else { | ||
// FIXME(compiler-errors): What if we don't have an item corresponding to our |
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.
Good question, is there a test case that covers this case?
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 previous logic didn't do anything, and it's just a missing diagnostic, right? Maybe we could emit a note that the thing is unimportable?
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.
Yeah, this is more like the visible_parent
for the item doesn't actually contain the item at all. This is actually probably a bug!
(e.g. maybe the visible_parents_map
has a bug).
if let Some(reexport) = reexports | ||
.into_iter() | ||
.find(|child| child.vis.is_public() && child.ident.name != kw::Underscore) | ||
.map(|child| child.ident.name) |
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.
Do we actually need to collect into a vec?
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.
Good point. Probably not.
r? rust-lang/compiler Not really familiar with this area. |
Maybe we should allow But that's a language change, we can do the suggestion logic first, as this PR does. |
906787b
to
682a342
Compare
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.
Addressed comments.
@rustbot label -S-waiting-on-author +S-waiting-on-review
return Ok((self, false)); | ||
} | ||
} else { | ||
// FIXME(compiler-errors): What if we don't have an item corresponding to our |
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.
Yeah, this is more like the visible_parent
for the item doesn't actually contain the item at all. This is actually probably a bug!
(e.g. maybe the visible_parents_map
has a bug).
if let Some(reexport) = reexports | ||
.into_iter() | ||
.find(|child| child.vis.is_public() && child.ident.name != kw::Underscore) | ||
.map(|child| child.ident.name) |
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.
Good point. Probably not.
@bors r+ rollup |
📌 Commit 682a342 has been approved by |
…askrgr Rollup of 7 pull requests Successful merges: - rust-lang#90345 (Stabilise entry_insert) - rust-lang#91412 (Improve suggestions for importing out-of-scope traits reexported as `_`) - rust-lang#91770 (Suggest adding a `#[cfg(test)]` to to a test module) - rust-lang#91823 (Make `PTR::as_ref` and similar methods `const`.) - rust-lang#92127 (Move duplicates removal when generating results instead of when displaying them) - rust-lang#92129 (JoinHandle docs: add missing 'the') - rust-lang#92131 (Sync rustc_codegen_cranelift) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
It wasn't benchmarked because it was rolled up. The rollup PR mentioned above was benchmarked |
parent_map
query to prefer visible parents that don't export items with the name_
.kw::Underscore
._
, but I think that's desirable here too (or else we get suggestions for paths likea::_::b
like in this doctest example).try_print_visible_def_path
if thedef_id
is re-exported as_
, which will fall back to printing the def-id's real (definition) path.use
ing paths that are private anyways. See this doctest example for demonstration of current behavior.my_library::prelude::*
) if the trait in question is only pub-exported as_
, as a fallback.I was somewhat opinionated about behaviors in this PR, and I'm totally open to limiting the impact of my changes or only landing parts of this. Happy to receive feedback if there are better ways to the same end.
Fixes #86035