Support importing path-segment keyword with renaming

[mu001999]

Reference PR

• Clarify use $crate restriction reference#2010
• Document importing path-segment keyword 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}; (in edition 2015). These patterns are now explicitly allowed. For use {self}; and use ::{self} (in edition 2015) without renaming, the new clearer error suggests adding an explicit rename.

Future

We plan to remove error 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

[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.

[craterbot]

🎉 Experiment pr-146972-1 is completed!
📊 1 regressed and 0 fixed (1897 total)
📊 122 spurious results on the retry-regressed-list.txt, consider a retry¹ if this is a significant amount.
📰 Open the summary report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

Footnotes

1. re-run the experiment with crates=https://crater-reports.s3.amazonaws.com/pr-146972-1/retry-regressed-list.txt ↩

[mu001999]

Why did craterbot remove S-waiting-on-documentation?

@rustbot label +S-waiting-on-documentation

[petrochenkov]

Blocked on rust-lang/reference#2136.

[ehuss]

I haven't seen it mentioned here, but I just wanted to note a confusing inconsistency with super after self in a path. Usually super is allowed after self when referring to non-module items. However, it seems like it isn't allowed for a module. I'm not entirely certain that is the rule.

mod m {
    fn f() {}
    mod inner {
        // OK: imports f
        use self::super::f;
        // Ok
        use super as m_alias;
        // Error: `super` in paths can only be used in start position or after another `super`
        // Error message is confusing, because `self::super::f` was allowed.
        use self::super as m_alias2;
        // Same error as above.
        use self::super;
    }
}

Is the rule something like this?

If super is used after self, then it is not allowed to import to a module.

Is this intentional, or is there some issue for this?

[ehuss]

Not mentioned in the description is that the following is now allowed in 2015:

use ::{self as other}; // imports the crate root as other

Before this PR it was an error (error[E0431]: `self` import can only appear in an import list with a non-empty prefix)

It makes sense to me, but I haven't seen much edition-specific differences noted here.

[petrochenkov]

Is the rule something like this?

If super is used after self, then it is not allowed to import to a module.

The rule is "super in paths can only be used in start position or after another super" as the error message says.
If it's allowed elsewhere then I see it as a bug (hopefully, the current compiler's behavior is not documented in the reference), but this PR didn't touch any path resolution logic outside of imports to fix it.

[ehuss]

I was contrasting it with use self::super::f; where super is allowed after self.
The current documentation for super is here: https://doc.rust-lang.org/nightly/reference/paths.html#r-paths.qualifiers.super.allowed-positions where it says:

It may only be used in leading segments of the path, possibly after an initial self segment.

What I'm getting at is that the error message says "it can only be used after another super", but that seems to be missing "possibly after an initial self...sometimes".

[mu001999]

Is the rule something like this?

If super is used after self, then it is not allowed to import to a module.

Is this intentional, or is there some issue for this?

This is intentional in current impl of this PR (#146972 (comment)).

If it's allowed elsewhere then I see it as a bug

There are some usages of self::super::name in fact, quick search on github (https://github.com/search?q=self%3A%3Asuper+language%3ARust&type=code&l=Rust). I think we shouldn't treat such usages as bug, especially considering that we already documented such usage in reference (#146972 (comment)).

I think supporting this for importing super in this PR is reasonable.

[mu001999]

Not mentioned in the description is that the following is now allowed in 2015:

use ::{self as other}; // imports the crate root as other

Before this PR it was an error (error[E0431]: `self` import can only appear in an import list with a non-empty prefix)

It makes sense to me, but I haven't seen much edition-specific differences noted here.

Oh, yes, this is missed in the description. I will update the PR description. (Updated)

[traviscross]

@rfcbot concern self-super-behavior

It seems there are somewhat diverging answers here; let's hold this for a moment and review this question. I've renominated.

I haven't seen it mentioned here, but I just wanted to note a confusing inconsistency with super after self in a path. Usually super is allowed after self when referring to non-module items. However, it seems like it isn't allowed for a module. I'm not entirely certain that is the rule.

mod m {
    fn f() {}
    mod inner {
        // OK: imports f
        use self::super::f;
        // Ok
        use super as m_alias;
        // Error: `super` in paths can only be used in start position or after another `super`
        // Error message is confusing, because `self::super::f` was allowed.
        use self::super as m_alias2;
        // Same error as above.
        use self::super;
    }
}

Let's also explicitly consider the edition change for Rust 2015 that's part of this:

Not mentioned in the description is that the following is now allowed in 2015:

use ::{self as other}; // imports the crate root as other

Before this PR it was an error (error[E0431]: `self` import can only appear in an import list with a non-empty prefix)

[petrochenkov]

My opinion regarding self::super is the same as regarding something::self, we either need to support self and super in any positions in paths like . and .. in filesystem paths, or not support these random special cases just for bug compatibility.

[joshtriplett]

I just tested with current rust 1.93. The following code does not compile in any edition:

use ::{self as abc};

It gives E0431 in every edition. So, changing that to compile does not appear to be an edition-specific change.

Note that the following code does compile in every edition:

use std::{io::self as abc};
use std::io::{self as abcd}; 

[nikomatsakis]

Hmm. I read over the comments. My take is generally:

• I didn't realize we support use super and use self::super but I would expect them to be equivalent.
• I think it's fine for us to have special things like super that can only appear in the prefix; I do not think this means we have to support use foo::bar::super::baz, for the reasons we articulated before (it introduces ambiguity when foo::bar is a pub use about "which super" is intended).
• I do not understand the rationale for forbidding use self::super::bar from importing a module, near as I can tell that works on stable.