Should `#[expect(warnings)]` at some point warn that there are no warnings in the annotated code?

[kamulos]

Code

#[expect(warnings)]
pub fn foo() {}

Current output

rustc is happy with an expect annotation on code, that does not trigger a warning

Desired output

probably this should ask to remove the expect annotation?

Rationale and extra context

expect(warnings) is probably not the most idiomatic thing to do, but I found it in my code. And I would think that this behaves like other expect annotations.

Other cases

No response

Rust Version

rustc 1.83.0-nightly (f79a912d9 2024-09-18)
binary: rustc
commit-hash: f79a912d9edc3ad4db910c0e93672ed5c65133fa
commit-date: 2024-09-18
host: x86_64-unknown-linux-gnu
release: 1.83.0-nightly
LLVM version: 19.1.0

Anything else?

No response

[jieyouxu]

warnings is a special pseudo lint group, possibly lint expectations behave strangely against that.

[Noratrieb]

expect(warnings) is a paradox that cannot make sense. if there are no warnings, it will cause a warning, which is a warning, so now there are warnings, which means it shouldn't trigger.
i think the best thing would be to make it an error, but since it's shipped already, we may need to make it a no-op+"don't do this" warning.
@xFrednet

[xFrednet]

Currently, it's defined that the unfulfilled_lint_expectations lint can't be expected. So there could be some logic where #[expect(warnings)] could work.

However, the unfulfilled_lint_expectations is emitted at the node that the #[expect] is attached to. My guess is that there is a weird combination with it being a pseudo lint group and the paradox that @Noratrieb mentioned. Even if the lint is emitted, the #[expect()] should suppress it again. 🤔