Conversation
The previous wording for this restriction was pretty confusing to me. I don't remember what I was thinking when I wrote it, and I can't find any historical explanation either. `use` paths can use `$crate` as long as they have more than one segment (`use $crate::foo` is obviously OK). I have rewritten this to make it clear it is specifically about `use $crate`. One could say that restriction is already covered by the previous point that says `use crate;` requires an `as`, but for some reason `use $crate as foo` doesn't work either. So I have left this as a separate rule for now. cc rust-lang/rust#146972 (comment) for context.
|
Opening as a draft because I'm wondering how intentional this is. |
|
cc @yaahc |
|
https://github.com/yaahc/rust/blob/adaa838976ff99a4f0661136322f64cb466b58a0/compiler/rustc_resolve/src/build_reduced_graph.rs#L630-L631 is the logic that controls this, it doesn't make a carveout for renaming imports but it doesn't mention them either so I'm not positive if that means it was intended to also disallow this case. rust-lang/rust#45846 is the PR where this logic was introduced. I did a quick search of the discussion on this PR and the associated PR, tracking issue, and RFC (discussion and content) and honestly couldn't find any mention of the $crate syntax at all outside of the PR diff itself. If I had to guess I'd assume this was probably an oversight. @petrochenkov's comment rust-lang/rust#35612 (comment) seems to support this theory. much better example: rust-lang/rust#146972 (comment) |
…ate, r=petrochenkov Support importing path-segment keyword with renaming *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/146972)* #### Reference PR - rust-lang/reference#2010 - rust-lang/reference#2136 #### Description This PR unifies and extends the behavior of importing path-segment keywords (`crate`/`$crate`/`super`/`self`), resolving several long-standing inconsistencies. Previously, Rust only allowed `use crate as name;` without renaming support for other path keywords. This PR enables importing these keywords with explicit renaming. And it also denies importing these keywords without renaming. ##### What's now allowed For **`crate`** and **`$crate`**: - `use crate as name;` - `use crate::{self as name};` - `use $crate as name;` - `use $crate::{self as name};` For **`super`** (including chained `super::super`): - `use super as name;` - `use super::{self as name};` - `use super::super as name;` - `use super::super::{self as name};` For **`self`**: - `use self as name;` - `use self::{self as name};` ##### Removed error codes Two error codes are no longer emitted: - **E0430**: Previously emitted for duplicate `self` imports like `std::fmt::{self, self}`. The existing E0252 ("name defined multiple times") provides sufficient guidance. - **E0431**: Previously emitted for `use {self [as name]};` and `use ::{self [as name]};`. These patterns are now allowed or denied but with new clearer errors. - For `use {self as name};` and `use ::{self as name};` (in edition 2015), they are allowed now and equivalent to `use crate as name`; - For `use {self};` and `use ::{self};` (in edition 2015) without renaming, they are equivalent to `use crate;`, the new clearer error suggests adding an explicit rename. - For `use ::{self [as name]};` after edition 2015, it is equivalent to `use ${extern-prelude} [as name];`, it is denied with new errors. ##### Future We plan to remove error [E0429](https://doc.rust-lang.org/stable/error_codes/E0429.html#error-code-e0429) and support `self` at the end of paths (rust-lang#146972 (comment)). This language extension and lint for redundant `::self` instead of hard error `E0429` will be landed separately in the future. --- Fixes rust-lang#29036 Fixes rust-lang#35612 Fixes rust-lang#37156 Fixes rust-lang#146967 Fixes rust-lang#149811 r? petrochenkov
Rollup merge of #146972 - mu001999-contrib:fix/use-dollar-crate, r=petrochenkov Support importing path-segment keyword with renaming *[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/146972)* #### Reference PR - rust-lang/reference#2010 - rust-lang/reference#2136 #### Description This PR unifies and extends the behavior of importing path-segment keywords (`crate`/`$crate`/`super`/`self`), resolving several long-standing inconsistencies. Previously, Rust only allowed `use crate as name;` without renaming support for other path keywords. This PR enables importing these keywords with explicit renaming. And it also denies importing these keywords without renaming. ##### What's now allowed For **`crate`** and **`$crate`**: - `use crate as name;` - `use crate::{self as name};` - `use $crate as name;` - `use $crate::{self as name};` For **`super`** (including chained `super::super`): - `use super as name;` - `use super::{self as name};` - `use super::super as name;` - `use super::super::{self as name};` For **`self`**: - `use self as name;` - `use self::{self as name};` ##### Removed error codes Two error codes are no longer emitted: - **E0430**: Previously emitted for duplicate `self` imports like `std::fmt::{self, self}`. The existing E0252 ("name defined multiple times") provides sufficient guidance. - **E0431**: Previously emitted for `use {self [as name]};` and `use ::{self [as name]};`. These patterns are now allowed or denied but with new clearer errors. - For `use {self as name};` and `use ::{self as name};` (in edition 2015), they are allowed now and equivalent to `use crate as name`; - For `use {self};` and `use ::{self};` (in edition 2015) without renaming, they are equivalent to `use crate;`, the new clearer error suggests adding an explicit rename. - For `use ::{self [as name]};` after edition 2015, it is equivalent to `use ${extern-prelude} [as name];`, it is denied with new errors. ##### Future We plan to remove error [E0429](https://doc.rust-lang.org/stable/error_codes/E0429.html#error-code-e0429) and support `self` at the end of paths (#146972 (comment)). This language extension and lint for redundant `::self` instead of hard error `E0429` will be landed separately in the future. --- Fixes #29036 Fixes #35612 Fixes #37156 Fixes #146967 Fixes #149811 r? petrochenkov
The previous wording for this restriction was pretty confusing to me. I don't remember what I was thinking when I wrote it, and I can't find any historical explanation either.
usepaths can use$crateas long as they have more than one segment (use $crate::foois obviously OK).I have rewritten this to make it clear it is specifically about
use $crate. One could say that restriction is already covered by the previous point that saysuse crate;requires anas, but for some reasonuse $crate as foodoesn't work either. So I have left this as a separate rule for now.cc rust-lang/rust#146972 (comment) for context.