Rollup merge of #121560 - Noratrieb:stop-lint-macro-nonsense, r=jieyouxu

Allow `#[deny]` inside `#[forbid]` as a no-op

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]` (or `#[warn]` for an allow-by-default lint) 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!

By making it a warning instead, we remove the problem with the macro, which is now nothing as warnings are suppressed in macro expanded code, while still telling users that something is up.

fixes #121483
This commit is contained in:
Matthias Krüger 2024-10-20 16:54:08 +02:00 committed by GitHub
commit 7b714d4735
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
18 changed files with 260 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)`