1
Fork 0

Allow #[deny(..)] inside #[forbid(..)] as a no-op with a warning

Forbid cannot be overriden. When someome tries to do this anyways,
it results in a hard error. That makes sense.

Except it doesn't, because macros. Macros may reasonably use `#[deny]`
in their expansion to assert
that their expanded code follows the lint. This is doesn't work when the
output gets expanded into a `forbid()` context. This is pretty silly,
since both the macros and the code agree on the lint!

Therefore, we allow `#[deny(..)]`ing a lint that's already forbidden,
keeping the level at forbid.
This commit is contained in:
Noratrieb 2024-10-17 19:34:04 +02:00
parent 3a85d3fa78
commit e78d78868a
11 changed files with 84 additions and 32 deletions

View file

@ -493,7 +493,10 @@ impl<'s, P: LintLevelsProvider> LintLevelsBuilder<'s, P> {
//
// This means that this only errors if we're truly lowering the lint
// level from forbid.
if self.lint_added_lints && level != Level::Forbid && old_level == Level::Forbid {
if self.lint_added_lints && level == Level::Deny && old_level == Level::Forbid {
// Having a deny inside a forbid is fine and is ignored, so we skip this check.
return;
} else if self.lint_added_lints && level != Level::Forbid && old_level == Level::Forbid {
// Backwards compatibility check:
//
// We used to not consider `forbid(lint_group)`