-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Clean up in intra-doc link collector #77743
Conversation
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.
cc @jyn514
I've found some parts of the code are hard to follow so I've done some cleanups, but it's not a thorough one. I don't really want to change anything big to not cause conflicts with ongoing PRs.
Can you remove the first commit? I don't think this depends on #77700 in any way. |
@jyn514 your test case can't compile, because /// [true] //~ ERROR ambiguous
pub mod true {} Rustc recommends me r#-ing it, but then the test case |
When you say passes, you mean it warns that it's an ambiguous link? |
For context, this is teh current error on master:
|
31291db
to
5574fa0
Compare
Hmm, now try adding the disambiguator:
That goes through |
Well I added code to test for true and false, it's just uses |
I don't think we should separate |
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.
Thanks for working on this :)
Res::Def(DefKind::AssocTy, _) => false, | ||
if let Ok(res) = result { | ||
match res { | ||
Res::Def(DefKind::AssocFn | DefKind::AssocConst, _) => { |
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 starting to wonder if traits_implemented_by
is actually necessary ... do we already have the info here?
Related: #74489 (comment). Maybe rustc_resolve
handles inherent impls but not anything else? @petrochenkov might know.
Anyway, not your problem to solve.
fn is_bool_value(path_str: &str, ns: Namespace) -> Option<(&'static str, Res)> { | ||
if ns == TypeNS && (path_str == "true" || path_str == "false") { | ||
Some(("bool", Res::PrimTy(hir::PrimTy::Bool))) | ||
} else { | ||
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.
This looks a little out of place now that it's in its own function ... I'm starting to wonder if ollie was right in #75101 (comment).
Anyway, not your problem, the implementation looks fine.
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.
Maybe we should support docs for keywords? :) /s
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.
On second (and third) thought, is it correct to handle true and false as an alias of bool? They are values, not types, up until the point when somebody defines something else called true. But in that case, couldn't the built-in resolution handle them?
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.
That's a separate policy decision that shouldn't happen here. I don't have a strong opinion either way, but if you want to change it please open a separate issue so we can discuss it separate from the implementation.
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.
couldn't the built-in resolution handle them?
They're not really values, they're keywords. Typeck handles them specially IIRC.
e532eb5
to
5c916d0
Compare
The idea behind the I did not do this using purely equivalent transformations - instead of checking if we have a primitive, we first try to resolve the path instead, and only check primitiveness if we found a mod. I'm not sure if this can cause issues, but if it does, then the test suite does not cover it. |
0b50831
to
4a22a57
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.
Last few nits :) overall looks good
let ty_res = if let Some(ty_res) = is_primitive(&path_root, TypeNS) | ||
.map(|(_, res)| res) | ||
.or_else(|| self.resolve_path(&path_root, TypeNS, module_id)) |
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.
After my spiel about separating refactors and changes, I don't want to make the change here, but I don't think these are both necessary:
let ty_res = if let Some(ty_res) = is_primitive(&path_root, TypeNS) | |
.map(|(_, res)| res) | |
.or_else(|| self.resolve_path(&path_root, TypeNS, module_id)) | |
// FIXME: are these both necessary? | |
let ty_res = if let Some(ty_res) = is_primitive(&path_root, TypeNS) | |
.map(|(_, res)| res) | |
.or_else(|| self.resolve_path(&path_root, TypeNS, module_id)) |
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.
In the strictest sense, they are, because removing is_primitive breaks tests, because modules aren't getting resolved. But even adding is_primitive back, it's only the modules that are called the same as the primitives that are... I wonder if this is because otherwise we'd end up returning early out of resolve()
?
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.
Let's fix this in a follow-up.
nit: Can you squash the commits a little more? No need to bring it down to one, but it would be nice not to have ' Undo the behaviour change while keeping most of the stylistic ones ' in the git history. Either way, r=me. @bors delegate=bugadani |
✌️ @bugadani can now approve this pull request |
I agree, but that is the trickiest commit to squash in the whole bunch because the changes are mixed with the str->symbol ones :) I'll see what I can do |
Ok, no need then. @bors r+ |
📌 Commit d4c51b88f558ce4f38f0a4aae09a8fd8a1f055ce has been approved by |
Sorry for the last force push but it doesn't hurt if the patch builds. Also squashed the nasty bits. 2 in 1, but should be fine now! |
@bors r+ |
📌 Commit 46f183bf523d7ee2ead49b0c6f3e51290a63ff8e has been approved by |
☔ The latest upstream changes (presumably #76934) made this pull request unmergeable. Please resolve the merge conflicts. Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
|
Rebased @bors r+ |
📌 Commit 725e3d1 has been approved by |
☀️ Test successful - checks-actions, checks-azure |
@bugadani small note - r+ marks you as the approver, please use r=jyn514 next time. Not a big deal though. |
Whoops, sorry about that. Is there a bors users' manual somewhere? :) Actually, I found it here: https://buildbot2.rust-lang.org/homu/ |
This PR makes the following changes in intra-doc links:
check_full_res
true
andfalse
need to be resolved separatelyCloses #77267 (cc @Stupremee)
r? @jyn514