impl Drop must not allow adding new bounds on type params

[pnkfelix]

Spawned off of #21022, #21972.

Before killing unsafe_destructor, we need to address the issue that type-parametric implementations of Drop cannot add new bounds ("new" as in bounds that were not already present on the type definition itself).

Here is an example:

use std::fmt;

pub struct S<T> { t: T }

impl<T: fmt::Show> Drop for S<T> {
    fn drop(&mut self) {
        println!("dropping S {{ t: {:?} }}", self.t);
    }
}

struct NoShow;

fn main() {
    let s1 = S { t: 1u8 };
    let s2 = S { t: 2u16 };
    let s3  =S { t: NoShow };
}

(On master, the above errors because it requires unsafe_destructor).

In the version of the compiler implemented on PR #21022, you get the following ICE:

% ./x86_64-apple-darwin/stage2/bin/rustc /tmp/dtor_ex2.rs
/tmp/dtor_ex2.rs:14:9: 14:11 warning: unused variable: `s1`, #[warn(unused_variables)] on by default
/tmp/dtor_ex2.rs:14     let s1 = S { t: 1u8 };
                            ^~
/tmp/dtor_ex2.rs:15:9: 15:11 warning: unused variable: `s2`, #[warn(unused_variables)] on by default
/tmp/dtor_ex2.rs:15     let s2 = S { t: 2u16 };
                            ^~
/tmp/dtor_ex2.rs:16:9: 16:11 warning: unused variable: `s3`, #[warn(unused_variables)] on by default
/tmp/dtor_ex2.rs:16     let s3  =S { t: NoShow };
                            ^~
/tmp/dtor_ex2.rs:1:1: 1:1 error: internal compiler error: Encountered error `Unimplemented` selecting `Binder(TraitRef(NoShow, core::fmt::Show))` during trans
/tmp/dtor_ex2.rs:1 use std::fmt;
                   ^
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'Box<Any>', /Users/fklock/Dev/Mozilla/rust-drop-lts/src/libsyntax/diagnostic.rs:123

[reem]

Is this a fundamental limitation or just requires implementation effort to detect which (if any) drop impl to run?

[nikomatsakis]

@reem not a fundamental limitation necessarily.

[pnkfelix]

closing as dupe of #8142