`single_use_lifetimes` warns when deriving a struct

[TimDiekmann]

When compiling

#![warn(single_use_lifetimes)]

#[derive(Debug)]
struct Foo<'a> {
    bar: &'a u32,
}

this warning is generated:

warning: lifetime parameter `'a` only used once
 --> src/lib.rs:5:12
  |
5 | struct Foo<'a> {
  |            ^^
  |

I think, #[automatically_derived] in the Debug derive does not consider this lint.

[eddyb]

I tried to deny(single_use_lifetimes) in the compiler but hit this bug, which makes it a non-starter.

I'd almost change built-in deriving to not declare the lifetimes explicitly but I suspect that wouldn't work when using #[derive] nested within a block where the shadowing from explicitness would be useful.
(That's assuming built-in deriving actually uses these lifetimes in bounds, otherwise it could just use '_)
cc @matthewjasper @rust-lang/compiler

[pnkfelix]

cc #44752

[pnkfelix]

I don't think this seems high priority. I'll leave it nominated but I'm prioritizing it as P-medium.

[oli-obk]

The problem is that the above code expands to something similar to

#![feature(in_band_lifetimes)]
#![warn(single_use_lifetimes)]

trait Foo {}

struct Bar<'a>(&'a i32);

impl Foo for Bar<'a> {}

which correctly warns for the 'a in the impl Foo. But since in the original code the impl is derived and reusesthe 'a from the struct declaration, the lint appears to trigger on the struct declaration.

We may either just want to not trigger in derive expansions or explicitly allow this lint in derives expansions.

[pnkfelix]

advertised at T-compiler meeting. removing nomination tag.

[nikomatsakis]

I'm going to ping @zackmdavis in the hopes that they have a bit of time to look into this. My sense is that we ought to make a plan to finish up the Rust 2018 idiom lints -- but at the same time it's hard to justify a P-high label just now.