Add #[rustc_edition_redirect] by Amanieu · Pull Request #160227 · rust-lang/rust

Amanieu · 2026-07-30T17:28:13Z

This implements the compiler portion of the library API evolution project goal by adding the #[rustc_edition_redirect] attribute. This attribute allows an item path in the standard library to be redirected to a different item when used from a crate with an older edition.

This PR only implements the compiler portion and doesn't make any use of this in the standard library. However I do have a POC branch which replaces the edition-specific panic! dispatching with this.

Example

// std
pub struct Older;
pub struct Old;
pub struct Current;
#[rustc_edition_redirect = "2018"]
pub use Older as Current;
#[rustc_edition_redirect = "2021"]
pub use Old as Current;

// 2024 edition crate
use std::Current; // resolves to Current

// 2021 edition crate
use std::Current; // resolves to Old

// 2018 edition crate
use std::Current; // resolves to Older

Semantics

#[rustc_edition_redirect = "EDITION"] is only allowed on a single-item use.
The annotated import is resolved and checked like an ordinary import, but does not introduce its alias while compiling the defining crate. Instead, it is attached as an edition-dependent alternative to the ordinary item or re-export with the same name and namespace.
Every redirect requires a default item with the same name and visibility.
Multiple redirects may be attached to the same default item, but duplicate edition boundaries are rejected.
When an external name is looked up, the first redirect whose boundary is later than the edition of the lookup span is selected. If none applies, the default item is used.
The edition comes from the span performing the lookup, so macro-generated identifiers retain the edition of their originating macro.
Redirect selection applies to explicit paths, ordinary and glob imports, #[macro_use], and prelude lookup.
Redirects are consumed by the first cross-crate lookup. If another crate re-exports the result, that re-export is fixed according to the edition of the re-exporting crate; redirect metadata is not propagated further.
Since redirect targets are ordinary re-exports, normal visibility, stability, and import checks apply.

Implementation

Attribute parsing records only the edition boundary; the redirect target is the target of the annotated use.
Redirect imports participate in normal import resolution, but their aliases are not planted into the defining module.
After import resolution reaches its fixed point, redirects are grouped with their default declarations and checked for a missing default, duplicate boundaries, and visibility mismatches.
Resolved redirects are stored as part of ModChild in crate metadata.
External name-resolution paths use redirect-aware accessors which select a declaration using the edition of the lookup span.

Open questions

This is currently gated under edition_redirect without a tracking issue. Does this need a separate tracking issue?
Do we need a way to automatically propagate redirects through re-exports? Currently this must be done manually when re-exporting through core/alloc/std.
Are ordinary re-export privacy and stability rules sufficient for legacy redirect targets that should not otherwise appear in the current-edition API?
This redirect is currently not shown in rustdoc at all. Ideally we would want a note that links to what this resolves to in older editions.

r? petrochenkov

rustbot · 2026-07-30T17:28:17Z

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann, @JonathanBrouwer

Some changes occurred in compiler/rustc_hir/src/attrs

cc @jdonszelmann, @JonathanBrouwer

mejrs

I can review the attribute portion of this.

Multiple attributes are allowed with different before keys. The oldest one that applies is selected.

Given that it's an internal attribute it's not so important, but another option is a range syntax to force unambiguity (error on overlapping ranges):

#[rustc_edition_redirect(during = "..=2018", target(oldest_module))]
#[rustc_edition_redirect(during = "2021..=2024", target(middle_module))]
pub mod redirected_module { }

View changes since this review

petrochenkov · 2026-07-31T12:30:51Z

@bors try @rust-timer queue

Add #[rustc_edition_redirect]

petrochenkov · 2026-07-31T14:05:38Z

Given that this is a major expansion to name resolution, it's not surprising that I don't like it :)
My goal here will be making it less major while trying to still satisfy the library goals, perhaps at cost of some reduced ergonomics.

Some initial ideas:

