rustc: Refactor how unstable flags are handled by alexcrichton · Pull Request #31793 · rust-lang/rust

alexcrichton · 2016-02-20T18:12:39Z

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.

rust-highfive · 2016-02-20T18:12:51Z

r? @nrc

(rust_highfive has picked a reviewer for you, use r? to override)

alexcrichton · 2016-02-20T18:15:09Z

Note that this PR has no functional changes from today's compiler except that usage of -Z on the stable channel will now emit a warning. I would hope that over time we can use this as a metric for what -Z flags really need to be stabilized, and we can stabilize some of the -Z flags in other locations.

nikomatsakis · 2016-02-21T09:21:16Z

@alexcrichton seems like a great start to me.

nikomatsakis · 2016-02-21T09:22:56Z

I'm confused by this FIXME -- in what sense do we "default" to stable below?

er, did we?

nikomatsakis · 2016-02-21T09:26:25Z

Is it worth adding a run-make test or something like that?

nikomatsakis · 2016-02-21T09:26:46Z

I'll take the review since @nrc is on vacation.

alexcrichton · 2016-02-21T18:14:43Z

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 · 2016-02-21T18:21:29Z

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.

nikomatsakis · 2016-02-23T19:31:45Z

@bors r+

bors · 2016-02-23T19:31:47Z

📌 Commit 3f187b9 has been approved by nikomatsakis

bors · 2016-02-24T10:29:10Z

⌛ Testing commit 3f187b9 with merge 6d91818...

bors · 2016-02-24T11:29:30Z

💔 Test failed - auto-mac-64-opt

pnkfelix · 2016-02-24T17:49:22Z

@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 · 2016-02-24T19:03:42Z

@bors: r=nikomatsakis 1282833

legit indeed!

bors · 2016-02-24T19:49:44Z

⌛ Testing commit 1282833 with merge 9f39abe...

bors · 2016-02-24T21:00:21Z

💔 Test failed - auto-win-gnu-32-nopt-t

alexcrichton · 2016-02-25T00:54:12Z

@bors: retry

On Wed, Feb 24, 2016 at 1:00 PM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-win-gnu-32-nopt-t
http://buildbot.rust-lang.org/builders/auto-win-gnu-32-nopt-t/builds/3211
—
Reply to this email directly or view it on GitHub
#31793 (comment).

…, 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.

- Successful merges: #31362, #31793, #31800, #31809, #31818, #31827, #31831, #31835, #31837, #31846 - Failed merges:

bors · 2016-02-25T13:44:00Z

⌛ Testing commit 1282833 with merge 8d30ee4...

bors · 2016-02-25T15:04:40Z

💔 Test failed - auto-linux-64-nopt-t

alexcrichton · 2016-02-25T17:07:14Z

@bors: retry

On Thu, Feb 25, 2016 at 7:04 AM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-linux-64-nopt-t
http://buildbot.rust-lang.org/builders/auto-linux-64-nopt-t/builds/8173
—
Reply to this email directly or view it on GitHub
#31793 (comment).

rust-highfive assigned nrc Feb 20, 2016

alexcrichton mentioned this pull request Feb 20, 2016
rustc: Disallow unstable flags in stable releases #31731
Closed

alexcrichton force-pushed the add-real-option-gating branch from facef09 to 9581134Compare February 20, 2016 18:16

nikomatsakis reviewed Feb 21, 2016
View reviewed changes

nikomatsakis assigned nikomatsakis and unassigned nrc Feb 21, 2016

alexcrichton force-pushed the add-real-option-gating branch 2 times, most recently from b48cb7e to bd1579cCompare February 21, 2016 18:18

alexcrichton mentioned this pull request Feb 23, 2016
Tracking issue for accepting unstable flags in stable compilers #31847
Closed

alexcrichton force-pushed the add-real-option-gating branch from bd1579c to 3f187b9Compare February 23, 2016 19:30

nikomatsakis added the relnotes Marks issues that should be documented in the release notes of the next release. label Feb 23, 2016

alexcrichton force-pushed the add-real-option-gating branch from 3f187b9 to 1282833Compare February 24, 2016 19:02

jseyfried mentioned this pull request Feb 25, 2016
resolve: fix the visibility of extern crates #31362
Merged

Manishearth mentioned this pull request Feb 25, 2016
Rollup of 10 pull requests #31882
Merged

bors added a commit that referenced this pull request Feb 25, 2016
Auto merge of#31882- Manishearth:rollup, r=Manishearth
c9852e2
- Successful merges: #31362, #31793, #31800, #31809, #31818, #31827, #31831, #31835, #31837, #31846 - Failed merges:

bors merged commit 1282833 into rust-lang:masterFeb 25, 2016

alexcrichton deleted the add-real-option-gating branch February 25, 2016 22:55

steveklabnik mentioned this pull request Aug 11, 2016
Support new Rust error format flycheck/flycheck#1035
Closed

gywn mentioned this pull request Nov 22, 2016
Avoid warning of -Z due to #31793 rust-lang/rust.vim#127
Merged

Uh oh!

Uh oh!

Conversation

alexcrichton commented Feb 20, 2016

Uh oh!

rust-highfive commented Feb 20, 2016

Uh oh!

alexcrichton commented Feb 20, 2016

Uh oh!

nikomatsakis commented Feb 21, 2016

Uh oh!

nikomatsakisFeb 21, 2016

Choose a reason for hiding this comment

Uh oh!

nikomatsakisFeb 21, 2016

Choose a reason for hiding this comment

Uh oh!

nikomatsakis commented Feb 21, 2016

Uh oh!

nikomatsakis commented Feb 21, 2016

Uh oh!

alexcrichton commented Feb 21, 2016

Uh oh!

alexcrichton commented Feb 21, 2016

Uh oh!

nikomatsakis commented Feb 23, 2016

Uh oh!

bors commented Feb 23, 2016

Uh oh!

bors commented Feb 24, 2016

Uh oh!

bors commented Feb 24, 2016

Uh oh!

pnkfelix commented Feb 24, 2016

Uh oh!

alexcrichton commented Feb 24, 2016

Uh oh!

bors commented Feb 24, 2016

Uh oh!

bors commented Feb 24, 2016

Uh oh!

alexcrichton commented Feb 25, 2016

Uh oh!

bors commented Feb 25, 2016

Uh oh!

bors commented Feb 25, 2016

Uh oh!

alexcrichton commented Feb 25, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants