Make ForceWarn a lint level.

[cjgillot]

Follow-up to #85788
cc @rylev

[rust-highfive]

r? @davidtwco

(rust-highfive has picked a reviewer for you, use r? to override)

[rylev]

I like that this uses the existing infrastructure, but I personally find it a tiny bit more complicated to reason about since --force-warns isn't really a logical level. But I'm happy either way. 😊

[davidtwco]

Apologies for the delay in reviewing, I feel like this is an improvement to me, but I appreciate that it isn't logically a lint level. r=me if you and @rylev are happy with it.

[cjgillot]

I really have trouble understanding why you consider it as not being a lint level. The way I see it, force-warns is to warn what forbid is to error. Am I missing something?

[rylev]

Hmmm error is not a lint level. Did you mean deny? If so, then I see where you're coming from.

My issue is that Level is also used for lint definitions, and it didn't make sense to me for a lint to define its level as being ForceWarn. However, I now see that it might make sense for there to be a level that is logically like Warn but that cannot be turned off. Just like Forbid is like Deny but cannot be turned off.

I believe my issue is one of nomenclature. From the command line, the user is logically forcing a certain lint to warn so the name "force-warn" makes sense. But at the lint definition site, if you sent level to ForceWarn you're really saying, we want that this always emits a warning so perhaps the name AlwaysWarn makes more sense.

I'm largely in favor this change now, but two questions:

• Does the name ForceWarn actually make sense? Since the command line option is unstable, it's easy for us to change the name.
• Can we document somewhere the analogy of force-warn is to warn as forbid is to deny? This should clarify things.

[bors]

☔ The latest upstream changes (presumably #86627) made this pull request unmergeable. Please resolve the merge conflicts.

[davidtwco]

r? @rylev

[cjgillot]

Hmmm error is not a lint level. Did you mean deny? If so, then I see where you're coming from.

Yes

My issue is that Level is also used for lint definitions, and it didn't make sense to me for a lint to define its level as being ForceWarn. However, I now see that it might make sense for there to be a level that is logically like Warn but that cannot be turned off. Just like Forbid is like Deny but cannot be turned off.

I believe my issue is one of nomenclature. From the command line, the user is logically forcing a certain lint to warn so the name "force-warn" makes sense. But at the lint definition site, if you sent level to ForceWarn you're really saying, we want that this always emits a warning so perhaps the name AlwaysWarn makes more sense.

I chose ForceWarn to mirror the command line option. Happy to change.

I'm largely in favor this change now, but two questions:

* Does the name `ForceWarn` actually make sense? Since the command line option is unstable, it's easy for us to change the name.

* Can we document somewhere the analogy of force-warn is to warn as forbid is to deny? This should clarify things.

I will do both changes at once if you decide to change the name.

[rylev]

@cjgillot Actually, let's merge this first. We can bike shed the name in a new PR as part of stabilization.

[davidtwco]

@bors r+

[bors]

📌 Commit e42271d has been approved by davidtwco

[bors]

⌛ Testing commit e42271d with merge 8971fff...

[bors]

☀️ Test successful - checks-actions
Approved by: davidtwco
Pushing 8971fff to master...

[ehuss]

This seems to have broken interaction with --force-warns and --cap-lints. Cargo does the following when running cargo fix --edition:

rustc main.rs --force-warns=rust-2021-compatibility -Zunstable-options --cap-lints=warn

The lints no longer fire on an example:

#![allow(ellipsis_inclusive_range_patterns)]

pub fn f() -> bool {
    let x = 123;
    match x {
        0...100 => true,
        _ => false,
    }
}

This is somewhat different from #86572, since --cap-lints=warn shouldn't set can_emit_warnings.

Can you take a look at this?

[rylev]

The interaction with cap-lints has been fixed in #86572.