#[rustc_edition_redirect] is effectively a second reexport system parallel to the regular reexports, it even has to duplicate some reexport checks like "too private to reexport".
I would prefer the "redirects" to reuse actual reexports, like
```
#[rustc_edition_redirect = <edition_info>]
use RedirectTarget as Name;
```
This would be resolved and checked exactly like a regular reexport, except it wouldn't plant Name into the current module to avoid conflicts.
This will also allow to avoid resolving paths inside built-in attributes, something that was deliberately avoided so far.
Second, #[rustc_edition_redirect = ...] attributes on a single item should be able to give a precise list of editions they target, in isolation.
So we don't need to find the full set of items with redirects and the same name and check how their edition ranges overlap to get the edition list.
Right now name resolution works the same in the local crate and in other crates, this feature as implemented breaks that invariant, but it would be good to keep it, or produce errors in cases where the resolution would works differently.
#[rustc_edition_redirect = ...] use RedirectTarget as Name; could actually plant the Name into the current module if the rustc_edition_redirect matches the current local edition.
Third, is it possible to get rid of the "some crates propagate redirects, and some do not" feature, and always either propagate or not? Perhaps at cost of some mild inconveniences in the standard library?
In any case, right now the choice shouldn't be made by looking at whether feature(edition_redirect) is enabled or not, a missing feature is not supposed to change behavior, only to report a non-fatal error and then continue as usual. Another crate-level attribute gated by rustc_attrs would work instead (#[rustc_preserve_edition_redirects] or something).

I'll need to think about this more in the background for some time.

rust-bors · 2026-07-31T14:35:53Z

☀️ Try build successful (CI)
Build commit: 1b93257 (1b9325785afb0e4413270e6bc497cf74b4bddc70)
Base parent: 922325b (922325bb13bfea5b41454318563f2a65e83c2336)

rust-timer · 2026-07-31T16:14:55Z

Finished benchmarking commit (1b93257): comparison URL.

Overall result: ❌✅ regressions and improvements - please read:

Benchmarking means the PR may be perf-sensitive. It's automatically marked not fit for rolling up. Overriding is possible but disadvised: it risks changing compiler perf.

Next, please: If you can, justify the regressions found in this try perf run in writing along with @rustbot label: +perf-regression-triaged. If not, fix the regressions and do another perf run. Neutral or positive results will clear the label automatically.

@bors rollup=never rustc-perf
@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.4%	[0.2%, 0.7%]	49
Regressions ❌ (secondary)	0.4%	[0.1%, 1.0%]	50
Improvements ✅ (primary)	-0.4%	[-0.4%, -0.4%]	3
Improvements ✅ (secondary)	-0.1%	[-0.1%, -0.1%]	2
All ❌✅ (primary)	0.4%	[-0.4%, 0.7%]	52

Max RSS (memory usage)

Results (primary 0.8%, secondary 1.5%)

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

	mean	range	count
Regressions ❌ (primary)	0.8%	[0.5%, 1.3%]	18
Regressions ❌ (secondary)	2.0%	[0.4%, 10.6%]	39
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.1%	[-4.5%, -0.6%]	4
All ❌✅ (primary)	0.8%	[0.5%, 1.3%]	18

Cycles

Results (primary 0.1%, secondary -0.1%)

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

	mean	range	count
Regressions ❌ (primary)	1.0%	[0.5%, 2.4%]	5
Regressions ❌ (secondary)	1.7%	[0.4%, 6.1%]	23
Improvements ✅ (primary)	-1.4%	[-2.3%, -0.7%]	3
Improvements ✅ (secondary)	-4.7%	[-9.2%, -2.0%]	9
All ❌✅ (primary)	0.1%	[-2.3%, 2.4%]	8

Binary size

Results (primary 0.3%, secondary 0.1%)

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

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.0%, 0.9%]	64
Regressions ❌ (secondary)	0.1%	[0.0%, 0.5%]	30
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[0.0%, 0.9%]	64

Bootstrap: 490.333s -> 491.013s (0.14%)
Artifact size: 392.58 MiB -> 390.64 MiB (-0.50%)

Amanieu · 2026-07-31T22:10:18Z

@petrochenkov Can you give more concrete examples of what you are proposing? You seem to be saying that we should just have multiple items with the same name in the same namespace with a different edition filter on them. I think that would be more complex and intrusive than the current solution.

#[rustc_edition_redirect = "2024"]
use RedirectTarget2024 as Name;
#[rustc_edition_redirect = "2021"]
use RedirectTarget2021 as Name;
#[rustc_edition_redirect = "2018"]
use RedirectTarget2018 as Name;

The current system is much simpler: there is only one name per namespace and you can attach any number of edition redirects on that name:

#[rustc_edition_redirect(before = "2024", target(RedirectTarget2024)]
#[rustc_edition_redirect(before = "2021", target(RedirectTarget2021)]
#[rustc_edition_redirect(before = "2018", target(RedirectTarget2018)]
struct Name;

That way all the redirection metadata for one name is available on the single ModChild for that name.

