Lint level control

[epage]

Sometimes it's useful to be able to change the alert level of specific lints for a particular item or an entire module. Clippy and rustc lints have already stabilized syntax like #[deny(lint_name)] and #[allow(lint_name)], and our syntax choices would ideally be reasonably compatible with those.

The kinds of controls we'd like to include are:

• Forbid: change not allowed regardless of version bump
• Major change: only allowed in major version bumps
• Minor change: only allowed in minor version bumps
• Informational: allowed in all version bumps, but nevertheless reported; for example, if human judgment is necessary to determine whether the change is concerning or not
• Ignored: not reported at all

The lint level control adjustments should allow both raising and lowering the level of a given lint. For example:

• semver-minor lints should be possible to be upgraded to semver-major
• semver-major lints should be possible to be downgraded to semver-minor
• it should be possible to annotate an entire module as downgrading all semver lints to ignored / informational, e.g. in macro-only or explicitly-unstable modules.

[epage]

To clarify something, lints should have two "levels":

• reporting level (forbid, deny, warn, allow)
• severity level (major, minor, patch)

In that context, wonder if we should have "virtual reporting groups" based on severity levels, so you can say -Apatch and allow every lint currently configured as "patch".

rustc has the concept of "virtual groups". These are lint groups that are made up of every lint that meets a qualification.

So say you have a command-line like -A<some-warning> -Dwarnings -W<some-warning>. warnings is a virtual reporting group of every lint that is at reporting level "warning". If I understand rustc correctly, by the fact that <some-warning> is allow at the time of denying warnings, we won't deny <some-warning> and can turn it back on.

Granted, the [lints] table doesn't support this back and forth but I was wanting to intentionally show a more perverse case to demonstrate the concept.

[obi1kenobi]

So say you have a command-line like -A<some-warning> -Dwarnings -W<some-warning>. warnings is a virtual reporting group of every lint that is at reporting level "warning". If I understand rustc correctly, by the fact that <some-warning> is allow at the time of denying warnings, we won't deny <some-warning> and can turn it back on.

Oh, interesting. I would have assumed that at the end of this command, <some-warning> would be set to warn because -W<some-warning> appears last in the args sequence. In my interpretation, -A<some-warning> -Dwarnings -W<some-warning> and -Dwarnings -W<some-warning> would produce an equivalent effect.

When resolving this issue, we should check this edge case in rustc, match its behavior, and ensure we have tests to back this up.

[epage]

Its at least my supposition based on the vague descriptions I've seen about -A<some-warning> -Dwarnings. I agree about double checking.

However, depending on the layers of abstraction and the CLI, this specific corner case might not matter (so long as -A<some-warning> -Dwarnings works). Its a question of whether you exclusively use Cargo.toml (which can't represent the above case) or also provide the CLI (which can represent the case).

[obi1kenobi]

I was assuming we'd eventually support both: Cargo.toml recommended for most use cases, CLI available as an override. Perhaps not both added at the same time, of course — probably Cargo.toml first.