New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for accepting unstable flags in stable compilers #31847

Closed
alexcrichton opened this Issue Feb 23, 2016 · 46 comments

Comments

Projects
None yet
@alexcrichton
Member

alexcrichton commented Feb 23, 2016

This issue is intended to track the process of fixing rustc to not accept unstable flags on stable compilers. It's somewhat of a historical mistake that this was allowed, and we're attempting now to repair the logic to disallow unstable flags on the compiler. Today the compiler has a few unstable flags:

  • -Z - all debugging options in the compiler are intended to be unstable
  • --pretty - the pretty printer is quite broken in various ways, and it's output is also generally quite unstable
  • --unpretty - the flag and formats emitted here were not intended to be stable
  • --error-format - this support is currently experimental in the compiler and may not be ready for prime-time

For backwards compatibility the compiler will continue to accept these flags on the stable and beta channels of Rust. In #31793, however, the compiler will start to issue a warning on these channels whenever these flags are passed. The warning message points at this issue.

The next steps on this issue are likely:

  • Wait for the warning to propagate to the stable channel
  • Get feedback about which unstable flags are widely used today
  • Resolve how to stabilize widely used unstable flags
  • Wait for these flags to be stable
  • Turn the warning of unstable flags on the stable channel into a hard error

If you're coming to this issue via the compiler warning, please feel free to comment with your flag and use case! We're eager to learn which unstable flags are most widely used to prioritize what to stabilize.

@Zoxc

This comment has been minimized.

Show comment
Hide comment
@Zoxc

Zoxc Feb 23, 2016

Contributor

Can -C link-args, -C llvm-args join this list? Both need a replacement which acceps spaces (#30947)

Contributor

Zoxc commented Feb 23, 2016

Can -C link-args, -C llvm-args join this list? Both need a replacement which acceps spaces (#30947)

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Feb 23, 2016

Member

@Zoxc for now, no, those are both stable flags and this is just targeted at unstable flags.

Member

alexcrichton commented Feb 23, 2016

@Zoxc for now, no, those are both stable flags and this is just targeted at unstable flags.

@durka

This comment has been minimized.

Show comment
Hide comment
@durka

durka Feb 23, 2016

Contributor

For myself I use -Z trace-macros and --pretty=expanded for debugging macros, though both need improvements in their output.

I also use -Z no-trans for a faster compile-edit cycle, so I can fix all the errors before even trying the slow translation/linking steps. And I use cargo clippy for extra lints, which uses this flag internally (I think cargo check does too). Something like it should probably be stabilized with a different name.

cargo clippy also uses -Z extra-plugins.

Contributor

durka commented Feb 23, 2016

For myself I use -Z trace-macros and --pretty=expanded for debugging macros, though both need improvements in their output.

I also use -Z no-trans for a faster compile-edit cycle, so I can fix all the errors before even trying the slow translation/linking steps. And I use cargo clippy for extra lints, which uses this flag internally (I think cargo check does too). Something like it should probably be stabilized with a different name.

cargo clippy also uses -Z extra-plugins.

@jrvidal

This comment has been minimized.

Show comment
Hide comment
@jrvidal

jrvidal Mar 4, 2016

I also use -Z no-trans for a faster compile-edit cycle

+1 on this.

(I'm guessing "+1" comments are fine in this thread...?)

jrvidal commented Mar 4, 2016

I also use -Z no-trans for a faster compile-edit cycle

+1 on this.

(I'm guessing "+1" comments are fine in this thread...?)

@nagisa

This comment has been minimized.

Show comment
Hide comment
@nagisa

nagisa Mar 4, 2016

Contributor

--pretty and --unpretty should probably be -Z pretty/unpretty instead. cc @nikomatsakis

Contributor

nagisa commented Mar 4, 2016

--pretty and --unpretty should probably be -Z pretty/unpretty instead. cc @nikomatsakis

@mkpankov

This comment has been minimized.

Show comment
Hide comment
@mkpankov

mkpankov May 26, 2016

Contributor

Note that passing -Z no-trans disables some errors. In particular, type size comparison done when checking if std::mem::transmute should be allowed is not performed.

See this example: https://is.gd/cnjaFI . When run locally with -Z no-trans, no errors are reported.

Also, I'd like to point out that many linters are using -Z no-trans. This itself doesn't justify its stabilization, especially considering the example above that isn't checked correctly with the option. But, there probably should be another, stable, option, then, which would serve the purpose of linting. It should check for all possible errors and drop the translation as soon as all possible. Or should we wait for linting support in IDE oracle?

Contributor

mkpankov commented May 26, 2016

Note that passing -Z no-trans disables some errors. In particular, type size comparison done when checking if std::mem::transmute should be allowed is not performed.

See this example: https://is.gd/cnjaFI . When run locally with -Z no-trans, no errors are reported.

Also, I'd like to point out that many linters are using -Z no-trans. This itself doesn't justify its stabilization, especially considering the example above that isn't checked correctly with the option. But, there probably should be another, stable, option, then, which would serve the purpose of linting. It should check for all possible errors and drop the translation as soon as all possible. Or should we wait for linting support in IDE oracle?

@psFried

This comment has been minimized.

Show comment
Hide comment
@psFried

psFried Jun 10, 2016

Regardless of whether -Z no-trans disables some checks, I think it's still very nice to have in the stable compiler. Ideally, the long term solution would be for linters and IDE's to use the oracle once it's ready, but I think it's important in the mean time to have a fast check that catches most compile errors. This is especially important for those who are new to the language and will ofter require many revisions in order to get their code compiling.

psFried commented Jun 10, 2016

Regardless of whether -Z no-trans disables some checks, I think it's still very nice to have in the stable compiler. Ideally, the long term solution would be for linters and IDE's to use the oracle once it's ready, but I think it's important in the mean time to have a fast check that catches most compile errors. This is especially important for those who are new to the language and will ofter require many revisions in order to get their code compiling.

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Jun 24, 2016

Contributor

@psFried I believe the plan was to make -Z no-trans more official, something like -C check. We should actually do this, however.

Contributor

nikomatsakis commented Jun 24, 2016

@psFried I believe the plan was to make -Z no-trans more official, something like -C check. We should actually do this, however.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Jul 14, 2016

Contributor

Nominating to consider converting to an error.

Contributor

brson commented Jul 14, 2016

Nominating to consider converting to an error.

@sanxiyn

This comment has been minimized.

Show comment
Hide comment
@sanxiyn

sanxiyn Jul 17, 2016

Member

This will break using -Z time-passes with stable compiler.

Member

sanxiyn commented Jul 17, 2016

This will break using -Z time-passes with stable compiler.

@durka

This comment has been minimized.

Show comment
Hide comment
@durka

durka Jul 19, 2016

Contributor

Have any of the useful flags people mentioned (no-trans, time-passes,
pretty-expanded, trace-macros) been moved to stable
equivalents/alternatives? (I think the answer is no.) If not, I think we
shouldn't make this an error yet, since (supposedly) the intent was to keep
useful functionality available, while being mindful about what gets
stabilized. Without that it's kind of a bait-and-switch.

On Jul 17, 2016 08:27, "Seo Sanghyeon" notifications@github.com wrote:

This will break using -Z time-passes with stable compiler.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#31847 (comment),
or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAC3nxuPYQNuceqHf7r-fBIcz7KhkvNLks5qWh--gaJpZM4Hg8-w
.

Contributor

durka commented Jul 19, 2016

Have any of the useful flags people mentioned (no-trans, time-passes,
pretty-expanded, trace-macros) been moved to stable
equivalents/alternatives? (I think the answer is no.) If not, I think we
shouldn't make this an error yet, since (supposedly) the intent was to keep
useful functionality available, while being mindful about what gets
stabilized. Without that it's kind of a bait-and-switch.

On Jul 17, 2016 08:27, "Seo Sanghyeon" notifications@github.com wrote:

This will break using -Z time-passes with stable compiler.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#31847 (comment),
or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAC3nxuPYQNuceqHf7r-fBIcz7KhkvNLks5qWh--gaJpZM4Hg8-w
.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jul 19, 2016

Member

@sanxiyn yes that's the intention, if it's a desirable flag to be on stable it should be stable.

@durka no, nothing has change, but that's because there doesn't seem to be that much desire to move these flags to stable.

Member

alexcrichton commented Jul 19, 2016

@sanxiyn yes that's the intention, if it's a desirable flag to be on stable it should be stable.

@durka no, nothing has change, but that's because there doesn't seem to be that much desire to move these flags to stable.

@sanxiyn

This comment has been minimized.

Show comment
Hide comment
@sanxiyn

sanxiyn Jul 19, 2016

Member

#34858 is an example of using -Z time-passes with stable, in this case to diagnose hang.

Member

sanxiyn commented Jul 19, 2016

#34858 is an example of using -Z time-passes with stable, in this case to diagnose hang.

@durka

This comment has been minimized.

Show comment
Hide comment
@durka

durka Jul 19, 2016

Contributor

I mean, why even ask in this issue for people's use cases if the answers
weren't going to matter? Sure, go ahead and error everything out and see
who complains.

On Jul 19, 2016 07:12, "Seo Sanghyeon" notifications@github.com wrote:

#34858 #34858 is an example of
using -Z time-passes with stable, in this case to diagnose hang.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#31847 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC3n-21HmArc8LDMrpq5fPpdyLuZ0kUks5qXLEtgaJpZM4Hg8-w
.

Contributor

durka commented Jul 19, 2016

I mean, why even ask in this issue for people's use cases if the answers
weren't going to matter? Sure, go ahead and error everything out and see
who complains.

On Jul 19, 2016 07:12, "Seo Sanghyeon" notifications@github.com wrote:

#34858 #34858 is an example of
using -Z time-passes with stable, in this case to diagnose hang.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#31847 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAC3n-21HmArc8LDMrpq5fPpdyLuZ0kUks5qXLEtgaJpZM4Hg8-w
.

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Jul 19, 2016

Contributor

Hmm, I think we should considering making a stable variant of -Z no-trans at least -- and probably the other flags too.

Regarding the other flags that were mentioned (time-passes, pretty-expanded, trace-macros):

All of these have in common that I feel more comfortable with stabilizing the ability to access said functionality than I do with stabilizing anything about the output. For example, I'd expect time-passes to look different over time (obviously, the set of passes will change, but also maybe the data we collect). Similary, pretty-expanded relies on our pretty printer, which I hope we will remove someday: I could imagine a new version looking quite different, or emitting only JSON, or something else.

What this means is that humans using these switches would probably be fine, but tools would break. Do we think we can realistically declare a stability level of that kind? I guess it is the same as (for example) our general error output, which we expect to change. (We probably want to consider explicit scripting commands like git offers.)

Contributor

nikomatsakis commented Jul 19, 2016

Hmm, I think we should considering making a stable variant of -Z no-trans at least -- and probably the other flags too.

Regarding the other flags that were mentioned (time-passes, pretty-expanded, trace-macros):

All of these have in common that I feel more comfortable with stabilizing the ability to access said functionality than I do with stabilizing anything about the output. For example, I'd expect time-passes to look different over time (obviously, the set of passes will change, but also maybe the data we collect). Similary, pretty-expanded relies on our pretty printer, which I hope we will remove someday: I could imagine a new version looking quite different, or emitting only JSON, or something else.

What this means is that humans using these switches would probably be fine, but tools would break. Do we think we can realistically declare a stability level of that kind? I guess it is the same as (for example) our general error output, which we expect to change. (We probably want to consider explicit scripting commands like git offers.)

@pnkfelix

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix Jul 21, 2016

Member

Compiler team's current thinking: Its too soon to switch off all support for all current -Z flags. There is a set of useful flags for debugging that we have no means of expression via -C or other stable interface.

But something we may be able to do in the short term is white list a small subset of -Z flags to be still accepted in nightly (as today), and make all others an error.

What small subset? We suggest starting with any that appear in comments on this thread. Get to it people!!! Add them below if not already above!

Member

pnkfelix commented Jul 21, 2016

Compiler team's current thinking: Its too soon to switch off all support for all current -Z flags. There is a set of useful flags for debugging that we have no means of expression via -C or other stable interface.

But something we may be able to do in the short term is white list a small subset of -Z flags to be still accepted in nightly (as today), and make all others an error.

What small subset? We suggest starting with any that appear in comments on this thread. Get to it people!!! Add them below if not already above!

@arielb1

This comment has been minimized.

Show comment
Hide comment
@arielb1

arielb1 Jul 21, 2016

Contributor

The contentious flags are these used for debugging user code. I don't feel like they should have the same stability semantics as normal flags. Maybe have -Z debug-mode or something.

Contributor

arielb1 commented Jul 21, 2016

The contentious flags are these used for debugging user code. I don't feel like they should have the same stability semantics as normal flags. Maybe have -Z debug-mode or something.

@pnkfelix pnkfelix removed the I-nominated label Jul 21, 2016

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Jul 26, 2016

Contributor

It does seem like there is room to have flags that, at minimum, have undefined output. Which effectively means they are unstable and can't really be used for scripting. I am thinking of things like gcc's "dump ast" flags (gcc -fdump-tree-vcg -g test.c).

Contributor

nikomatsakis commented Jul 26, 2016

It does seem like there is room to have flags that, at minimum, have undefined output. Which effectively means they are unstable and can't really be used for scripting. I am thinking of things like gcc's "dump ast" flags (gcc -fdump-tree-vcg -g test.c).

@pwoolcoc

This comment has been minimized.

Show comment
Hide comment
@pwoolcoc

pwoolcoc Sep 11, 2016

Contributor

If there is an answer to how we want to stabilize -Z no-trans I would love to use it as an "entry-level" PR for rustc, if yinz don't mind.

Contributor

pwoolcoc commented Sep 11, 2016

If there is an answer to how we want to stabilize -Z no-trans I would love to use it as an "entry-level" PR for rustc, if yinz don't mind.

@hauleth

This comment has been minimized.

Show comment
Hide comment
@hauleth

hauleth Oct 16, 2016

Contributor

Also -Z parse-only is useful for linters.

Contributor

hauleth commented Oct 16, 2016

Also -Z parse-only is useful for linters.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Feb 2, 2017

Member

If we really want -Ztime-passes to be stable, then I'd encourage an issue/proposal to stabilize that rather than delaying this change, personally

Member

alexcrichton commented Feb 2, 2017

If we really want -Ztime-passes to be stable, then I'd encourage an issue/proposal to stabilize that rather than delaying this change, personally

@Mark-Simulacrum

This comment has been minimized.

Show comment
Hide comment
@Mark-Simulacrum

Mark-Simulacrum Feb 2, 2017

Member

Yeah, I don't have an overly strong opinion on it. Just wanted to bring it up. Just something to think about.

Member

Mark-Simulacrum commented Feb 2, 2017

Yeah, I don't have an overly strong opinion on it. Just wanted to bring it up. Just something to think about.

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Feb 7, 2017

Contributor

@alexcrichton

If we really want -Ztime-passes to be stable, then I'd encourage an issue/proposal to stabilize that rather than delaying this change, personally

I agree, except that I would definitely not want to "stabilize" the output of -Z time-passes in the sense of "guarantee that anything remotely similar gets output". But having an option like --self-profile or something seems ok.

In particular, as we move to a more "demand-driven" architecture, the whole idea of "compiler passes" is going to become less clear. I'd still expect we will want to have ways to profile where the compiler is spending its time. But it's not going to look much like it looks today.

Contributor

nikomatsakis commented Feb 7, 2017

@alexcrichton

If we really want -Ztime-passes to be stable, then I'd encourage an issue/proposal to stabilize that rather than delaying this change, personally

I agree, except that I would definitely not want to "stabilize" the output of -Z time-passes in the sense of "guarantee that anything remotely similar gets output". But having an option like --self-profile or something seems ok.

In particular, as we move to a more "demand-driven" architecture, the whole idea of "compiler passes" is going to become less clear. I'd still expect we will want to have ways to profile where the compiler is spending its time. But it's not going to look much like it looks today.

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
@SimonSapin

SimonSapin Feb 7, 2017

Contributor

Could we stabilize "a command line flag named XYZ exists and makes the compiler output some sort of timing information" without stabilizing what that information is and how it’s formatted?

Contributor

SimonSapin commented Feb 7, 2017

Could we stabilize "a command line flag named XYZ exists and makes the compiler output some sort of timing information" without stabilizing what that information is and how it’s formatted?

@pwoolcoc

This comment has been minimized.

Show comment
Hide comment
@pwoolcoc

pwoolcoc Feb 7, 2017

Contributor

Sorry if I'm intruding here, but what if --self-profile took an argument, so that you could stabilize (say) --self-profile=classic and in the future, add another argument for any new style of output?

Contributor

pwoolcoc commented Feb 7, 2017

Sorry if I'm intruding here, but what if --self-profile took an argument, so that you could stabilize (say) --self-profile=classic and in the future, add another argument for any new style of output?

@hauleth

This comment has been minimized.

Show comment
Hide comment
@hauleth

hauleth Feb 7, 2017

Contributor
Contributor

hauleth commented Feb 7, 2017

@pnkfelix

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix Feb 7, 2017

Member

@hauleth (trying to follow git's lead might be confusing, given that the --porcelain option, at least in some contexts, is used to indicate that the output is stable ... see also http://stackoverflow.com/a/6978402 )

Member

pnkfelix commented Feb 7, 2017

@hauleth (trying to follow git's lead might be confusing, given that the --porcelain option, at least in some contexts, is used to indicate that the output is stable ... see also http://stackoverflow.com/a/6978402 )

@hauleth

This comment has been minimized.

Show comment
Hide comment
@hauleth

hauleth Feb 7, 2017

Contributor

@pnkfelix I know, Git has it own strange tidbits that unfortunately still wasn't fixed (maybe v3). However we could adapt similar ideology to provide unstable output with stable compiler and in future provide stable one with appreciate flag.

Contributor

hauleth commented Feb 7, 2017

@pnkfelix I know, Git has it own strange tidbits that unfortunately still wasn't fixed (maybe v3). However we could adapt similar ideology to provide unstable output with stable compiler and in future provide stable one with appreciate flag.

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Feb 7, 2017

Contributor

@SimonSapin

Could we stabilize "a command line flag named XYZ exists and makes the compiler output some sort of timing information" without stabilizing what that information is and how it’s formatted?

This is what I want to do yeah.

Contributor

nikomatsakis commented Feb 7, 2017

@SimonSapin

Could we stabilize "a command line flag named XYZ exists and makes the compiler output some sort of timing information" without stabilizing what that information is and how it’s formatted?

This is what I want to do yeah.

@shepmaster

This comment has been minimized.

Show comment
Hide comment
@shepmaster

shepmaster Feb 11, 2017

Member

Is there any possibility of changing --unpretty=mir to an --emit=mir option? I'd love to be able to use that for the alternative playground. Is it possible to stabilize the concept of outputting MIR even if the actual text form completely changes?

Member

shepmaster commented Feb 11, 2017

Is there any possibility of changing --unpretty=mir to an --emit=mir option? I'd love to be able to use that for the alternative playground. Is it possible to stabilize the concept of outputting MIR even if the actual text form completely changes?

@durka

This comment has been minimized.

Show comment
Hide comment
@durka

durka Feb 11, 2017

Contributor
Contributor

durka commented Feb 11, 2017

@shepmaster

This comment has been minimized.

Show comment
Hide comment
@shepmaster

shepmaster Feb 11, 2017

Member

MIR even if the actual text form completely changes?

I guess we should also consider that there might come a time where MIR no longer even exists (it didn't in Rust 1.0, afterall! 😸). In that case, I even think it would be fine to print the text "MIR was removed in Rust 1.99, nothing to see here!".

a way to stabilize options without stabilizing their output format.

Pedantically, we say we output LLVM IR, but we certainly don't control the format of that. And it's already changed incompatibly as Rust has upgraded LLVM over time. Maybe we are worrying more than we need to be?

Member

shepmaster commented Feb 11, 2017

MIR even if the actual text form completely changes?

I guess we should also consider that there might come a time where MIR no longer even exists (it didn't in Rust 1.0, afterall! 😸). In that case, I even think it would be fine to print the text "MIR was removed in Rust 1.99, nothing to see here!".

a way to stabilize options without stabilizing their output format.

Pedantically, we say we output LLVM IR, but we certainly don't control the format of that. And it's already changed incompatibly as Rust has upgraded LLVM over time. Maybe we are worrying more than we need to be?

@nagisa

This comment has been minimized.

Show comment
Hide comment
@nagisa

nagisa Feb 12, 2017

Contributor

The whole point of emiting MIR is for debugging. --unpretty=mir has little use to compiler devs by now, because -Z dump-mir simply provides more information. In that sense its in the same position as -Ztime-passes – useful for debugging the compiler and nothing else. --unpretty=mir is most likely to just get merged into -Z dump-mir (incompatible output format, files instead stdout).

Comparing MIR output to LLVM-IR/LLVM-BC is unfair here IMO and it should rather be compared with the --emit=obj instead. Why? Because in both cases this output, when paired with an appropriate version of a tool, will end up in asm or object. In that sense LLVM-IR/BC output is stable. There are no (and never should be any) tools for parsing the MIR dumps.

Contributor

nagisa commented Feb 12, 2017

The whole point of emiting MIR is for debugging. --unpretty=mir has little use to compiler devs by now, because -Z dump-mir simply provides more information. In that sense its in the same position as -Ztime-passes – useful for debugging the compiler and nothing else. --unpretty=mir is most likely to just get merged into -Z dump-mir (incompatible output format, files instead stdout).

Comparing MIR output to LLVM-IR/LLVM-BC is unfair here IMO and it should rather be compared with the --emit=obj instead. Why? Because in both cases this output, when paired with an appropriate version of a tool, will end up in asm or object. In that sense LLVM-IR/BC output is stable. There are no (and never should be any) tools for parsing the MIR dumps.

@shepmaster

This comment has been minimized.

Show comment
Hide comment
@shepmaster

shepmaster Feb 12, 2017

Member

--unpretty=mir has little use to compiler devs by now, because -Z dump-mir simply provides more information

I'm totally OK with whichever format...

incompatible output format, files instead stdout)

But for my own selfish reasons, I'd prefer that the MIR for the entire crate be output into a single file (just like LLVM-IR and ASM), as well as being triggered by --emit=.... This is just to make my life easier.

There are no (and never should be any) tools for parsing the MIR dumps.

How picky should we be about this aspect? The official playground already parses MIR to some extent.

Member

shepmaster commented Feb 12, 2017

--unpretty=mir has little use to compiler devs by now, because -Z dump-mir simply provides more information

I'm totally OK with whichever format...

incompatible output format, files instead stdout)

But for my own selfish reasons, I'd prefer that the MIR for the entire crate be output into a single file (just like LLVM-IR and ASM), as well as being triggered by --emit=.... This is just to make my life easier.

There are no (and never should be any) tools for parsing the MIR dumps.

How picky should we be about this aspect? The official playground already parses MIR to some extent.

@pnkfelix

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix Feb 17, 2017

Member

@rfcbot concern bootstrap-rustc-builds

with the change being planned here, will the -Z and --pretty/--unpretty flags continue to be available with the bootstrap rustc builds?

There are occasional times where I need to resort to looking at expanded output annotated with node-ids in order to make sense of ICE's that occur from a bootstrap compiler that I am in the process of constructing.

Member

pnkfelix commented Feb 17, 2017

@rfcbot concern bootstrap-rustc-builds

with the change being planned here, will the -Z and --pretty/--unpretty flags continue to be available with the bootstrap rustc builds?

There are occasional times where I need to resort to looking at expanded output annotated with node-ids in order to make sense of ICE's that occur from a bootstrap compiler that I am in the process of constructing.

@eddyb

This comment has been minimized.

Show comment
Hide comment
@eddyb

eddyb Feb 17, 2017

Member

Nowadays all you have to do is set RUSTC_BOOTSTRAP=1.

Member

eddyb commented Feb 17, 2017

Nowadays all you have to do is set RUSTC_BOOTSTRAP=1.

@pnkfelix

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix Feb 17, 2017

Member

@rfcbot resolved bootstrap-rustc-builds

(I'm assuming that whatever else is happening based on the change proposed here, RUSTC_BOOTSTRAP=1 will remain as a way to bypass the stability checks and allow one to again use -Z whatever.)

Member

pnkfelix commented Feb 17, 2017

@rfcbot resolved bootstrap-rustc-builds

(I'm assuming that whatever else is happening based on the change proposed here, RUSTC_BOOTSTRAP=1 will remain as a way to bypass the stability checks and allow one to again use -Z whatever.)

@MJDSys

This comment has been minimized.

Show comment
Hide comment
@MJDSys

MJDSys Mar 17, 2017

Contributor

One problem I noticed with this issue is that Cargo doesn't detect what version of rust is running before passing -Z flags.

As a real example, I've enabled CARGO_INCREMENTAL on one of my computers, and it recently ran into a bug on the nightly compiler. I've fallen back to the stable compiler for now, but I get warning about -Zincremental being passed due to this issue. It would be good if Cargo avoided passing -Z flags to rust before it becomes a hard error.

Would it help if I filed an issue about this against cargo?

Contributor

MJDSys commented Mar 17, 2017

One problem I noticed with this issue is that Cargo doesn't detect what version of rust is running before passing -Z flags.

As a real example, I've enabled CARGO_INCREMENTAL on one of my computers, and it recently ran into a bug on the nightly compiler. I've fallen back to the stable compiler for now, but I get warning about -Zincremental being passed due to this issue. It would be good if Cargo avoided passing -Z flags to rust before it becomes a hard error.

Would it help if I filed an issue about this against cargo?

@SimonSapin

This comment has been minimized.

Show comment
Hide comment
Contributor

SimonSapin commented Mar 17, 2017

frewsxcv added a commit to frewsxcv/rust that referenced this issue Mar 23, 2017

Rollup merge of #39891 - shepmaster:emit-mir, r=nikomatsakis
Teach rustc --emit=mir

I'm opening this PR to discuss:

1. Is this a good idea?
1. Is this a good implementation?

I'm sure people will have opinions on both points!

This spawned from rust-lang#31847 (comment), so I figured a prototype implementation could help provide a seed to talk about.
@est31

This comment has been minimized.

Show comment
Hide comment
@est31

est31 May 4, 2017

Contributor

See also issue #41743 .

Contributor

est31 commented May 4, 2017

See also issue #41743 .

alexcrichton added a commit to alexcrichton/rust that referenced this issue May 4, 2017

rustc: Forbid `-Z` flags on stable/beta channels
First deprecated in rustc 1.8.0 the intention was to never allow `-Z` flags make
their way to the stable channel (or unstable options). After a year of warnings
we've seen one of the main use cases, `-Z no-trans`, stabilized as `cargo
check`. Otherwise while other use cases remain the sentiment is that now's the
time to start forbidding `-Z` by default on stable/beta.

Closes #31847

alexcrichton added a commit to alexcrichton/rust that referenced this issue May 4, 2017

rustc: Forbid `-Z` flags on stable/beta channels
First deprecated in rustc 1.8.0 the intention was to never allow `-Z` flags make
their way to the stable channel (or unstable options). After a year of warnings
we've seen one of the main use cases, `-Z no-trans`, stabilized as `cargo
check`. Otherwise while other use cases remain the sentiment is that now's the
time to start forbidding `-Z` by default on stable/beta.

Closes #31847
@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton May 4, 2017

Member

All major stakeholders have checked in with checkboxes above, and this was re-reviewed during tools triage yesterday, and I've now opened a PR: #41751

Member

alexcrichton commented May 4, 2017

All major stakeholders have checked in with checkboxes above, and this was re-reviewed during tools triage yesterday, and I've now opened a PR: #41751

@durka

This comment has been minimized.

Show comment
Hide comment
@durka

durka May 4, 2017

Contributor

Removing --pretty also breaks cargo expand.

Contributor

durka commented May 4, 2017

Removing --pretty also breaks cargo expand.

alexcrichton added a commit to alexcrichton/rust that referenced this issue May 4, 2017

rustc: Forbid `-Z` flags on stable/beta channels
First deprecated in rustc 1.8.0 the intention was to never allow `-Z` flags make
their way to the stable channel (or unstable options). After a year of warnings
we've seen one of the main use cases, `-Z no-trans`, stabilized as `cargo
check`. Otherwise while other use cases remain the sentiment is that now's the
time to start forbidding `-Z` by default on stable/beta.

Closes #31847
@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton May 4, 2017

Member

@durka we've spent the last year printing that this is going to become an error. cargo expand will still work on nightly, as is expected.

Member

alexcrichton commented May 4, 2017

@durka we've spent the last year printing that this is going to become an error. cargo expand will still work on nightly, as is expected.

frewsxcv added a commit to frewsxcv/rust that referenced this issue May 4, 2017

Rollup merge of #41751 - alexcrichton:unstable-flags, r=eddyb
rustc: Forbid `-Z` flags on stable/beta channels

First deprecated in rustc 1.8.0 the intention was to never allow `-Z` flags make
their way to the stable channel (or unstable options). After a year of warnings
we've seen one of the main use cases, `-Z no-trans`, stabilized as `cargo
check`. Otherwise while other use cases remain the sentiment is that now's the
time to start forbidding `-Z` by default on stable/beta.

Closes #31847

frewsxcv added a commit to frewsxcv/rust that referenced this issue May 5, 2017

Rollup merge of #41751 - alexcrichton:unstable-flags, r=eddyb
rustc: Forbid `-Z` flags on stable/beta channels

First deprecated in rustc 1.8.0 the intention was to never allow `-Z` flags make
their way to the stable channel (or unstable options). After a year of warnings
we've seen one of the main use cases, `-Z no-trans`, stabilized as `cargo
check`. Otherwise while other use cases remain the sentiment is that now's the
time to start forbidding `-Z` by default on stable/beta.

Closes #31847

bors added a commit that referenced this issue May 5, 2017

Auto merge of #41751 - alexcrichton:unstable-flags, r=eddyb
rustc: Forbid `-Z` flags on stable/beta channels

First deprecated in rustc 1.8.0 the intention was to never allow `-Z` flags make
their way to the stable channel (or unstable options). After a year of warnings
we've seen one of the main use cases, `-Z no-trans`, stabilized as `cargo
check`. Otherwise while other use cases remain the sentiment is that now's the
time to start forbidding `-Z` by default on stable/beta.

Closes #31847

@bors bors closed this in #41751 May 5, 2017

hackeryarn added a commit to hackeryarn/rust that referenced this issue May 9, 2017

rustc: Forbid `-Z` flags on stable/beta channels
First deprecated in rustc 1.8.0 the intention was to never allow `-Z` flags make
their way to the stable channel (or unstable options). After a year of warnings
we've seen one of the main use cases, `-Z no-trans`, stabilized as `cargo
check`. Otherwise while other use cases remain the sentiment is that now's the
time to start forbidding `-Z` by default on stable/beta.

Closes #31847
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment