Don't warn on proc macro generated code in needless_return
#13464
Conversation
|
r? @Alexendoo rustbot has assigned @Alexendoo. Use |
rustbot
added
the
S-waiting-on-review
| @@ -1,5 +1,5 @@ | |||
| #![warn(clippy::dbg_macro)] | |||
| #![allow(clippy::unnecessary_operation, clippy::no_effect)] | |||
| #![allow(clippy::unnecessary_operation, clippy::no_effect, clippy::unit_arg)] | |||
There was a problem hiding this comment.
It now emits a warning on this line
which looks like a true positive to me
|
Hmm, lintcheck reports a lot of new warnings. Still going through them, but most of them look like they originate in local macros, so that seems about expected. |
| @@ -407,7 +407,7 @@ fn check_final_expr<'tcx>( | |||
| } | |||
| } | |||
|
|
|||
| if ret_span.from_expansion() { | |||
| if ret_span.from_expansion() || is_from_proc_macro(cx, expr) { | |||
There was a problem hiding this comment.
Note: if this is the Span::from_expansion that is the rustc one, then AFAIK in general it is the most robust check for spans from macro expansions that is possible, and I would not have expected is_from_proc_macro detection to not be already covered by from_expansion if the proc macro implements span hygiene correctly.
I suspect that some crates have proc-macros which generate spans that have call-site hygiene instead of mixed-site hygiene, causing from_expansion to return false.
But I suppose it's possible that clippy wants different trade-offs here and try to provide warnings even if the proc-macros do not emit spans with proper hygiene?
See: similar issue I ran into in implementing unit_bindings lint in rustc rust-lang/rust#112380 (comment).
Also see a Rocket PR where I used Span::mixed_site().located_at(span) so the proc-macro produces a Span which will correctly return true for Span::from_expansion because it has distinguishing SyntaxContext.
There was a problem hiding this comment.
Yeah, the issue that is_from_proc_macro solves is crates using quote_spanned! with an input span like tokio does in the linked issues which makes it (to my knowledge) completely impossible to detect whether a span is from a proc macro, so this is a big hack that approximates it even further by checking if the code pointed at the span lines up with the AST.
@Alexendoo wrote a good comment about the proc macro situation in a zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/report_in_external_macro.20no.20longer.20configurable.3F/near/448135182
To be clear, I'd also love to get rid of this, but afaik we're kind of stuck with this hack for now and add such checks whenever needed because proc macro tooling like quote::quote_spanned! makes it incredibly easy to fool clippy and we get a lot of bug reports for it because a lot of proc macros do this
There was a problem hiding this comment.
Right, that's entirely reasonable for clippy. I opened a zulip topic for T-compiler (and T-lang) to discuss the proc-macro span hygiene syntax context situation and if we can somehow make more people aware of the proc-macro span hygiene syntax context issues (because rustc lints/diagnostics also gets bitten by this quite often): https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/proc-macro.20span.20hygiene.
It's really not ideal when many, many crate authors get proc-macro hygiene syntax context wrong because there's not much awareness or guidance for it. This in turn causes diagnostic and lint issues in rustc and clippy.
EDIT: and an issue rust-lang/rust#130995
EDIT 2: hygiene -> syntax context, I am one of the people confused myself
clippy_utils/src/check_proc_macro.rs
Outdated
| // e.g. `return format!(..)` would be considered to be from a proc macro | ||
| // if we build up a pattern for the macro expansion and compare it to the invocation `format!()`. | ||
| // So instead we return an empty pattern such that `span_matches_pat` always returns true. | ||
| if e.span.ctxt() != outer_ctxt { |
There was a problem hiding this comment.
Could we pass the span in here to use eq_ctxt?
Fixes #13458
Fixes #13457
Fixes #13467
Fixes #13479
Fixes #13481
The fix is unfortunately a little more convoluted than just simply adding a
is_from_proc_macro. That check does fix the issue, however it also introduces a bunch of false negatives in the tests, specifically when the returned expression is in a different syntax context, e.g.return format!(..).The proc macro check builds up a start and end pattern based on the HIR nodes and compares it to a snippet of the span, however that would currently fail for
return format!(..)because we would have the patterns("return", <something inside of the format macro>), which doesn't compare equal. So we now return an empty string pattern for when it's in a different syntax context."Hide whitespace" helps a bit for reviewing the proc macro detection change
changelog: none