make the epoch Enable All The Things

[nikomatsakis]

So @Manishearth added -Zepoch=2018. It's time to make it your One Stop Shop for turning on all the feature gates and things. This issue is tracking the feature gates and lints that should be enable by -Zepoch=2018.

This issue is meant to serve as a master issue for tracking the full set of feature gates and language changes as well. It somewhat duplicates #46889 in that respect, but it's more targeted.

Key

🚧 Still needs work
🆘 The code is on nightly, but we need to link it to the -Zepoch flag. Help wanted!
💛 Good to go, waiting for us to pull the trigger
❓ Something needs to be resolved.
✅ Done

Feature gates

• 🆘 match_default_bindings (#42640)
• 🆘 nll (#43234)
• 🆘 underscore_lifetime (#48469)
• 🆘in_band_lifetimes (#44524)
• 🆘 universal_impl_trait (#34511))
• 🆘 conservative_impl_trait (#34511)
• 🆘 dyn_trait (#44662)
• 🆘 copy_closures (#44490)
• 🆘 clone_closures (#44490)
• 🆘 termination_trait (#43301)
• 🚧 module system feature gates not yet decided
• 🚧 tying feature gates to epochs: (#48794)

Lints

These lints cover cases where the preferred syntax is changing. Per the epoch RFC, all such changes must have a lint that starts to warn in the old epoch. The preference is for this lint to move to deny-by-default in the new epoch, though in some cases we may choose to create a hard error (not configurable) instead.

We are not ready, I think, to start warning by default yet; therefore, the warn-by-default on master for most lints is marked 💛.

• tyvar_behind_raw_pointer #46906
  • 💛 warn by default on master (not yet!)
  • ❓hard error in the new epoch, I believe
    • this is to make way for the newer features
• bare_trait_object
  • 💛 warn by default on master (not yet!)
  • 🆘 deny by default in new epoch
• elided_lifetime_in_path
  • 🚧 warn by default on master (blocked: #48385)
  • 🚧 deny by default in new epoch
• single_use_lifetime (#44752)
  • 🚧 warn by default on master (blocked: not fully implemented, see issue above)
  • 🚧 deny by default in new epoch (blocked: still has bugs)
• dyn keyword lint
  • 🚧 warn by default on master (blocked: not implemented)
  • 🚧 deny by default on master (blocked: not implemented)
• catch keyword lint (#48791)
  • 🚧 warn by default on master (blocked: not implemented)
  • 🚧 deny by default on master (blocked: not implemented)
• unusued_pub ??

[nikomatsakis]

Hmm, so actually I'm not 100% sure how we should set this up. In principle, epochs and feature gates are sort of orthogonal. That is -- I want some trivial way to enable the new features, and -- until the epoch is stable -- -Zepoch=2018 (and/or epoch=2018) feels like the most natural way to do it.

But looking further ahead, of course you can be in an epoch and still want feature gates -- and many of these features are going to be stabilized without reference to an epoch longer term (e.g., impl trait).

So I'm feeling a bit uncertain how to proceed here!

[Manishearth]

Okay, so I think dyn_trait is a bit tricky.

There are actually two separate concerns here, which we may be rolling together:

• dyn is now a keyword, which we need to compat lint for (blocked on raw identifiers)
• we want to introduce a lint that suggests using dyn (this lint exists, but is hidden behind the feature flag)

The latter lint cannot work without dyn trait being possible. That cannot be stabilized until epoch 2018.

What we need to do here is:

• Add the keyword lint
• Keep the dyn trait lint behind the dyn trait flag, and remove the EpochDeny for now
• In Rust 2018, dyn trait is enabled automatically, and the lint is enabled.
• In Rust 2018, wait a couple releases and then make it EpochDeny. Actually, this lint doesn't need EpochDeny since we can just make it Deny then, Rust 2015 doesn't get this lint without the feature flag, and we don't particularly care about users still using Rust 2015 but also using nightly with feature flags.

The whole "bare traits should use dyn trait" is not a 2018 epoch lint at all, though it may be a compatability lint for the next epoch.

This kinda explains some of the confusion I had when implementing epoch lints -- I implemented what we needed for epoch lints but was kinda confused about how bare_trait_lint fit in there.

[Manishearth]

Basically, there are two kinds of epoch lints:

• uh oh, this will break in 2018, fix it please
• oh btw have you heard the good news of our lord and savior <cool new feature>?

The former should exist in 2015 and become hard errors in 2018. The latter should be tied to the feature gate, and eventually become Deny, perhaps.

For the path reform RFC I'm not sure if any of the lints are of this kind.

[Manishearth]

Regarding feature gates, I think we should do something similar to EpochDeny for them -- currently we have active/accepted/etc features in

rust/src/libsyntax/feature_gate.rs

Line 124 in 2789b06

declare_features! (

We make it such that you can declare a feature as accepted(epoch), and it gets auto-turned-on in the epoch.

So we can do that for dyn trait, for example. I can work on this if you think this makes sense.

[nikomatsakis]

The latter lint cannot work without dyn trait being possible.

Hmm, this is not clear to me. I think we can enable dyn Trait as a contextual keyword. But I guess we should discuss this over in the dyn Trait tracking issue

[petrochenkov]

Lints

I think we should not tie lints to epochs, continue gradual "escalation" of deprecation lints with small-scale effect, and never enable lints with large-scale effect (e.g. dyn) by default.

I don't see any point in the recent epoch-related activities in the compiler and breaking the stability promise and user trust (except for maybe earning visibility points in Mozilla or something) following one bad decision made in rust-lang/rfcs#2052.

Ok, I said that, now I can sleep better.

[nikomatsakis]

@petrochenkov

breaking the stability promise

I want to push back on this language. The approach you propose ("gradual escalation of deprecation lints") seems to actually be breaking the stability promise (although I guess that depends on long we continue escalating): we are gradually making code stop compiling. The epoch approach, in contrast, tries to avoid making older code stop compiling, and instead pushes for 'opt-in' for larger scale changes. I can certainly see an argument that this is not a good idea: but I don't think you can call it breaking the stability promise.

[Manishearth]

Filed #48794 about auto-opening feature gates in epochs.

[Manishearth]

I don't see any point in the recent epoch-related activities in the compiler and breaking the stability promise and user trust (except for maybe earning visibility points in Mozilla or something) following one bad decision made in rust-lang/rfcs#2052.

This seems to be directed towards me, given that I'm doing all the implementation work.

Please don't insinuate stuff about motivations. I was asked to help with this, and I'm helping. I shouldn't have to justify doing the implementation work for an accepted RFC, the burden of justification is on those who wish it not to be implemented, and you do that by opening another RFC or starting similar discussions, not by pushing back against the implementation work.

(I think there's good consensus amongst the teams that we want epochs to happen, so that's unlikely to go through)

[CAD97]

@nikomatsakis

But looking further ahead, of course you can be in an epoch and still want feature gates -- and many of these features are going to be stabilized without reference to an epoch longer term (e.g., impl trait).

So I'm feeling a bit uncertain how to proceed here!

Huh, I had a similar idea. If this sort of "feature gate group" is useful to talk about at an edition level, then maybe a "nightly" edition can be introduced to un-gate likely-to-be-stabilized-in-near-current-form features. Or, alternatively, introduce feature groups like warning groups, so #[feature(edition_2018_preview)] opts in to the featured feature gates (and -Zedition=2018 enables the language-level features).

[nikomatsakis]

@CAD97 I saw that thread. I've been meaning to comment there. Long term, I believe that editions are orthogonal to nightly/stable/etc.

[crlf0710]

I believe this can be closed now? @nikomatsakis