cargo icon indicating copy to clipboard operation
cargo copied to clipboard

Packages overriding inherited lints in Cargo.toml + adding lints

Open GilShoshan94 opened this issue 1 year ago • 1 comments

Problem

Hi,

With the release of 1.74.0 and Lint configuration through Cargo I was interrested to have lints configure for my workspace and to override some of them in specific crates.

I was met with an error in rust-analyzer that stopped working with error :

cannot override workspace.lints in lints, either remove the overrides or lints.workspace = true and manually specify the lints"

I was surprised as my intuition was that it should have work, especially with the level system for each lint. Nothing in the Cargo Book mention that it would be impossible to override lints if inherited from the workspace (I looked in the manifest format and in workspace reference)

After researching a long time in various places, I finally found in the RFC 3389 (here, precisely) the confirmation that this is an hard error:

Currently, it is a hard error to mix workspace = true and lints. We could open this up in the future for the package to override lints from the workspace.

(By the way, after testing, it's not only overriding lints that is problematic, also adding new lints to the inherited lints in a crate is an hard error)

While it is still possible in lib.rs and/or in main.rs to add attributes #![allow(...lints...)] to override lints, I think it should still be added, as with the level system, it seems clear who override who. For me the main reason I prefered to put my "global/crate wide" lints in the cargo.toml manifest, was to get a clear view of wich crate in my workspace override what lint without touching to lib.rs/main.rs

For example we could have a workspace where in general, we wish to deny unsafe code but we could have one very low level crate that override it because we absolutly need it.

Example:

# Cargo.toml of workspace

[workspace.lints.rust]
unsafe_code = { level = "deny", priority = -1 }

[workspace.lints.clippy]
all = { level = "deny", priority = -1 }
cargo = { level = "deny", priority = -1 }
pedantic = { level = "deny", priority = -1 }
too_many_lines = "allow"
# Cargo.toml of a member crate

[lints]
workspace = true

[workspace.lints.rust]
unsafe_code = "allow"

Proposed Solution

I see 2 solutions:

  1. We can override and/or add lints in crates that inherited from workspace as I explained above.
  2. We leave the lints in cargo.toml as it is now but we document in the Cargo Book (here and here) the interdiction to add or/and override if lints.workspace = true. And we explain that the idiomatic way to do is to use the attributes #![allow(...lints...), deny(....), ....] in lib.rs/main.rs

I personally prefer solution 1) as it is more intuitive and the level system permits this.

Notes

No response

GilShoshan94 avatar Dec 12 '23 10:12 GilShoshan94

Huh, for some reason I thought we had an issue for this but I'm not seeing it.

Something we'd have to decide is whether we treat this as lints.rust.unsafe_code.extend(workspace.lints.rust.unsafe_code) or whether we sort workspace lints and then sort package lints.

epage avatar Dec 12 '23 14:12 epage