Support importing path-segment keyword with renaming

[mu001999]

Reference PR:

• Clarify use $crate restriction reference#2010

Description:

• Make imports consistent, self/super/crate/$crate can be imported with renaming now
  • Allow use self/super/crate/$crate as name; and also use super/crate/$crate::{self as name};
  • Deny use self/super/crate/$crate; and also use super/crate/$crate::{self};
  • Deny use ::self;, use ::{self};, use ::self as name; and use ::{self as name};
• Proper error messages, and E0430 and E0431 are no longer emitted now
  • [E0430]: self import can only appear once in an import list was emitted before when std::fmt::{self, self}, but the emitted [E0252]: the name fmt is defined multiple times is good enough
  • [E0431]: self import can only appear in an import list with a non-empty prefix was emiited before when use {self as name};, now use {self as name}; is allowed; for use {self};, it's denied because it lacks renaming and will emit imports need to be explicitly named with suggesting renaming.

Fixes #29036
Fixes #35612
Fixes #37156
Fixes #146967
Fixes #149811

r? petrochenkov

[rustbot]

Failed to set assignee to [petrochenkov]: invalid assignee

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

[traviscross]

Thanks to @mu001999 for putting this forward and to @petrochenkov for supporting this. This makes sense to me. I propose that we do it, and I'll then file a concern we discussed in the meeting (thanks @Nadrieril) about documentation.

@rfcbot fcp merge lang

[rust-rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

Concerns:

• consistent-axioms (Support importing path-segment keyword with renaming #146972 (comment))
• documentation (Support importing path-segment keyword with renaming #146972 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[traviscross]

@rfcbot concern documentation

The linked Reference PR (rust-lang/reference#2010) is a minor clarification. Let's please go ahead and also make a Reference PR documenting the rules described in this stabilization report.

[tmandry]

@rfcbot reviewed

[nikomatsakis]

@rfcbot concern consistent-axioms

I am a bit confused by why we would make errors in some of these cases and also the overall philosophical approach.

In particular I expect as an "axiom" that, for all $path, the following should EITHER both work OR both error:

use $path::{self};
use $path::self;

...but the PR description suggests that where use foo::{self} would work but use foo::self would not. I understand why the latter would be discouraged (with a lint) but I think it should be allowed. I can imagine code generators or macros wanting to add self or wanting to be able to simplify a {identifier} to identifier without having to special-case self.

My rule of thumb is that the language should accept things that have only one obvious meaning but, if they seem "redundant" or may suggest a broken mental model for users, issue a lint.

Thinking over my model for how this works, I think of it like this...

• an import path has two things: (a) the absolute path and (b) optionally, a name;
• something like use foo::bar has (a) the absolute path foo::bar with (b) the name bar
• $path::self is "identity", it preserves both
• self, super, crate, and $crat, when used as the prefix of a path, expand to (a) the absolute path you'd expect but (b) no name.
• it is an error to import something with no name without a use.

This implies that e.g. use super is an error but use super as X, use super::{self as X} and use super::self as X should all work.

[petrochenkov]

@nikomatsakis
Right now the model is that self in use prefix::{self as name}; is not a part of the path, but rather a part of the braced import {...} syntax.
This self is never resolved as a name, but gets rewritten into use prefix as name instead.
So it could e.g. use some non-keyword operator instead (use prefix::{<- as name} or something).
This PR continues to follow that model.

We could certainly extend the language to make it a part of the path, but then I'd rather support self and super in all positions in paths, like . and .. are supported everywhere in filesystem paths.
If this is a desirable direction, then this PR could bring back the support for use std::{io::self} (without extending it), and unbreak most of the regressions.

[rust-bors]

☔ The latest upstream changes made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #150682) made this pull request unmergeable. Please resolve the merge conflicts.

[rust-bors]

☔ The latest upstream changes made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #150729) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[nikomatsakis]

Hi @petrochenkov ...

We discussed this in the lang-team meeting. Some notes from our discussion:

Right now the model is that self in use prefix::{self as name}; is not a part of the path, but rather a part of the braced import {...} syntax.

I see. This makes sense from that point-of-view, but I think the meeting consensus was that most users wouldn't see it that way, but rather that a syntax like use prefix::{$a, $b, $c} should work the same where ${a,b,c} are identifiers or the self keyword.

(We did briefly consider something like the keyword you suggested or use prefix::{as name}, but I think nobody particularly liked it.)

We could certainly extend the language to make it a part of the path, but then I'd rather, like . and .. are supported everywhere in filesystem paths.

We discussed this. Meeting consensus is that this is an orthogonal extension -- i.e., it's "consistent" to say that "if you can put it in braces, it should behave like other identifiers" and also say "...and you cannot use super or crate except at the start of a path".

We felt the stronger case for allowing self and super to appear anywhere was the idea of macros that may wish to concatenate paths (e.g., use foo::super::bar). (This would also argue for crate.)

But after more discussion, we realized that supporting "backward relative operations" like super/crate adds a key bit of complexity when it comes to pub use -- imagine you have pub use a::b as foo and we have use foo::super::bar, is that equivalent to crate::a::bar or crate::bar.

The meeting consensus was that this is definitely orthogonal (i.e., we don't have to support super and crate in the middle of a path just because we support it at the beginning); that the stronger case is around conatenation (except that it breaks); and therefore some serious skepticism about this as a feature.

If this is a desirable direction, then this PR could bring back the support for use std::{io::self} (without extending it), and unbreak most of the regressions.

Yes, we all agree this falls out from the axioms I laid out and out to work and be equivalent to use std::io;

In summary:

Meeting consensus points

• Let's not worry about super and crate in paths here;
• I think we had a consensus that self ought to be treated like a "special identifier" that can appear at the end of any paths and is normalized away (with warnings) versus making hard errors.

I realize we did not discuss something like use foo::self::bar. I personally think it's fine, but I don't think it's required to support it and I'd be inclined not to add it unless we have a strong case for it.

[petrochenkov]

I'd rather keep this PR doing what it does (i.e. bugfixing), modulo unbreaking the previously supported use std::{io::self} cases.
The larger language extension (supporting self at the end of paths) can be landed separately.

[joshtriplett]

(Deleted my comment that was redundant with @nikomatsakis's summary.)

[joshtriplett]

Being explicit about something: we'd still love to see lints for cases like redundant use of ::self, even though we don't want to see them become hard errors as was originally proposed.

(Those lints don't have to be in this PR, either.)