Support trailing `self` in paths by mu001999 · Pull Request #152996 · rust-lang/rust

mu001999 · 2026-02-23T01:16:34Z

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

Trailing self can appear in paths (as the consensus in Support importing path-segment keyword with renaming #146972 (comment))
E0429 will be no longer emitted, use ...::self [as target]; will be equivalent to use ...::{self [as target]};
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 · 2026-02-23T14:45:29Z

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 · 2026-02-23T14:54:27Z

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? 🤔

rustbot · 2026-02-25T14:43:19Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

petrochenkov · 2026-02-25T14:48:18Z

compiler/rustc_resolve/src/build_reduced_graph.rs

-                        ident = Ident::new(source.ident.name, self_span);
-                    }
-                }
+                    Ident::new(parent.ident.name, self_span)


So things like foo::self::self are still unsupported and will be reported by UnnamedImport.
Seems fine for a start.

Also, use foo::self::self as name is probably supported now, right?

Updated, use foo::self::self; is allowed.

petrochenkov · 2026-02-25T14:49:12Z

compiler/rustc_resolve/src/diagnostics.rs

        let mut span = binding_span;
        match import.kind {
-            ImportKind::Single { type_ns_only: true, .. } => {
-                suggestion = Some(format!("self as {suggested_name}"))


What is this change responsible for?

Without this, use foo::self; will have wrong suggestion use self as other_foo;. With this we will get use foo::self as other_foo; correctly

petrochenkov · 2026-02-25T14:52:43Z

compiler/rustc_resolve/src/ident.rs

-                    return Ok(module.self_decl.unwrap());
+                if ns == TypeNS {
+                    if ident.name == kw::SelfLower {
+                        return Ok(module.self_decl.unwrap());


Hmm, why doesn't this enable paths like foo::self in non-import positions?
Is there some separate check in resolve_path or similar reporting an error for this case?

Yes, resolve_path_with_ribs will check any path-kw used in the middle

Seems we can support foo::self in non-import paths if we remove that check for self at last position.

Updated, foo::self is allowed in non-import positions now.

petrochenkov · 2026-02-25T16:45:19Z

(I just hope force pushes won't break the perf run.)

rust-bors · 2026-02-25T16:53:37Z

☀️ Try build successful (CI)
Build commit: a35a6e8 (a35a6e89bc39ea2ad9cbed9dd69128944a2930fa, parent: 3f9853562c73af38a5e6af8b0da1b2734a327e19)

mu001999 · 2026-02-25T17:04:53Z

I will remove type_ns_only if the perf run doesn't show perf regression. (if it run successfully)

rust-timer · 2026-02-25T18:06:27Z

Finished benchmarking commit (a35a6e8): comparison URL.

Overall result: ✅ improvements - no action needed

Benchmarking this pull request means it may be perf-sensitive – we'll automatically label it not fit for rolling up. You can override this, but we strongly advise not to, due to possible changes in compiler perf.

@bors rollup=never
@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.2%	[-0.2%, -0.2%]	2
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (secondary -7.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-7.8%	[-7.9%, -7.7%]	2
All ❌✅ (primary)	-	-	0

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 480.701s -> 480.064s (-0.13%)
Artifact size: 397.77 MiB -> 395.76 MiB (-0.50%)

…-self, r=JonathanBrouwer Remove redundant self usages Extracted from rust-lang#152996. r? petrochenkov

mu001999 · 2026-02-26T00:48:29Z

Cool, seems the perf run shows no perf regression, so maybe I could remove the type_ns_only? Or still keep it in current implementation, how do you think about it?

…-self, r=JonathanBrouwer Remove redundant self usages Extracted from rust-lang#152996. r? petrochenkov

mu001999 · 2026-02-26T04:11:54Z

@rustbot ready

rustbot assigned petrochenkov Feb 23, 2026