Overwriting group flags

[Byter09]

Hello.

I'm working on a project that has several smaller Rust projects and wanted to add every possible lint or lint group to them so we know exactly what's still there to fix and know exactly when something bad is introduced. I should note that these smaller projects are not in a workspace.

Using the typical deny(...) for a group and then allow(...) another lint inside it is what I wanted to do initially, but also having rustc lints in that list quickly bloated it to about 45 lines. And managing this list in every small project is pain. So I ended up writing a small script that can be run from inside the CI and by developers alike without having to manually update all lib.rs or main.rs files every time a new lint can be deny(...)'d.

When running the script it turned out that all of the lints in groups that were on deny suddenly popped up again even though they were allowed.

For example: cargo clippy -- --deny clippy::pedantic --allow clippy::similar_names still triggers the similar_names lint. Using

#![deny(clippy::pedantic)]
#![allow(clippy::similar_names)]

works flawlessly.

This was tested with clippy 0.0.212 (b2601be 2018-11-27) and pretty much forces me to fill 4 lib.rs/main.rs files with about 45 allow and deny-s.

Is there a reason a allow flag does not overwrite a deny flag? If so, why?

[Manishearth]

I think this is a bug on the rustc end, we don't do anything special for lint groups

[Byter09]

I haven't tested it, but this should then also not work correctly when using lint groups from rustc and activating a single lint in there? I'll try it out.

[Byter09]

I tried it with
RUSTFLAGS="--deny rust-2018-idioms --allow elided-lifetimes-in-paths" cargo check and it's still complaining about anonymous lifetimes in my generated protobuf files. So that's good as it proves that this is a bug in rustc.

What about this issue then? Shall I close it?

[Manishearth]

Open an issue on the rust side, feel free to link to it here and leave this open or closed as you wish.

[Byter09]

Thank you @Manishearth for taking the time to respond. I'll close this issue.