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

[Noratrieb]

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

[rustbot]

r? @TaKO8Ki

rustbot has assigned @TaKO8Ki.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Noratrieb]

better lint name ideas welcome

[workingjubilee]

My understanding is that this allows this pattern:

#![forbid(lint)]

#[deny(lint)]
fn something() {
    // code
}

Can this come with a test for this case?

#![forbid(lint)]

#[deny(lint)]
fn something() {
    #[allow(lint)]
    {
        // linted code
    }
}

Apologies if this test already exists and I just didn't notice it.

[TaKO8Ki]

@rustbot author

[scottmcm]

When do people really want forbid? The only thing that comes to mind for me is forbid(unsafe_code), where I could consider it a plus that a macro can't allow(unsafe_code) to use it anyway.

If people hit this, maybe the resolution instead would be to say "well use deny then"?

[joshtriplett]

It seems completely fine to #[deny] inside a #[forbid], and I don't think we need a warning for that. (The lint should remain in the forbidden state, and should still not subsequently be allow-able.)

The thing that shouldn't be allowed is using #[warn] or #[allow] inside #[forbid]; that's the exact thing that #[forbid] forbids, so if you want to allow that, don't use #[forbid].

[joshtriplett]

@workingjubilee Agreed that we should have a test for allow-inside-deny-inside-forbid, as well as a test for warn-inside-deny-inside-forbid, both of which should be an error. (The test should check the case where that happens via a macro, as well.)

[traviscross]

We discussed this at the end of the lang triage call today and did not reach a resolution before running out of time.

We'll leave this nominated so as to discuss in the meeting on a future week.

[joshtriplett]

We discussed this again in today's @rust-lang/lang meeting. Concrete proposal to get consensus on:

• Allow deny within forbid, silently without any warning, but keep the state forbid. Rationale: forbid is just "deny and don't allow that to be changed".

• Continue to hard-error on warn or allow within forbid. Re-evaluate after fixing deny.

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @tmandry

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[joshtriplett]

@Nilstrieb Could you please remove the warning, and silently allow deny within forbid (but ensure that the state remains forbid so that allow-inside-deny-inside-forbid is still a hard error)?

[traviscross]

@rustbot labels -I-lang-nominated

As mentioned above, this was discussed today and the mood in the meeting was positive on doing what Josh proposed. Since it was discussed and there's now a propose FCP here, let's unnominate.

[workingjubilee]

Thanks! This will help me significantly for situations where a forbid(lint) holding is critical... yes, usually forbid(unsafe_code)... while permitting macro code to generate its own deny(lint)s so that it retains internal consistency in its expansion, so that if a macro is used in both a forbid(lint) context and outside of that context, it doesn't have to rethink how it expands certain pieces of code.

[bors]

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

[tmandry]

@rfcbot reviewed

Note that the PR still needs to be updated to reflect the lang team consensus (no warning on deny-in-forbid, but it's a no-op).

Personally I'm in favor of going farther and allowing #[warn] and even #[allow] as no-ops with a warning (and that warning would be suppressed inside macro expansions). But let's get this merged first.

[jieyouxu]

Thanks, this LGTM with some additional test coverage. Though may need to fix the lint docs failure, not sure what's up with that, I haven't looked closely at it.

[Noratrieb]

the lint-docs failure was because the lint docs were relying on deny inside forbid being wrong, i changed that one to warn.
i also opened a pr to the reference: rust-lang/reference#1655

[Noratrieb]

oh @rustbot ready

[jieyouxu]

Thanks!

[jieyouxu]

@bors r+

[bors]

📌 Commit 1af9d11 has been approved by jieyouxu

It is now in the queue for this repository.