Repository navigation
force-warn for edition lints #85512
Description
Activity
Some mentoring notes:
- To add an option, modify this code to add the force-warn, modeled on cap-lints:
Extend the
LintLevelMapto contain a list of "force warn" lists:Modify the
lint_levelsquery to populate the list from the command line option:Extend
LintLevelSourcewith an option forForceWarn:Modify the
level_and_sourceto check the list "force warn" and returnWarnif the lint is present, regardless of the other parameters (returnForceWarn):Write some tests:
// compile-flags: --force-warn XXXto add flags- Test for:
- Force warn on a lint name that is allowed by name
- Force warn on a lint name that is allowed by a group that contains it
- Force warn on a lint group that contains a lint allowed by its name
- Force warn on a lint group that contains a lint allowed by group
- Force warn on a lint group that contains a lint allowed by some other group
- Force warn on a lint that is allowed by warnings group (
#[allow(warnings)])
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.
I was under the impression that most (if not all) migrations lints will already result in an error by means of the fact that the code will break. For example with the
TryFrom/TryInto/FromIteratormigration lint, even if the lint is set as a warning/error on 2021 edition, it would never be hit due to hittingerror[E0034]: multiple applicable items in scopeand compilation stopping before the lint (as the lint has to occur after trait resolution to know whether the trait is actually outside of std/core).If the purpose of such is for users to just change edition to 2021 without running migration fixes to get an error indicating the error being 2021-edition-related, I would imagine we'd need to implement an additional bit of detection/help text for that emission of E0034.
Such a help text should be possible, just detecting that one of the traits in the set of applicable items is
TryFrom/TryInto/FromIteratorshould be enough. Although we should likely also detect that the import comes from being auto-imported, or if we don't make it clear in the help text that it only "might" be 2021-related.@jam1garner that text was referring specifically to those warnings which will become hard errors in the new edition, eg the items in #83213
Reacted by jam1garner- added a commit that references this issue
on Jun 4, 2021 @rustbot label +A-lint
I'll post a Cargo PR to start using the new flag, and enable 2021 migrations.
There is some follow-up working being pursued (#86009 and supporting
--cap-lints), that I think would be good to resolve before stabilizing the flag. (And it needs to be stabilized before 2021 is stabilized.)Reacted by Ryan LevickI'll work on stabilization. 👍
Summary
Compiler changes:
--force-warn XXXoption that is given either a lint or lint groupXXXXXXwill always issue warnings, regardless of whether they are "allowed" by the code or command-line optionsCargo fix changes:
cargo fix --editionin order to force migration lints etc to be consideredMotivation
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 fixwould 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-migrationgroup.Caveat: Multiple groups
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 lintfoo, maybe we make afoo_2021lint 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.