Change:
} } ast::StmtKind::Semi(ref expr) => { <del> self.space_if_not_bol(); self.print_expr_outer_attr_style(expr, false); self.s.word(";"); </del> <ins> match expr.kind { // Filter out empty `Tup` exprs created for the `redundant_semicolon` // lint, as they shouldn't be visible and interact poorly // with proc macros. ast::ExprKind::Tup(ref exprs) if exprs.is_empty() && expr.attrs.is_empty() => (), _ => { self.space_if_not_bol(); self.print_expr_outer_attr_style(expr, false); self.s.word(";"); } } </ins> } ast::StmtKind::Mac(ref mac) => { let (ref mac, style, ref attrs) = **mac;

Discussion:
Using nightly-2019-08-26. In we upgraded the compiler. Our tidbquery component tripped the redundantsemicolon lint (and seemingly in turn clippy::noeffect) but rustc/clippy did not tell us the line number. I couldn't find the code that triggered the lint and had to just allow both for the whole crate. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
It can be reproduced by cloning that PR, removing the commit that adds the s, and running .
Introduced in It has caused similar effects in other cases like CC
cc
Check-in from compiler team: Marking as P-high " as this is a regression, though admittedly one without particularly serious consequences (the lint can always be allowed). or perhaps one of you can take a stab at this? Please if you do start working on it (even if it's just to write mentoring instructions).
Also, it'd be great to get a minimized version of the problem. Therefore, marking as E-needs-mvce.
I'll work on this. Looking into it a bit, I think it has to do with the lint's interaction with custom proc macro attributes. Specifically, when the item passed to the attribute contains a redundant semicolon, every span in the is the dummy span. This occurs in both this issue and . It's definitely due to the changes to the parser, but I'm not sure why the changes would have that effect on the spans. claim
just in case you didn't see, the attempt to fix this with your PR failed the rollup, see

The new lint for excess semicolons () has some weird behaviour when the lint is triggered inside an async function that is transformed using a procedural macro. Rustc version: 1.39.0-nightly ( 2019-08-26) Compiling this: gives this output: note how the spans are all targeting the procedural macro instead of the correct line. If I remove the procedural macro or if I remove the excess semicolon, the spans are fine. This leads me to believe that it's an error in the lint, not in the macro, but maybe I'm wrong.
It is the macro's responsibility to preserve spans. What we can do is silence warnings coming from macro's, but we do that on a lint by lint basis at the moment.
Without the excess semicolon the spans for the other warnings are correct even with the macro, which led me to believe that the macro itself is not the problem. Does that mean that the macro somehow needs to support this new lint (or some family of lints)?
The fact that the other lints trigger only if the extra semicolon is there is quite weird indeed.
At my setup they trigger always (unless the compiler does not nothing and prints nothing out), however the combination + macro + excess semicolon messes up the spans. I looked at the macro and tried to use , that didn't help.