Disabling -Z for stable builds is a mistake

[jethrogb]

If your code compiles on Rust stable 1.0, it should compile with Rust stable 1.x with a minimum of hassle.

I’m not sure how you go from here to “-Z must not work on stable”. Most, if not all of the -Z flags, and certainly those people seem to care about in this thread, do not affect whether or how your code builds at all! They are merely diagnostic tools used during development. I really don’t see how having those available would creates de-facto unwanted ecosystem stability.

If it compiles on the stable toolchain, it will continue to compile on new versions thereof, modulo minor disambiguations (like type annotations).

I’m thinking more along the lines of if it compiles with -Z, it will compile without.

[nikomatsakis]

They are merely diagnostic tools used during development.

So here’s the thing. I think I would be in favor of making a stable set of debuginfo switches with explicitly unstable output, much as we did with --emit mir. I would (as with MIR) include some text in the output itself warning that this info is intended for human readers and may go away, and then we can just package up the things we have now. If in the future we decide to remove one of these options, we’ll just change the output to describe the new option that can be used instead. We’re basically just blocked on somebody making PRs – maybe we want a grouping for this, sort of like --debug XXX?

[zackw]

I use -Zparse-only with syntastic in vim to get very quick feedback on whether I’ve committed a syntax error.

This feature is available in GCC, Clang, etc under the name -fsyntax-only. Command line compatibility with C compilers is not a priority feature for rustc (after all, many of the knobs you need for C don’t even make sense in Rust), but it sure would make my fingers happy if this particular mode were stabilized under the name they already know it by.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.