Rust-clippy: lints triggering inside derives like #[derive(Deserialize)]

[CraZySacX]

Started getting this with 0.0.142 (built from master) linting a project that has serde and serde_derive as dependencies:

error: you seem to be trying to use match for destructuring a single pattern. Consider using `if let`                                                         
  --> src/tmpl.rs:43:35                
   |                                   
43 | #[derive(Clone, Debug, Serialize, Deserialize)]                           
   |                                   ^^^^^^^^^^^ help: try this `if let Deserialize = Deserialize Deserialize else Deserialize`                             
   |                                   
   = help: for further information visit https://github.com/Manishearth/rust-clippy/wiki#single_match_else

Using the following nightly:

rustc 1.20.0-nightly (696412de7 2017-07-06)
binary: rustc
commit-hash: 696412de7e4e119f8536686c643621115b90c775
commit-date: 2017-07-06
host: x86_64-unknown-linux-gnu
release: 1.20.0-nightly
LLVM version: 4.0

[oli-obk]

I thought we fixed that... needs a macro check

[dtolnay]

if let Deserialize = Deserialize Deserialize else Deserialize

High-quality suggestion. :paperclip: :100:

Something must have changed about spans and the derived code is no longer exempt from lints. https://github.com/serde-rs/serde/issues/983

[dtolnay]

Based on serde-json Travis builds, this worked in rustc 1.20.0-nightly (3610a70ce 2017-07-05) and has been failing since rustc 1.20.0-nightly (696412de7 2017-07-06).

[oli-obk]

Thanks for the bisect. I'll investigate

[oli-obk]

We need to get the lint story straight in rustc. So many things don't have expansion info: ?-Operator, for loop expansion, procedural and derive macros, ... I have not yet read up on save-analysis (what is it, what does it do, and why is expansion info such a bad thing for it?). We should add a new expansion info kind that just tells you "hey this isn't written by the user, but treat it as such as long as you aren't a lint". Then we make sure a rust builtin lint triggers on an expanded code (but is not linted). So basically a canary test. This is pretty easy to do with procedural macros.

Anyway. Dogfood is broken, users are getting gazillions of bogus messages on derives. We need to get a fix through quickly.

[oli-obk]

This has been fixed in 0.0.144