Third, is it possible to get rid of the "some crates propagate redirects, and some do not" feature, and always either propagate or not? Perhaps at cost of some mild inconveniences in the standard library?

In theory yes, we could manually add edition redirect attributes on every re-export of an item that has redirects. But that would just end up being completely equivalent to what the current implementation is doing, while being more error-prone since we may accidentally forget redirects in some places.

In any case, right now the choice shouldn't be made by looking at whether feature(edition_redirect) is enabled or not, a missing feature is not supposed to change behavior, only to report a non-fatal error and then continue as usual.

There's quite a few places in the compiler where we change global behavior depending on whether a feature is enabled. For example stage_api forces all public items to have stability attributes. I feel that what I am doing is not too different, and in any case this feature is only intended for use in the standard library and tests.

petrochenkov · 2026-08-06T16:25:53Z

Here's some minimized version that I came up with today - petrochenkov@2659b90.
(It needs a further refactoring, but the "name resolution logic" part is minimized.)
In this version I actually have some confidence.

Initially I wanted to limit all the edition-based dispatch to one place in resolve_ident_in_extern_module_non_globs_unadjusted, to make it truly cross-crate only.
For this the "propagation of redirects through imports" had to be removed, because it brings the edition-based dispatch into the current crate in a complicated way which is error-prone and in which I had no confidence.

But then I realized that one place in resolve_ident_in_extern_module_non_globs_unadjusted is still error-prone, because any code that uses self.resolutions(...) or self.resolution(...).non_glob_decl can easily get the non-redirected version of the extern declaration using the same key!

So I hid the NameResolution structure into a module and made the non_glob_decl field private, and added methods that ensure that we either get the redirected version of the binding (fn non_glob_decl_redir), or panic if the redirect set is non-empty (fn non_glob_decl).
With this all the tests pass except these cases that test the "redirect propagation" specifically.
(I think it's better if we instead do stuff like this explicitly in the standard library for now.)

    // tests\ui\edition-redirect\basic.rs
    let _: ExpectedScopedRedirected = edition_redirect::ScopedRedirected;
    let _: edition_redirect::same_redirects::Item = ExpectedRedirectedUse;

    // tests\ui\edition-redirect\reexport.rs
    let _: reexport_preserving::Item = reexport_source::current();
    let _: reexport_preserving::Child = reexport_source::current_child();

All the other things work correctly because the correct redirects are fetched in resolve_ident_in_extern_module_non_globs_unadjusted, resolve_glob_import, and for_each_child_mut (for macro_use), and then automatically propagate through all the following imports, etc.

rustbot · 2026-08-17T21:59:45Z

Some changes occurred in compiler/rustc_attr_ir

cc @jdonszelmann, @JonathanBrouwer

Amanieu · 2026-08-17T22:39:29Z

@petrochenkov I applied your changes on top of mine and then had an LLM audit every single code path that ends up calling non_glob_decl. This exposed some issues that are addressed in the latest commit:

We need redir and non-redir versions of for_each_child, depending on the caller's context. Notably, add_module_candidates and lookup_import_candidates_from_module.
Diagnostic lookups need to use the redir version because they may be looking up an item in the standard library that has redirects. The non-redir version panics if it is called on a decl with redirects.
The per-module trait cache needs to be keyed by edition because the set of available traits in a module may depend on the edition used to do a lookup into that module. This is relevant when resolving a trait through the prelude, which (unlike glob imports) performs the resolution using the edition of the place it is used rather than the edition of the glob import itself.

Tests were added for all of these issues. However I'm not 100% confident about these, so another round of review is probably necessary.

Amanieu · 2026-08-31T15:26:13Z

cc @rust-lang/edition for awareness.

rustbot · 2026-08-31T15:51:08Z

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.

petrochenkov · 2026-09-02T15:16:02Z

audit every single code path that ends up calling non_glob_decl. This exposed some issues that are addressed in the latest commit

Yeah, I only did bare minimum for the test suite to pass, but anything not correctly updated will result in a panic rather than a silent bug, so it's not a big problem.

petrochenkov · 2026-09-02T15:35:33Z

+    const PATH: &[Symbol] = &[sym::rustc_edition_redirect];
+    const ALLOWED_TARGETS: AllowedTargets<'_> = AllowedTargets::AllowList(&[Allow(Target::Use)]);
+    const TEMPLATE: AttributeTemplate = template!(NameValueStr: "2024");
+    const STABILITY: AttributeStability = unstable!(edition_redirect);


Suggested change

const STABILITY: AttributeStability = unstable!(edition_redirect);

const STABILITY: AttributeStability = unstable!(rustc_attrs);

The feature no longer does anything besides gating the attribute itself, I'd rather avoid introducing more entities and reuse feature(rustc_attrs) which is used for other attributes in this file.

View changes since the review

petrochenkov · 2026-09-02T15:43:41Z

+pub struct Oldest;
+pub struct Middle;
+
+#[rustc_edition_redirect = "2021"]


Suggested change

#[rustc_edition_redirect = "2021"]

#[rustc_edition_redirect = "..=2021"]

Similarly to @mejrs I'd personally prefer to use ranges and prohibit overlaps instead of relying on overlaps to determine which edition the reexport actually uses.

Also, it's not very obvious from the current syntax that "2021" actually means "not later than 2021".
This is not very related to name resolution though, so I'll leave this for lang team to decide.

View changes since the review

petrochenkov · 2026-09-02T15:43:54Z

        await_macro,
        backchain,
        backend_repr,
+        before,


This symbol is no longer used.

View changes since the review

petrochenkov · 2026-09-02T15:49:21Z

    ambiguity_vis_min: CmCell<Option<Decl<'ra>>>,
    parent_module: Option<Module<'ra>>,
+    /// Fully resolved cross-crate redirects attached to this declaration.
+    edition_redirects: &'ra [EditionRedirectDecl<'ra>],


