dropck rule may have ample room for improvement

[pnkfelix]

While writing the clarification PR #828, I realized there may be other ways to further narrow the Drop-Check rule in a sound manner. For example, if D has multiple type parameters where some are bounded and some are unbounded, it could be that the fact that the bounded type parameters could never actually gain access to the data of lifetime 'a.

More concretely:

trait Bound { fn act(&mut self); }
impl Bound for String { ... }
struct Two<A,B:Bound> { a: A, b: B }
impl<A,B:Bound> Drop for Two<A,B> { ... }
fn foo<'a>(t: Two<&'a u8, String>) { ... }

In the above example, I think one can argue that even though Two has a type parameter B with code that is effectively hidden from dropck, there is no way the impl Bound for String could access the &'a u8 that the A holds, and therefore we do not need to force 'a to strictly outlive t when dropck is analyzing fn foo.

This may actually matter in real code; I am imagining in particular the example of CheckedHashMap<K,V>, where a Eq+Hash bound on K need not restrict the choices that we select for V.

[pnkfelix]

(this is essentially covered by the Eyepatch RFC PR #1327 , I think...)

[Centril]

Closing since this is essentially covered by #1327.