rustc: Refactor how unstable flags are handled #31793
Conversation
|
r? @nrc (rust_highfive has picked a reviewer for you, use r? to override) |
|
Note that this PR has no functional changes from today's compiler except that usage of |
alexcrichton
force-pushed
the
add-real-option-gating
branch
from
facef09 to
9581134
Compare
|
@alexcrichton seems like a great start to me. |
| // FIXME (pnkfelix): We default to stable since the current set of | ||
| // options is defacto stable. However, it would be good to revise the | ||
| // code so that a stable option is the thing that takes extra effort | ||
| // to encode. |
There was a problem hiding this comment.
I'm confused by this FIXME -- in what sense do we "default" to stable below?
|
Is it worth adding a |
|
I'll take the review since @nrc is on vacation. |
|
I was hoping I could add a test of some form, but I couldn't really think of a way to do so unfortunately. We don't have a way to say "dear compiler, please pretend you are a stable compiler" in a reliable fashion. Although I guess one could be added? |
alexcrichton
force-pushed
the
add-real-option-gating
branch
2 times, most recently
from
b48cb7e to
bd1579c
Compare
|
One part of our discussion at the core team meeting as well was to not warn for now until the stable replacements existed, but thinking more on that it might be nice to start warning immediately to get feedback on what needs to be stabilized. Worth making sure that we want to do this, though. |
alexcrichton
force-pushed
the
add-real-option-gating
branch
from
bd1579c to
3f187b9
Compare
|
@bors r+ |
|
📌 Commit 3f187b9 has been approved by |
nikomatsakis
added
the
relnotes
|
⌛ Testing commit 3f187b9 with merge 6d91818... |
|
💔 Test failed - auto-mac-64-opt |
|
@alexcrichton that bors failure looks (plausibly) legitimate to me. |
This commit adds support for *truly* unstable options in the compiler, as well as adding warnings for the start of the deprecation path of unstable-but-not-really options. Specifically, the following behavior is now in place for handling unstable options: * As before, an unconditional error is emitted if an unstable option is passed and the `-Z unstable-options` flag is not present. Note that passing another `-Z` flag does not require passing `-Z unstable-options` as well. * New flags added to the compiler will be in the `Unstable` category as opposed to the `UnstableButNotReally` category which means they will unconditionally emit an error when used on stable. * All current flags are in a category where they will emit warnings when used that the option will soon be a hard error. Also as before, it is intended that `-Z` is akin to `#![feature]` in a crate where it is required to unlock unstable functionality. A nightly compiler which is used without any `-Z` flags should only be exercising stable behavior.
alexcrichton
force-pushed
the
add-real-option-gating
branch
from
3f187b9 to
1282833
Compare
|
⌛ Testing commit 1282833 with merge 9f39abe... |
|
💔 Test failed - auto-win-gnu-32-nopt-t |
|
@bors: retry On Wed, Feb 24, 2016 at 1:00 PM, bors notifications@github.com wrote:
|
…, r=nikomatsakis This commit adds support for *truly* unstable options in the compiler, as well as adding warnings for the start of the deprecation path of unstable-but-not-really options. Specifically, the following behavior is now in place for handling unstable options: * As before, an unconditional error is emitted if an unstable option is passed and the `-Z unstable-options` flag is not present. Note that passing another `-Z` flag does not require passing `-Z unstable-options` as well. * New flags added to the compiler will be in the `Unstable` category as opposed to the `UnstableButNotReally` category which means they will unconditionally emit an error when used on stable. * All current flags are in a category where they will emit warnings when used that the option will soon be a hard error. Also as before, it is intended that `-Z` is akin to `#![feature]` in a crate where it is required to unlock unstable functionality. A nightly compiler which is used without any `-Z` flags should only be exercising stable behavior.
|
⌛ Testing commit 1282833 with merge 8d30ee4... |
|
💔 Test failed - auto-linux-64-nopt-t |
|
@bors: retry On Thu, Feb 25, 2016 at 7:04 AM, bors notifications@github.com wrote:
|
This commit adds support for truly unstable options in the compiler, as well
as adding warnings for the start of the deprecation path of
unstable-but-not-really options. Specifically, the following behavior is now in
place for handling unstable options:
and the
-Z unstable-optionsflag is not present. Note that passing another-Zflag does not require passing-Z unstable-optionsas well.Unstablecategory as opposedto the
UnstableButNotReallycategory which means they will unconditionallyemit an error when used on stable.
that the option will soon be a hard error.
Also as before, it is intended that
-Zis akin to#![feature]in a cratewhere it is required to unlock unstable functionality. A nightly compiler which
is used without any
-Zflags should only be exercising stable behavior.