Unnecessary "Parameter Foo is never used" error when Foo is used in generic bounds

[Osspial]

When creating structs that use generics parameters for use in generic bounds, the compiler throws an error that such parameters aren't being used when they are actually being used in the bound. For example, take the following struct/trait pair:

struct Foo<B, A: ExampleTrait<B>> {
    a: A
}

trait ExampleTrait<B> {}

This code has no reason not to compile, but it still fails with the following error:

error: parameter `B` is never used [--explain E0392]
 --> <anon>:1:12
1 |> struct Foo<B, A: ExampleTrait<B>> {
  |>            ^
help: consider removing `B` or using a marker such as `std::marker::PhantomData`

error: aborting due to previous error

Similarly, if a lifetime is used in the trait, the same error occurs:

struct Foo<'a, A: ExampleTrait<'a>> {
    a: A
}

trait ExampleTrait<'a> {}

error: parameter `'a` is never used [--explain E0392]
 --> <anon>:1:12
1 |> struct Foo<'a, A: ExampleTrait<'a>> {
  |>            ^^
help: consider removing `'a` or using a marker such as `std::marker::PhantomData`

error: aborting due to previous error

Now, using PhantomData does indeed work for these cases and correctly suppresses the error. However, the error should not occur here in the first place, as the relevant parameters are being used in the struct, albeit not directly. Instead, the compiler should just accept the PhantomData-less code as valid.

Meta

rustc 1.10.0 (cfcb716cf 2016-07-03)
binary: rustc
commit-hash: cfcb716cf0961a7e3a4eceac828d94805cf8140b
commit-date: 2016-07-03
host: x86_64-unknown-linux-gnu
release: 1.10.0

[eefriedman]

See https://github.com/rust-lang/rfcs/blob/4b4fd5146c04c9c284094aad8f54ca5c2093c7f2/text/0738-variance.md .

[Mark-Simulacrum]

@eddyb I seem to recall another issue about something similar to this that you commented on (maybe #25041?); I think this isn't an issue--that is, B isn't really being used by anything in the struct definition (trait ExampleTrait<B> doesn't use B since nothing in the trait can access that information--I guess?) but I'm uncertain.

[eddyb]

Yeah just remove the bound is what I'd say.

[Mark-Simulacrum]

In that case I think we can just close this, since I don't know of anything actionable that can be done here. Let me know if I misunderstood.