Description
Proposal
Add mechanism for forcing lints to trigger.
Summary
- Add a
--force-warn XXXoption that is given either a lint or lint groupXXX - When this command line option is used, all other lint settings the lints covered by
XXXwill always issue warnings, regardless of whether they are "allowed" by the code or command-line options - This command line option is supplied by
cargo fix --editionin order to force migration lints etc to be considered
Motivation
We would like to take some existing warnings and make them into errors in the new edition. We anticipate this being a common pattern. The problem is that these warnings, if they already exist, may be marked a #[allow] in various code bases. As a result, cargo fix would not see the migration suggestions and migration would not succeed.
Proposed plan
To become part of a migration, existing lints can be directly added into rust-2021-migration group.
Caveat: Multiple groups
There has been some concern about members of multiple groups.
This plan may mean that they are members of multiple groups. This is generally discouraged for reasons not clearly documented -- Niko's hypothesis is that the reason for this is that (e.g.) the code doesn't consider intersection between two groups, and hence #[allow(group1)] and #[warn(group2)] may result in either allow or warn for any common members, depending on the order in which those directives are processed. Perhaps others can confirm. This seems like an independent bug that should be fixed -- however, using this command line option, it is not a big probem because the members of rust-2021-migrations will be warn regardless of what other groups they may belong to.
There may be confusion in other parts of the code, such as diagnostics.
Also, we don't expect users to commonly add rust_2021_migrations.
This plan means that some lints are members of multiple groups. This has been discouraged but in the past but we currently believe that it should work fine. We should test the scenario where a lint is in two groups and one of those groups is allow.
Alternatives
We could instead introduce a fresh copy of these lints that is a member of rust_2021_migrations. For example, if there is a lint foo, maybe we make a foo_2021 lint that is specifically for the migration. We could perhaps make this convenient to issue in the code by having some option when creating the lint that is like .migration(RUST_2021_MIGRATioN). This could also make the lint into a hard error automatically in the new edition, regardless of the lint level.
Mentors or Reviewers
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.