Rust-clippy: False positive on similar_names?

[darnir]

The similar_names lint seems to be very strict with what it considers "similar". For example, I just had clippy give me this warning:

warning: binding's name is too similar to existing binding
  --> src/argparse.rs:53:5
   |
53 |     pub cache_util: f32,
   |     ^^^^^^^^^^^^^^^^^^^
   |
note: lint level defined here
  --> src/main.rs:24:9
   |
24 | #![warn(similar_names)]
   |         ^^^^^^^^^^^^^
note: existing binding defined here
  --> src/argparse.rs:43:5
   |
43 |     pub input: InputType,
   |     ^^^^^^^^^^^^^^^^^^^^

Sure, both of these fields are part of the same struct, but I don't see how input and cache_util are similar or confusing looking variable names.

[phansch]

@darnir That does look like a false positive, indeed.
Could you provide the original source of the struct or if that's not possible, a playground link that shows the issue? I can't seem to reproduce it unfortunately.

[oli-obk]

I think this might be the issue with spans not having expansion info since the last update. So this is actually occurring inside a derive

[darnir]

@phansch: Here's the entire struct:

#[derive(Debug)]
pub struct RtaArgs {
    pub input: InputType,
    pub hwdesc: HardwareDescription,
    pub ntasks: u16,
    pub nsets: u16,
    pub save_tasksets: bool,
    pub utilization_begin: f32,
    pub utilization_step: f32,
    pub utilization_end: f32,
    pub min_period: u32,
    pub max_period: u32,
    pub cache_util: f32,
    pub reuse_factor: f32,
}

[phansch]

@darnir thanks!

@oli-obk I guess you're correct: https://play.rust-lang.org/?gist=77d160aa9b7de5f0e132f4c65aa316d9&version=nightly

It only triggers when the #[derive(Debug)] is there.

[phansch]

Looks like this is caused by https://github.com/rust-lang/rust/pull/49154, which broke the macro check in some cases.

[darnir]

Given how this is still a broken lint, how about adding it to the list of known problems ~and maybe disabling while it is fixed~?

EDIT: Just realized, I've been explicitly enabling it.
But, adding this to the list of known problems still stands

[oli-obk]

The lint isn't broken, rustc is. If we disable this lint we could just as well disable all clippy lints, because all of them have this issue in some form or another ;)

I'll try to find the root cause in rustc today.

[gnzlbg]

I am having this issue with structopt derives :/ I was confused at first but in hindsight it makes sense.

[flip1995]

Will probably be fixed with the next nightly.