force-warn for edition lints

[nikomatsakis]

Summary

Compiler changes:

• Create MCP
• Add a --force-warn XXX option that is given either a lint or lint group XXX
• When this command line option is used, all other lint settings the lints covered by XXX will always issue warnings, regardless of whether they are "allowed" by the code or command-line options

Cargo fix changes:

• This command line option is supplied by cargo fix --edition in 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

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.

[nikomatsakis]

@rustbot assign @rylev

[nikomatsakis]

Some mentoring notes:

• To add an option, modify this code to add the force-warn, modeled on cap-lints:

https://github.com/rust-lang/rust/blob/0eb4e811915eae2964e6072086d4a13c8daf136b/compiler/rustc_session/src/options.rs#L131-L133

Extend the LintLevelMap to contain a list of "force warn" lists:

https://github.com/rust-lang/rust/blob/0eb4e811915eae2964e6072086d4a13c8daf136b/compiler/rustc_middle/src/lint.rs#L152-L157

Modify the lint_levels query to populate the list from the command line option:

https://github.com/rust-lang/rust/blob/0eb4e811915eae2964e6072086d4a13c8daf136b/compiler/rustc_lint/src/levels.rs#L31-L32

Extend LintLevelSource with an option for ForceWarn:

https://github.com/rust-lang/rust/blob/0eb4e811915eae2964e6072086d4a13c8daf136b/compiler/rustc_middle/src/lint.rs#L17-L32

Modify the level_and_source to check the list "force warn" and return Warn if the lint is present, regardless of the other parameters (return ForceWarn):

https://github.com/rust-lang/rust/blob/0eb4e811915eae2964e6072086d4a13c8daf136b/compiler/rustc_middle/src/lint.rs#L166-L173

[nikomatsakis]

Write some tests:

• // compile-flags: --force-warn XXX to 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)])

[jam1garner]

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/FromIterator migration lint, even if the lint is set as a warning/error on 2021 edition, it would never be hit due to hitting error[E0034]: multiple applicable items in scope and 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/FromIterator should 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.

[nikomatsakis]

@jam1garner that text was referring specifically to those warnings which will become hard errors in the new edition, eg the items in #83213

[inquisitivecrystal]

@rustbot label +A-lint