Description
Proposal
The -Aunknown_lints flag tells the compiler not to warn or error on any unrecognized #[allow(...)] arguments. However, unstable lints are treated differently and will produce an error that a feature needs to be enabled. Here's a quick example of where this can cause problems:
must_not_suspend
The must_not_suspend lint was added as a stable lint and remained that way for about a month. During this time it was discovered that the lint had false positives, and so was recently gated behind a feature. Upgrading a project through this process could go as follows:
- Add
-Aunknown_lintsand mark up any code that will trigger the lint with#[allow(must_not_suspend)] - Upgrade the compiler
- Remove
-Aunknown_lintssince the lints are now known
However, after the lint is destabilized there is no further upgrade path:
- Removing the
#[allow(must_not_suspend)]attributes will trigger the lint on the current version of the compiler. - Adding
-Amust_not_suspendwill allow the removal of the attributes, but trigger an error thatmust_not_suspendis nightly as soon as the compiler is upgraded. - Using
-Aunknown_lintsdoes not prevent the error from-Amust_not_suspendafter the compiler is upgraded. - There is no way for us to make the compiler ignore the
must_not_suspendlint.
Escaping this migration trap is more difficult than it needs to be. -Aunknown_lints is a great mechanism for introducing lints to a codebase, but there's no equivalent for removing them. This forces us to perform a compiler upgrade and code change in lockstep, which is not always convenient or possible. We can do better.
Using -Aunknown_lints to ignore nightly lints
An easy way out of this would be to change the behavior of -Aunknown_lints to also ignore any uses of nightly lints. This would allow us to upgrade the compiler gracefully without introducing any sequence points where the build fails. When the lint is re-stabilized, it can be allowed on a case by case basis.
A possible alternative would be to leave the behavior of -Aunknown_lints the same and introduce a new -I flag that takes a lint name and treats the lint as unknown. An example here would be to combine -Imust_not_suspend to act as if the lint does not exist with -Aunknown_lints to ignore any unknown lints. This has the downside that doing so will not prompt users to handle the lint after it is stabilized.
Mentors or Reviewers
I am willing to take on the work to get this done. I'm not sure who would be the best person to review this work, but I can probably tug on @tmandry's sleeve to review.
Process
The main points of the Major Change Process are as follows:
- 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.