rust/tests/ui/dyn-drop/dyn-drop.rs

#![deny(dyn_drop)]
#![allow(bare_trait_objects)]
fn foo(_: Box<dyn Drop>) {} //~ ERROR
fn bar(_: &dyn Drop) {} //~ERROR
fn baz(_: *mut Drop) {} //~ ERROR
struct Foo {
  _x: Box<dyn Drop> //~ ERROR
}
trait Bar {
  type T: ?Sized;
}
struct Baz {}
impl Bar for Baz {
  type T = dyn Drop; //~ ERROR
}
fn main() {}
feat(rustc_lint): add `dyn_drop` Based on the conversation in #86747. Explanation ----------- A trait object bound of the form `dyn Drop` is most likely misleading and not what the programmer intended. `Drop` bounds do not actually indicate whether a type can be trivially dropped or not, because a composite type containing `Drop` types does not necessarily implement `Drop` itself. Naïvely, one might be tempted to write a deferred drop system, to pull cleaning up memory out of a latency-sensitive code path, using `dyn Drop` trait objects. However, this breaks down e.g. when `T` is `String`, which does not implement `Drop`, but should probably be accepted. To write a trait object bound that accepts anything, use a placeholder trait with a blanket implementation. ```rust trait Placeholder {} impl<T> Placeholder for T {} fn foo(_x: Box<dyn Placeholder>) {} ``` 2021-07-03 11:20:01 -07:00			`#![deny(dyn_drop)]`
			`#![allow(bare_trait_objects)]`
			`fn foo(_: Box<dyn Drop>) {} //~ ERROR`
			`fn bar(_: &dyn Drop) {} //~ERROR`
			`fn baz(_: *mut Drop) {} //~ ERROR`
			`struct Foo {`
			`_x: Box<dyn Drop> //~ ERROR`
			`}`
			`trait Bar {`
			`type T: ?Sized;`
			`}`
			`struct Baz {}`
			`impl Bar for Baz {`
			`type T = dyn Drop; //~ ERROR`
			`}`
			`fn main() {}`