rustc book does not specify priority between lint options like -A and attributes

[sourcefrog]

Location

https://doc.rust-lang.org/rustc/lints/levels.html

Summary

This page describes that you can configure the allow/warn/deny/etc level of various lints or groups using attributes and command-line options.

It does not currently specify whether options have priority above or below in-code attributes, and I think it would be helpful if it did.

If you like, I can look at what the current behavior is and send a PR documenting it.

[jieyouxu]

I agree that the priority for lint levels should be documented, especially because the priority is not trivial: level levels are affected by:

• Command-line options for a specific lint: e.g. -A <lint-name> or -W <lint-name>
• Command-line options for a specific lint group: e.g. -A <lint-group-name> or -W <lint-group-name>
• Command-line options (allow/deny/warn) for the special warnings lint group: e.g. -D warnings
• --cap-lints=<LEVEL>
• Hierarchical in-source lint level attributes for specific lint/lint groups/warnings: #[allow(...)], #![warn(...)] etc.

[sourcefrog]

In case it's interesting or helpful, the context for this is sourcefrog/cargo-mutants#322, where cargo-mutants wants to run cargo build making sure that most lints are not treated as errors, but still treating const_eval_long_running as an error. (If it injects a mutation that causes a variable to be unused, that shouldn't cause the compilation to fail, but if it cause a const function to hang then it would be better that the compiler does not hang.)

Currently we use --cap-lints but that has the drawback that it also turns off const_eval_long_running.

Probably some of this goes beyond just documentation into wishing for more detailed control from the command line, or suggesting that const eval hangs are more than just a lint, but having at least some authoritative docs on what the behavior is meant to be today would be nice.