Add #[rustc_per_edition] for edition-dependent type aliases.

[m-ou-se]

This will make it possible to have e.g. std::ops::Range refer to different types depending on the edition of the code using that alias.

Marking this as experimental for now, because I don't know yet if this is something we want.

Thanks @eddyb for pointing out this can be done relatively easily with type aliases.

cc @sfackler, since you're working on the new Range types, for which this could be useful.

As this PR shows, the change to rustc itself is pretty simple. But rustdoc (and racer/rls and rust-analyzer) would also need special support for this, which I haven't looked into yet.

r? @ghost

[eddyb]

One very important design decision is that pub use std::ops::Range as MyRange; still gives you the "edition-polymorphic" alias, while pub type MyRange<T> = std::ops::Range<T>; forces an edition to be picked.

It might be more desirable to have imports also force choosing one of the alternatives, and if we can do it at the import level, it would work for other items as well, but it is trickier.

Something I was thinking might work is have a setup like this:

#[rustc_per_edition]
pub use self::rust_0000::Range;

mod rust_2015 { pub use crate::iter::Range; }
mod rust_2018 { pub use crate::iter::Range; }
mod rust_2021 { pub struct Range<T> {...} ... }

Where rustc_resolve rewrites rust_0000 in the path depending on the edition, when the attribute is present (this happens in the crate this is written, i.e. libcore, as paths themselves are not kept cross-crate).

(Other than replacing an identifier, we could instead inject an extra path component just before the last one or w/e, but that feels "more magical")

While it would resolve to rust_2021 inside libcore itself, we could record an Export that contains per-edition resolutions, so that cross-crate rustc_resolve can just pull the right set of resolutions for wherever that #[rustc_per_edition] core::ops::Range is imported.

cc @petrochenkov

[petrochenkov]

Could someone explain what are the goals exactly?

1. libstd is built with edition set in stone (now 2018, soon 2021).
2. Some other crate is built in an arbitrary edition e and uses libstd.
3. ??? Range ???

[m-ou-se]

I'd like to find a way to make it possible to use editions for small breaking changes in the standard library as well, instead of only in the language. (E.g. for renaming/moving items.) This seems to be a way to achieve that without making things too complicated.

For Range specifically: a..b currently expands to a value of type std::ops::Range, which is an Iterator and is not Copy. We now think it might be better if a..b would've expanded to a type that is Copy, and implements IntoIterator. We can already change the compiler/language to expand a..b to a different type in a new edition, but ideally, this new Copy type would be called std::ops::Range in the new edition too (and we'd move the iterator type to std::iter::Range or something).

Basically: It'd be nice if in Edition 2021 code, std::ops::Range would refer to a Copy type, while in older editions, it still refers to the Iterator type like it does now (which we might put under std::iter::Range).

[m-ou-se]

We already did something like this for panic: std::panic!() 'resolves' to either panic_2015!() or panic_2021!(). (That's now implemented as a builtin macro. But maybe a more general mechanism would be possible.)

[Dylan-DPC]

@m-ou-se any updates on this?

[bors]

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

[JohnCSimon]

@m-ou-se
Ping from triage: I'm closing this due to inactivity, Please reopen when you are ready to continue with this.
Note: if you do please open the PR BEFORE you push to it, else you won't be able to reopen - this is a quirk of github.
Thanks for your contribution.

@rustbot label: +S-inactive