rust-lang
Allow informational -Z flags on stable compiler
Background
There are some rustc -Z options that only output extra information, that are really useful on the stable compiler when investigating compilation time issues. -Z time-passes reports (among other things) the time spent running the linker; -Z self-profile is a popular way to investigate other compiler slowness.
I've encountered a number of blog posts where people document using RUSTC_BOOTSTRAP=1 as a backdoor way of enabling these tools on the stable compiler. It would be nice if these flags just worked on stable, so people don't get mixed messages about whether it's ok to use RUSTC_BOOTSTRAP in their own projects.
Others on Zulip have suggested this is also true of other -Z options: they are useful for debugging on stable; don't affect the generated code; and there's no expectation of stability guarantees for the "informational" output.
Proposal
The following set of -Z options should be made available on the stable compiler, behind some other command-line argument (e.g. -I for "informational"):
-
-Z time-passes -
-Z self-profile -
-Z trace-macros -
-Z treat-err-as-bug -
-Z hir-stats -
-Z meta-stats -
-Z verbose
This list is not meant to be exhaustive, but is long enough to demonstrate that the category is useful in the long term.
This category only includes options that do not affect the code that is output, and have the side-effect of returning additional information to the user (e.g. printed to stdout, or written to a file). The format of the information returned may be unstable and/or undocumented.
Mentors or Reviewers
@jyn514 and @compiler-errors gave initial positive feedback, as did several others on the zulip thread-- I don't know which people to tag here, so apologies if I should have named everyone.
Process
The main points of the Major Change Process are as follows:
- [x] File an issue describing the proposal.
- [ ] A compiler team member or contributor who is knowledgeable in the area can second by writing
@rustbot second.- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
-C flag, then full team check-off is required. - Compiler team members can initiate a check-off via
@rfcbot fcp mergeon either the MCP or the PR.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
- [ ] Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.
You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
cc @rust-lang/compiler @rust-lang/compiler-contributors