This can be moved to struct NameResolution since only non_glob_decl declarations in NameResolutions can have redirects.

Also, allocating on the arena may be unnecessary from the lifetime point of view.
But it is probably still slightly useful for performance.

View changes since the review

petrochenkov · 2026-09-02T15:58:40Z

 }

 impl<'ra> Module<'ra> {
+    /// Visits children without applying edition redirects.


Suggested change

/// Visits children without applying edition redirects.

/// Visits children and panic if any edition redirects are encountered.

View changes since the review

petrochenkov · 2026-09-02T16:23:14Z


-                self.add_import(module_path, kind, use_tree.span(), item, root_span, item.id, vis);
+                let edition_redirect = if !nested
+                    && ast::attr::contains_name(&item.attrs, sym::rustc_edition_redirect)


Suggested change

&& ast::attr::contains_name(&item.attrs, sym::rustc_edition_redirect)

&& attr::contains_name(&item.attrs, sym::rustc_edition_redirect)

View changes since the review

petrochenkov · 2026-09-02T16:25:42Z

-    /// The glob declaration for this name, if it is known to exist.
-    pub glob_decl: Option<Decl<'ra>> = None,
-    pub orig_ident_span: Span,
+mod name_resolution {


Could you add a comment telling why this module exists?

View changes since the review

petrochenkov · 2026-09-02T16:28:49Z

    pub(crate) fn determined_decl(&self) -> Option<Decl<'ra>> {
-        if self.non_glob_decl.is_some() {
-            self.non_glob_decl
+        if self.non_glob_decl().is_some() {


Suggested change

if self.non_glob_decl().is_some() {

if let non_glob_decl @ Some(..) = self.non_glob_decl() {

To avoid the second call.
And the same below for consistency.

View changes since the review

petrochenkov · 2026-09-02T16:31:21Z

                return; // Has resolution, do not create the dummy binding
            }
+            if import.edition_redirect.is_some() {
+                let dummy_decl = self.new_import_decl(self.dummy_decl, import);


Is this necessary?
I remember removing it in my commit without consequences.

View changes since the review

petrochenkov · 2026-09-02T16:34:52Z

        let mut ambig_module_children = Default::default();
-        for module in &self.local_modules {
-            self.finalize_resolutions_in(*module, &mut module_children, &mut ambig_module_children);
+        for index in 0..self.local_modules.len() {


Why was this change necessary?

View changes since the review

rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 30, 2026

rustbot assigned petrochenkov Jul 30, 2026

Amanieu added the A-resolve Area: Name/path resolution done by `rustc_resolve` specifically label Jul 30, 2026

mejrs requested changes Jul 30, 2026

View reviewed changes

Comment thread compiler/rustc_resolve/src/build_reduced_graph.rs Outdated

Comment thread compiler/rustc_resolve/src/build_reduced_graph.rs Outdated

Comment thread compiler/rustc_attr_parsing/src/attributes/rustc_internal.rs Outdated

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 30, 2026

mejrs added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jul 31, 2026