-
Notifications
You must be signed in to change notification settings - Fork 13.3k
collect doc alias as tips during resolution #127721
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
base: master
Are you sure you want to change the base?
Conversation
In general I'd prefer to maybe not do this at all for the local crate. |
Agree and accept this suggestion. @rustbot ready |
This comment was marked as resolved.
This comment was marked as resolved.
@bvanjoi triage here, any interest in rebasing this? |
@bvanjoi |
Rebased. @rustbot ready |
This comment was marked as resolved.
This comment was marked as resolved.
Update: Fixes the incorrect submodule... |
This comment was marked as resolved.
This comment was marked as resolved.
Hi @estebank could you take a look at this when you get a chance? Thanks 🙂 |
Maybe r? @petrochenkov (or reroll)? |
} else { | ||
let mod_path = &path[..path.len() - 1]; | ||
if let PathResult::Module(ModuleOrUniformRoot::Module(module)) = | ||
self.resolve_path(mod_path, Some(TypeNS), None) |
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 don't think the logic is right, we are reporting an error for one specific unresolved segment in a path (and it's not necessarily the last one), not for all segments, and all segments before the one unresolved segment should be already resolved and recorded into partial_res_map
.
So
- no need to search candidates for all segments, only for the currently unresolved one
- no need to use
resolve_path
for the previous segments,partial_res_map
should already be filled.
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.
no need to search candidates for all segments, only for the currently unresolved one
I'm not sure what the point of 'all segments' is, because right now, it only searches in the module where the unresolved item is located.
Some changes occurred in compiler/rustc_attr_parsing |
@rustbot ready |
} | ||
} | ||
} else { | ||
let mod_seg = path[path.len() - 2]; |
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 unresolved segment is not necessarily last, index of the unresolved segment can be obtained using partial_res.unresolved_segments()
in smart_resolve_path_fragment
(or it's 0 if there is no partial resolution).
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 used an iterator for path segments because we cannot determine the position of the first unresolved segment in advance (meaning we don't know which item's unresolved_segment
property will be works).
} | ||
} | ||
} else { | ||
for (idx, seg) in path.iter().enumerate().rev().skip(1) { |
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.
Use skip(1)
because that the last segment must remain unresolved in the current logic, regardless of whether it's the first unresolved segment.
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.
Can you leave a comment to that effect? It's otherwise very opaque.
@rustbot ready |
Close #124273
Collect the symbol in the doc alias attributes and provide a tip when a match is found.
r? @estebank