-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Warn when a lint table has a group at the same priority as lints #12918
Comments
This was left as a future possibility in the RFC.
|
I'm confused by this.
Does what I expect it to do
Works just fine too. I would expect that if I override a specific lint from a group that was included, that the override wins. Which is what Rust itself seems to do, regardless of sort order. Only in the case of 2 groups disagreeing on a setting is when I would think to start using priorities. |
|
Is there a workaround for this in the meantime? I keep coming back around to this issue. I'm forced to just use -A flag on cargo directly and still can't seem to make anything work in config.toml or Cargo.toml. |
There is a PR for a clippy lint for when groups are the same priority as lints. For why you are having difficulty, its hard to say without a reproduction case. |
Add `lint_groups_priority` lint Warns when a lint group in Cargo.toml's `[lints]` section shares the same priority as a lint. This is in the cargo section but is categorised as `correctness` so it's on by default, it doesn't call `cargo metadata` though and parses the `Cargo.toml` directly The lint should be temporary until rust-lang/cargo#12918 is resolved, but in the meanwhile this is an common issue to run into - #11237 - #11751 - #11830 changelog: Add [`lint_groups_priority`] lint r? `@flip1995`
i'm not sure if this is a bug in this new behavior, but after updating to 1.78 i'm getting error: lint group `pedantic` has the same priority (0) as a lint
|
16 | pedantic = "warn"
| ^^^^^^^^ ------ has an implicit priority of 0
17 | wildcard_enum_match_arm = "warn"
| ----------------------- has the same priority as this lint
|
= note: the order of the lints in the table is ignored by Cargo
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#lint_groups_priority
help: to have lints override the group set `pedantic` to a lower priority
|
16 | pedantic = { level = "warn", priority = -1 } these both have the same level, so i'm not sure why it would need a priority. |
FYI that is a clippy lint and there is at least rust-lang/rust-clippy#12270 opened against it which is similar to what you are seeing. |
Cargo.lock was updated to version 4 manually. All Git refs in our Cargo.lock appear to be encoded correctly. See: - rust-lang/cargo#12280 - rust-lang/cargo#12852 The clippy::incompatible_msrv lint may be useful in the future. We currently do not specify rust-version in Cargo.toml. Our libraries are not designed to be used outside Grandine. rust-toolchain.toml makes rust-version redundant for builds inside this repository. See: - https://doc.rust-lang.org/1.78.0/cargo/reference/manifest.html#the-rust-version-field - https://rust-lang.github.io/rust-clippy/rust-1.78.0/#/incompatible_msrv The clippy::lint_groups_priority lint produces false positives: - rust-lang/cargo#12918 (comment) - rust-lang/rust-clippy#12270 Luckily, lints inherited from a workspace do not trigger it. The issue appears to be fixed in rust-lang/rust-clippy#12827. The reason public functions trigger clippy::single_call_fn is actually our setting of avoid-breaking-exported-api. We assumed it was a bug.
Cargo.lock was updated to version 4 manually. All Git refs in our Cargo.lock appear to be encoded correctly. See: - rust-lang/cargo#12280 - rust-lang/cargo#12852 The clippy::incompatible_msrv lint may be useful in the future. We currently do not specify rust-version in Cargo.toml. Our libraries are not designed to be used outside Grandine. rust-toolchain.toml makes rust-version redundant for builds inside this repository. See: - https://doc.rust-lang.org/1.78.0/cargo/reference/manifest.html#the-rust-version-field - https://rust-lang.github.io/rust-clippy/rust-1.78.0/#/incompatible_msrv The clippy::lint_groups_priority lint produces false positives: - rust-lang/cargo#12918 (comment) - rust-lang/rust-clippy#12270 Luckily, lints inherited from a workspace do not trigger it. The issue appears to be fixed in rust-lang/rust-clippy#12827. The reason public functions trigger clippy::single_call_fn is actually our setting of avoid-breaking-exported-api. We assumed it was a bug.
Signed-off-by: strawberry <strawberry@puppygock.gay>
Signed-off-by: strawberry <strawberry@puppygock.gay>
Signed-off-by: strawberry <strawberry@puppygock.gay>
Signed-off-by: strawberry <strawberry@puppygock.gay>
Problem
The sorting behaviour is causing confusion, me included as I thought this was a bug until I read the RFC
rust-lang/rust-clippy#11751 (comment)
rust-lang/rust-clippy#11237
Steps
No response
Possible Solution(s)
No response
Notes
No response
Version
No response
The text was updated successfully, but these errors were encountered: