2019-07-26 21:54:25 +00:00
|
|
|
// run-pass
|
|
|
|
|
|
2018-09-17 09:18:35 +00:00
|
|
|
#![allow(unused_imports)]
|
|
|
|
|
#![allow(unused_must_use)]
|
2015-03-22 20:13:15 +00:00
|
|
|
// pretty-expanded FIXME #23616
|
|
|
|
|
|
2015-04-27 21:10:49 +00:00
|
|
|
#![feature(rustc_private)]
|
2014-10-02 19:52:06 +00:00
|
|
|
|
2020-06-02 19:46:42 +00:00
|
|
|
extern crate rustc_serialize;
|
2014-10-02 19:52:06 +00:00
|
|
|
|
2014-12-12 18:59:41 +00:00
|
|
|
use std::fmt;
|
2020-06-02 19:46:42 +00:00
|
|
|
use rustc_serialize::{Encoder, Encodable};
|
|
|
|
|
use rustc_serialize::json;
|
2014-10-02 19:52:06 +00:00
|
|
|
|
Reject specialized Drop impls.
See Issue 8142 for discussion.
This makes it illegal for a Drop impl to be more specialized than the
original item.
So for example, all of the following are now rejected (when they would
have been blindly accepted before):
```rust
struct S<A> { ... };
impl Drop for S<i8> { ... } // error: specialized to concrete type
struct T<'a> { ... };
impl Drop for T<'static> { ... } // error: specialized to concrete region
struct U<A> { ... };
impl<A:Clone> Drop for U<A> { ... } // error: added extra type requirement
struct V<'a,'b>;
impl<'a,'b:a> Drop for V<'a,'b> { ... } // error: added extra region requirement
```
Due to examples like the above, this is a [breaking-change].
(The fix is to either remove the specialization from the `Drop` impl,
or to transcribe the requirements into the struct/enum definition;
examples of both are shown in the PR's fixed to `libstd`.)
----
This is likely to be the last thing blocking the removal of the
`#[unsafe_destructor]` attribute.
Includes two new error codes for the new dropck check.
Update run-pass tests to accommodate new dropck pass.
Update tests and docs to reflect new destructor restriction.
----
Implementation notes:
We identify Drop impl specialization by not being as parametric as the
struct/enum definition via unification.
More specifically:
1. Attempt unification of a skolemized instance of the struct/enum
with an instance of the Drop impl's type expression where all of
the impl's generics (i.e. the free variables of the type
expression) have been replaced with unification variables.
2. If unification fails, then reject Drop impl as specialized.
3. If unification succeeds, check if any of the skolemized
variables "leaked" into the constraint set for the inference
context; if so, then reject Drop impl as specialized.
4. Otherwise, unification succeeded without leaking skolemized
variables: accept the Drop impl.
We identify whether a Drop impl is injecting new predicates by simply
looking whether the predicate, after an appropriate substitution,
appears on the struct/enum definition.
2015-03-21 12:12:08 +00:00
|
|
|
struct Foo<T: Encodable> {
|
2014-10-02 19:52:06 +00:00
|
|
|
v: T,
|
|
|
|
|
}
|
|
|
|
|
|
2015-01-04 06:24:50 +00:00
|
|
|
impl<T: Encodable> Drop for Foo<T> {
|
2014-10-02 19:52:06 +00:00
|
|
|
fn drop(&mut self) {
|
|
|
|
|
json::encode(&self.v);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fn main() {
|
2015-01-25 21:05:03 +00:00
|
|
|
let _ = Foo { v: 10 };
|
2014-10-02 19:52:06 +00:00
|
|
|
}
|