-
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
Support ::crate
in paths
#45771
Support ::crate
in paths
#45771
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
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 left various requests around the tests, but my biggest concern is that crate::foo::bar
seems to parse in contexts where I would not expect it to.
src/libsyntax/ast.rs
Outdated
@@ -97,9 +97,12 @@ impl Path { | |||
} | |||
|
|||
pub fn default_to_global(mut self) -> Path { |
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.
Pre-existing, but I think a comment on this function would be great, just showing the transformations it does (and maybe explaining the reason for its existence).
src/libsyntax/parse/parser.rs
Outdated
!self.is_union_item() { | ||
!self.is_union_item() && | ||
!(self.token.is_keyword(keywords::Crate) && | ||
self.look_ahead(1, |t| t != &token::ModSep)) { |
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.
Nit: I feel like some comments would be nice here too. In fact, I personally am a bit confused about what's going on here. =) Lots of nested nots!
// Parse any path `foo::bar`. But be careful of various corner cases involving contextual keywords:
//
// - `union Foo { .. }`, a union item. This gets parsed below. Note that `union::foo` is a path.
// - Note that `crate::foo` *is* a path, but `crate` followed by any other token is not. (??)
I'm not entirely clear I guess on what is happening. =)
// http://rust-lang.org/COPYRIGHT. | ||
// | ||
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or | ||
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license |
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 we please collect the tests for this feature in some kind of directory named after the rfc? I would suggest {compile-fail,run-pass,ui}/rfc2126-crate-paths
.
pub struct Z; | ||
pub struct S1(crate (::m::Z)); // OK | ||
pub struct S2(::crate ::m::Z); // OK | ||
pub struct S3(crate ::m::Z); //~ ERROR undeclared type or module `crate` |
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.
Huh, this error seems to indicate that it is parsing a path crate::m::Z
which then fails to resolve... is that correct? If so, that seems sort of wrong, right? Today at least you get an error, and if we were going to favor any interpretation here, I would expect us to treat crate
as a visibility modifier (wasn't that the whole point of accepting ::crate
only?).
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.
Yes, crate ::m::Z
is parsed as a single path, I explained this choice in #45477 (comment).
FWIW, it's also the most conservative solution (since crate::anything::else
is an error).
wasn't that the whole point of accepting ::crate only?
I thought it was for teachability / symmetry with ::other_crate::x::y
(#44660 (comment)).
|
||
pub fn g() { | ||
use ::super::main; //~ ERROR global paths cannot start with `super` | ||
use ::super::main; //~ ERROR unresolved import `super` |
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.
Why the change to the error message here? Seems less good now.
|
||
#![feature(crate_in_paths)] | ||
|
||
use crate::m::f; |
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 we also test this from another module besides the root module?
} | ||
|
||
fn main() { | ||
f(); |
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.
Not that I think it's really needed, bu this test doesn't demonstrate that things resolved correctly in any way. Perhaps have f
and g
return values, and we can assert that you get the right thing back?
Hi from triage @petrochenkov — looks like you've got some grade-A feedback; will you be able to act on it soon? |
I'll address the comments tomorrow. |
Updated. |
☔ The latest upstream changes (presumably #45870) made this pull request unmergeable. Please resolve the merge conflicts. |
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.
Looks nice. Two more questions. =)
pub struct Z; | ||
pub struct S1(crate (::m::Z)); // OK | ||
pub struct S2(::crate ::m::Z); // OK | ||
pub struct S3(crate ::m::Z); //~ ERROR `crate` can only be used in absolute paths |
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 still a bit surprised that this doesn't work out with crate
being a visibility modifier. What is the reason for it not to parse that way?
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 answered this earlier (#45771 (comment)), but GitHub has hidden the message.
|
||
pub fn g() { | ||
use ::super::main; //~ ERROR global paths cannot start with `super` | ||
use ::super::main; //~ ERROR unresolved import `super` | ||
//~^ NOTE global paths cannot start with `super` |
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 notes are definitely an improvement -- but "unresolved import super
" still feels misleading to me. Among other things, super
is a keyword and hence could not possibly be an import, right? Can we readily change from adding a note to altering the main message?
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.
Done.
☔ The latest upstream changes (presumably #45905) made this pull request unmergeable. Please resolve the merge conflicts. |
Regarding the precedence of |
r=me post rebase |
@bors r=nikomatsakis |
📌 Commit 90f5cfd has been approved by |
FWIW, I still hope this never ends up on stable. |
☀️ Test successful - status-appveyor, status-travis |
Support `extern` in paths Implement the primary alternative to #46613 + #45771, achieving the same effect without requiring changes to other imports. Both need to be experimentally evaluated before making further progress. The PR also adds docs for all these related features into the unstable book. cc #44660 r? @nikomatsakis
cc #45477
Fixes #45229