Stabilize "force warn" option

[nikomatsakis]

We need #85512 to be stabilized so that cargo fix can use it.

[rylev]

Work that needs to be done to stabilize:

• Merge Make --force-warns a normal lint level option #86970
• Change name to --force-warn Rename force-warns to force-warn #87346
• Remove from the unstable book.
• Update the rustc book.
• Create a stabilization report.
• Make usage stable.

[inquisitivecrystal]

@rylev You mentioned that you're planning to work on stabilization. I'm happy to help out with this, but I don't want to steal your project.

[rylev]

@inquisitivecrystal I’m happy to split the work with you. I was going to open a PR rename the option to —force-warn, and I’m already working on a stabilization report. Let me know if you want to take on some piece of the work outlined above (or if we’re missing something that should be added to the list).

[inquisitivecrystal]

Well, I'm happy to help out however I can. You working on the stabilization report is definitely a good idea, since I wouldn't have any clue how to do that. I'm not entirely sure I know how to do the documentation PR, but I can work it out. The other steps are simple enough that anyone can do them. I'd definitely be happy to take final stabilization, as I find those kind of fun. I guess overall, it would make sense for me to take stabilization, and maybe also the documentation if you'd like me to that?

Incidentally, does this need to go through FCP after we get all the other stuff in order?

[inquisitivecrystal]

I've got a WIP combined documentation and stabilization PR that's pretty close to completion. I'm hoping to be able to submit it as a draft in the next few days, though it wouldn't be merged until the stabilization report and FCP. @rylev, is that alright with you?

[rylev]

@inquisitivecrystal Yep! Feel free to open the draft PR, and I will have the stabilization report done soon.

[rylev]

Stabilization Report 🎉

(Let me know if I missed anything)

Description of behavior

• A new command line option force-warn is added which (like other lint options like -A, -W, etc.) accepts a lint name or lint group and ensures that if that lint is triggered it is always emitted as a "warn" level lint, ignoring any other lint level specification (cap-lints, attributes in code, command line options, etc. -- including levels like forbid).
• force-warn is to warn as forbid is to deny. It behaves just like the other option but cannot be suppressed through mechanisms like --cap-lints.

The primary use case of this feature is for cargo fix which uses this feature to ensure that compatibility lints are emitted (and subsequently the fixes for those lints are applied).

Possible points of contention

This feature is relatively low risk as we don't foresee it being widely used, and behavior of lints is not a part of the stability guarantee for Rust. Therefore, in the worst case, this option can be removed completely (though we would need to ensure that passing the option would not cause an error).

Small points of possible contention:

• The name force-warn was bikeshedded but was not selected due to any particular criteria other than "sounding good" to the PR authors and reviewers.

Documentation and Testing

• Stablization PR: Stabilize and document --force-warn #87472

This feature is being tested through the usage of cargo fix in the Rust 2021 edition testing. So far, no issues related to its usage have been found.

Remaining issues for stabilization can found here: #86516 (comment)

[Mark-Simulacrum]

force-warn is to warn as forbid is to deny. It behaves just like the other option but cannot be suppressed through mechanisms like --cap-lints.

Can we elaborate on this point? I think it'd be useful to list the behavior in a sort of matrix with cap-lints on one axis and the environment the lint is issued in (deny/allow(warnings); allow/warn/deny/forbid(some_specific_lint)) on the other.

For example, does force-warn cause an allow'd lint to fire? If it does fire, is it forcing it to warn level, or does it become a regular warning and is affected by deny(warnings) to trigger a compilation error?

---

A separate question is whether --force-warn warnings is accepted. Warnings is not a statically defined lint group, and it may not be quite well suited to what this flag does. Preventing it would leave room open in the future and protect against unexpected behavior in the meantime.

[inquisitivecrystal]

I have something of a last minute proposal. I was just updating the docs to reflect the fact that --cap-lints doesn't work for force-warn. This is extremely confusing, since it breaks completely with the behavior for forbid. I don't think we should stabilize it in this state.

I have two alternatives. First, we could make cap-lints work the same way for force-warn that it does for everything else. This would require a change to cargo's fix system to set its cap lints to force-warn instead of warn, but that's a one-line change. Alternatively, we could say that setting cap-lints to warn actually sets it to force-warn. This is slightly inconsistent, but you could argue that it's probably what the user intends anyway.