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.

[estebank]

I tried an approach where I would look at the lifetime span to see if it came from a compiler desugaring, but the derived code doesn't keep any information about their context. A different approach will be needed in the parse step to make sure the debug subparser produced spans are appropriately marked. I won't have time to dig deeper, but wanted to share what I found.

[eddyb]

@estebank AFAIK there's a perma-unstable attribute that is placed on derived impls which some error reporting code might be checking.

@pnkfelix I should've given more context - it'd be good to fix this because it would unblock something like #61735, but likely removing a far larger number of lifetimes, which may simplify e.g. the 'gcx removal.
But if we can't really soon, we can defer indefinitely, I think.

[zackmdavis]

we ought to make a plan to finish up the Rust 2018 idiom lints

#54910?

[stouset]

@zackmdavis This seems to have regressed.

#[deny(single_use_lifetimes)]

#[derive(Eq)]
struct Foo<'a, T> {
    /// a reference to the underlying secret data that will be derefed
    pub data: &'a mut T,
}

produces the following warning

   Compiling playground v0.0.1 (/playground)
error: lifetime parameter `'a` only used once
 --> src/lib.rs:4:12
  |
3 | #[derive(Eq)]
  |          -- ...is used only here
4 | struct Foo<'a, T> {
  |            ^^ this lifetime...
  |
note: lint level defined here
 --> src/lib.rs:1:8
  |
1 | #[deny(single_use_lifetimes)]