Support trailing self in paths

[mu001999]

View all comments

As a follow-up PR to #146972, after this PR:

1. Trailing self can appear in paths (as the consensus in Support importing path-segment keyword with renaming #146972 (comment))
2. E0429 will be no longer emitted, use ...::self [as target]; will be equivalent to use ...::{self [as target]};
3. Things like struct S {}; use S::{self as Other}; will be rejected

---

This PR used to add a new lint redundant_self, which would lint use ...::self [as target]; and use ...::{self [as target]};, and the last commit fixes all warnings emitted by this lint.

But this lint and clippy lint unnecessary_self_imports have some overlap. And use std::io::self; is not equivalent to use std::io in fact for now, the new lint will also cause the following known issue:

Removing ::{self} will cause any non-module items at the same path to also be imported. This might cause a naming conflict (rust-lang/rustfmt#3568).

So I removed this lint, and I think what it does should be done by extending the clippy lint unnecessary_self_imports.

r? petrochenkov

[petrochenkov]

It looks like #146972 (comment) suggests to support trailing self in all paths, not just import paths. We can start with import paths if that's more convenient though.

However, if we are doing it, then I think it's time to abandon the whole "self rewriting" hack, and just properly resolve self inside modules.

[mu001999]

It looks like #146972 (comment) suggests to support trailing self in all paths, not just import paths.

Semantics of trailing self in import paths, like use foo::self;, is explicit and same to use foo::{self};, and this will require foo is in type namespace. So I think trailing self in import paths is usefull to replace use foo::{self}; when we want to import only items in type namespace.

But what will trailing self in non-import paths be? Do we need things like Foo::self? 🤔

[mu001999]

@rustbot ready

[petrochenkov]

Why? The normalization of foo::self to foo was removed, and I think we shouldn't do any other kind of "overwriting" either, only resolution.

The check is "only first and last segments can be self", and it can be checked without normalization, and self::self passes it too.
(It can be checked in one place too, now the error is split into two.)

[mu001999]

But use foo::self::self; will be accepted

[petrochenkov]

foo::self::self has self that is not first and not last, so it doesn't pass the check and shouldn't be accepted.

[mu001999]

In resolve_path_with_ribs, the path will be foo::self not foo::self::self, so the second self would be the last one when checking "only first and last segments can be self".

[mu001999]

use foo::self::self will have module_path = foo::self and source = self, although we have abandoned the "self rewriting" hack

[mu001999]

@rustbot review

[mu001999]

@rustbot author

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