Open kamulos opened 2 hours ago
warnings
is a special pseudo lint group, possibly lint expectations behave strangely against that.
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
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. 🤔
Code
Current output
rustc
is happy with an expect annotation on code, that does not trigger a warningDesired 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 otherexpect
annotations.Other cases
No response
Rust Version
Anything else?
No response