move expect from `allow_attributes_without_reason` to it's own lint

[ratmice]

What it does

Currently allow_attributes works only on allow, but doesn't trigger on expect.
The allow_attributes_without_reason works differently, it applies to both allow and expect.

It would be nice if these could be set separately, so that allow_attributes_without_reason only applied to
#[allow()] and expect_attributes_without_reason could apply the same logic to expect.

Advantage

The allow_attributes lint is too much for many cases, such as when you conditionally need an allow in a #[cfg()] where #[expect(...)] is too strong.

We would like to be able to use:

#[allow(...) reason = "...."]
#[expect(something_else)]

but erroring on

#[allow(some_other_thing)]

Moving expect_attributes_without_reason to it's own lint would allow this kind of flexibility.

Drawbacks

People relying on the current behavior of allow_attributes_without_reason need to enable another lint to keep that behavior.

Example

<code>

Could be written as:

<code>

Comparison with existing lints

No response

Additional Context

No response

[ratmice]

This was also mentioned in #13623 (comment)

[mpiton]

I took a look at this. From what I can tell, this isn't a parsing issue: both allow and expect are explicitly handled by allow_attributes_without_reason, and the current UI test covers #[expect(dead_code)].

Splitting them looks fairly small technically, but I'm not sure about the compatibility side. If allow_attributes_without_reason stops checking expect, users relying on the current behavior would need to enable the new expect_attributes_without_reason lint as well.

Would a direct split with a changelog note be acceptable here, or would a different migration path be preferred? I'm new to contributing to Clippy, so I wanted to check the expected direction before putting together a PR.

[ratmice]

Yeah, I'm not sure what the lint compatibility is either. I suspect it wouldn't be a bad idea
to try and come up with a new name for allow_attributes_without_reason, deprecating the old name. Perhaps one which is less allow specific like bypass_lint_without_reason which doesn't refer to allow or expect. Then perhaps coming up with a new one
that specifies allow/expect explicitly.

I don't really have good suggestions for naming, but it feels like doing a deprecation wouldn't be unwarranted.

[mpiton]

That makes sense. lint_suppressions_without_reason might be another option for the combined lint, since both #[allow] and #[expect] suppress a lint diagnostic.

One thing I'm not clear on is how the old name should map during the transition. If allow_attributes_without_reason becomes a deprecated alias for the combined lint, it couldn't also become the allow-only lint. Would the intended end state be a generic combined lint plus two new explicit lints for allow and expect, with the old name deprecated? Or would the combined lint be replaced entirely by the two specific ones?

I may be misunderstanding how Clippy normally handles lint splits, so I'm mainly trying to understand the intended shape before looking further into names.

[ratmice]

FWIW, I'm pretty much entirely unfamiliar with clippy norms, so don't take my thoughts as gospel or anything... it just felt like the path of least resistance.

But yes, sorry for not being clear, I was imagining both new name for the old combined lint, and new names for the expect/allow individual lints. The main point of the combined lint is to be something we can suggest to people who currently enable the lint which retains the exact same behavior in the deprecation message.

The only ideas I had for new names was allow_attributes_require_reason and expect_attributes_require_reason. This kind of flips the tense from without to require, but I couldn't think of anything better.