[mehbark]

Based on #1648, this lint checks for allow or expect attributes with the warnings group; for example, #![allow(warnings)] instead of #![allow(non_snake_case)].
This is generally suspicious (though perhaps not the literal category), especially if you're using clippy. The use of "blanket" comes from blanket_clippy_restriction_lints.

Some questions about this lint that I don't know the answers to:

• Is this even something we want?
• What's the right name for this?
• What category is this?
• Should this be extended to check for #[allow(clippy)]?
• Would a customizable allow/except denylist be better?
• How do we issue an "unsilenceable" warning instead of an error?

Also the error messages, documentation, and testing could be better.

---

changelog: [blanket_allow_warnings]: new lint

[rustbot]

Thanks for the pull request, and welcome! The Rust Project is excited to review your changes, and you should hear from @llogiq (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: 8 candidates
• 8 candidates expanded to 8 candidates
• Random selection from Jarcho, dswij, llogiq, samueltardieu

[github-actions]

Lintcheck changes for f928210

Lint	Added	Removed	Changed
clippy::blanket_allow_warnings	6	0	0

This comment will be updated if you push new changes

[DanielEScherzer]

community review - inline suggestion

View changes since this review

[blyxyas]

Hello @mehbark, mind if we use your PR for some teaching?
@medzernik, I think that we've never implemented a lint, could you take a look here? It's a pretty simple lint, so I'm sure you'll have no problems! (=ↀωↀ=)

[rustbot]

Some changes occurred in clippy_lints/src/doc

cc @notriddle

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[medzernik]

Hi! Thanks for the PR. Could you please rebase it so it has no merge commits? It makes the review process basically impossible with 940+ changed files.

Once that is done, I can continue to review. Thanks!

View changes since this review

[medzernik]

Some questions about this lint that I don't know the answers to:

Is this even something we want?
What's the right name for this?
What category is this?
Should this be extended to check for #[allow(clippy)]?
Would a customizable allow/except denylist be better?
How do we issue an "unsilenceable" warning instead of an error?
Also the error messages, documentation, and testing could be better.

I kinda like the lint idea. I think it being an optional lint would help environments, where there needs to be stricter control over the amount of allowed lints to go through - especially in CI scenarios.

I think the name is fine? Unless there are other opinions :D

The category I would actually suggest maybe the clippy::suspicious one, it really does feel like something is off if someone has to allow an entire category blanked file.

Customizable allow and deny list would be very nice, however I do see value (from my work experience) of a global ban on allow warnings, especially for CI/CD tests.

I'm not quite sure how do we issue an unsilenceable warning yet, I think @blyxyas would know much better than me in this case 😶

I also ran this across the lintcheck groups and there is indeed just one occurence of this lint being applied - in the regex crate in the builders.rs file on line 1:1 where someone actually used this. I think the impact on regular crates is therefore minimal and could work well for those who opt-in as an additional safeguard.

I tried the lint with some macros and edge cases, from what I've tried it seemed to work nice.

I think so far just removing the TODO and maybe some additional comments would be nice, after that's done I will approve, but of course the final approval is on @blyxyas.

Thanks!

View changes since this review

[medzernik]

Leftover TODO here.

[rustbot]

☔ The latest upstream changes (possibly #17678) made this pull request unmergeable. Please resolve the merge conflicts.