Tracking issue for RFC 2052: Epochs

[aturon]

This is a tracking issue for the RFC "Evolving Rust through Epochs" (rust-lang/rfcs#2052).

Overall status

• Implement the RFC
  • Implement RFC 2052 (Epochs) #48014 added -Zepoch flag
• Adjust documentation (see instructions on forge)

Next work items

• Make -Zepoch=2018 imply the "standard set" of features and lints:
  • Tracking issue make the epoch Enable All The Things #48790

Unresolved questions

How to handle macros from epoch 2015 that are used in a crate from epoch 2018?

[epage]

I think there would be a lot of value to leaving warning groups unchanged during an epoch (see my rust2018 post).

Would the appropriate venue for that to be discussed here to be added to this RFC or does it need its own RFC?

High level thoughts

• Warning group doesn't change during epoch
  • No new warnings added
  • If a warning absolutely needs to be removed (say implementation details like Chalk change the warning enough not to be the same) we make it a no-op
• Warning group -unstable variant is what the group will be in the future epoch
  • Warnings added as-needed
  • Warnings removed as-needed

[Manishearth]

Unless someone gets to it first, I plan on doing most of the work here sometime in february. It involves:

• cargo logic for accepting epochs in cargo.toml and passing them down
• crates.io logic for validating epoch flags and ensuring they're part of a set of allowed flags (so you can't publish a 2018-pre crate or whatever)
• rustc logic for setting epoches, and flipping features based on them. I will probably make Tracking issue for future-incompatibility lint tyvar_behind_raw_pointer #46906 my guinea pig for an epoch-gated error

[nikomatsakis]

@Manishearth glad to see you volunteering. =) Writing up a concrete plan and mentoring instructions has been on my to-do list for quite some time. I think the work items ought to be roughly as follows:

• Add a -Zepoch=XXX switch to the compiler.
  • This will eventually be --epoch=XXX or -C epoch=XXX or something, but starting with -Z because it's unstable.
  • This will set some flags in the session or what have you, so that you can easily do if tcx.features.rust_2018 { ... }. We might want some helpers for checking "ranges" of epochs (i.e., "sometimes before rust-2018 vs sometime after?).
  • There will be a list of declared epochs and their status, probably starting with 2015 and 2018.
    • 2015 should be "stable". Stable epochs can be used on stable (except that the flag itself is unstable, but that's a separate check.)
    • 2018 would be "unstable". Unstable epochs may only be used on nightly.
• Add a epoch = XXX thing to cargo, which is only usable on nightly, and which triggers this flag to be passed to the compiler.
  • Once the epoch flag stabilizes, we will want some infrastructure for declaring
• I don't know what crates.io logic is required here. Just checking that things build probably suffices, right? (Since a bad epoch would fail to build?)

That itself is some pretty simple stuff, but it lays the groundwork. Then, yes, we can for example gate the #46906 error.

The idea of a 2018-pre epoch can be fit into this, although it's not entirely clear to me if it is needed. It's certainly not technically needed: we could just have a 2018 epoch. It can be allowed on stable as soon as the full set of deprecations are known. The main problem there is that it might confuse people if we allow you to do --epoch = 2018 on stable before the epoch is all done. But we can worry about this later. (Anyway, since the epoch isn't really going to alter much in the behavior of the compiler, it probably doesn't matter much -- that is, there might be a few features gated on the epoch, but most stuff is going to be available before, and the epoch is mostly about being stricter about a few deprecations.)

[Manishearth]

Cool. This roughly aligns with my plan for it. I was considering a -pre epoch mostly so that we could experiment without confusing people but you're right that we can just make all new epochs nightly-only till they stabilize.

[Manishearth]

I wonder -- did we ever decide how this works with macros? I guess macro expansions belong to the epoch of the crate the macro was defined in, but that can get icky to precisely define. Also a backcompat hazard -- what if the actual problematic code comes from code originally specified by the macro caller in the macro arguments? What if the problematic code comes from a combination of the two?

Macro expansions being in the expanded crate's epoch is a rather simple backcompat hazard.

I'm reminded of Clippy's macro check issue -- we want to determine if the code is yours or from a macro expansion, so that we can avoid warning in the expansion case. We end up basically bailing for non-local macros. The problem is that this misses code like wrap_code!(bad code here) if wrap_code is from a different crate because even though we wrote the bad code it turns up in the expansion of that macro and there's no straightforward way of tying it back.

We really need to figure this out before shipping epochs. It's listed as an unresolved question in the RFC right now.

[nikomatsakis]

I wonder -- did we ever decide how this works with macros?

Good point, I think we "deferred" that =)

I guess macro expansions belong to the epoch of the crate the macro was defined in, but that can get icky to precisely define.

Seems like we will want this to be based on the span, basically same as hygiene. Not that I really know how that works precisely. Still, it complicates things quite a bit, since it wouldn't be a global switch.

[Manishearth]

@nrc @jseyfried thoughts?