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

error: types that do not implement `Drop` can still have drop glue, consider instead using `std::mem::needs_drop` to detect whether a type is trivially dropped
  --> $DIR/dyn-drop.rs:2:19
   |
LL | fn foo(_: Box<dyn Drop>) {}
   |                   ^^^^
   |
note: the lint level is defined here
  --> $DIR/dyn-drop.rs:1:9
   |
LL | #![deny(dyn_drop)]
   |         ^^^^^^^^

error: types that do not implement `Drop` can still have drop glue, consider instead using `std::mem::needs_drop` to detect whether a type is trivially dropped
  --> $DIR/dyn-drop.rs:3:16
   |
LL | fn bar(_: &dyn Drop) {}
   |                ^^^^

error: types that do not implement `Drop` can still have drop glue, consider instead using `std::mem::needs_drop` to detect whether a type is trivially dropped
  --> $DIR/dyn-drop.rs:4:20
   |
LL | fn baz(_: *mut dyn Drop) {}
   |                    ^^^^

error: types that do not implement `Drop` can still have drop glue, consider instead using `std::mem::needs_drop` to detect whether a type is trivially dropped
  --> $DIR/dyn-drop.rs:6:15
   |
LL |   _x: Box<dyn Drop>
   |               ^^^^

error: types that do not implement `Drop` can still have drop glue, consider instead using `std::mem::needs_drop` to detect whether a type is trivially dropped
  --> $DIR/dyn-drop.rs:13:16
   |
LL |   type T = dyn Drop;
   |                ^^^^

error: aborting due to 5 previous errors
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			error: types that do not implement `Drop` can still have drop glue, consider instead using `std::mem::needs_drop` to detect whether a type is trivially dropped
Add missing `dyn` keywords to tests that do not test for them This ensures that these tests can be run on editions other than 2015 2025-06-02 10:11:10 +02:00			`--> $DIR/dyn-drop.rs:2:19`
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			`\|`
			`LL \| fn foo(_: Box<dyn Drop>) {}`
			`\| ^^^^`
			`\|`
			`note: the lint level is defined here`
			`--> $DIR/dyn-drop.rs:1:9`
			`\|`
			`LL \| #![deny(dyn_drop)]`
			`\| ^^^^^^^^`

			error: types that do not implement `Drop` can still have drop glue, consider instead using `std::mem::needs_drop` to detect whether a type is trivially dropped
Add missing `dyn` keywords to tests that do not test for them This ensures that these tests can be run on editions other than 2015 2025-06-02 10:11:10 +02:00			`--> $DIR/dyn-drop.rs:3:16`
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			`\|`
			`LL \| fn bar(_: &dyn Drop) {}`
			`\| ^^^^`

			error: types that do not implement `Drop` can still have drop glue, consider instead using `std::mem::needs_drop` to detect whether a type is trivially dropped
Add missing `dyn` keywords to tests that do not test for them This ensures that these tests can be run on editions other than 2015 2025-06-02 10:11:10 +02:00			`--> $DIR/dyn-drop.rs:4:20`
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			`\|`
Add missing `dyn` keywords to tests that do not test for them This ensures that these tests can be run on editions other than 2015 2025-06-02 10:11:10 +02:00			`LL \| fn baz(_: *mut dyn Drop) {}`
			`\| ^^^^`
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
			error: types that do not implement `Drop` can still have drop glue, consider instead using `std::mem::needs_drop` to detect whether a type is trivially dropped
Add missing `dyn` keywords to tests that do not test for them This ensures that these tests can be run on editions other than 2015 2025-06-02 10:11:10 +02:00			`--> $DIR/dyn-drop.rs:6:15`
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			`\|`
			`LL \| _x: Box<dyn Drop>`
			`\| ^^^^`

			error: types that do not implement `Drop` can still have drop glue, consider instead using `std::mem::needs_drop` to detect whether a type is trivially dropped
Add missing `dyn` keywords to tests that do not test for them This ensures that these tests can be run on editions other than 2015 2025-06-02 10:11:10 +02:00			`--> $DIR/dyn-drop.rs:13:16`
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			`\|`
			`LL \| type T = dyn Drop;`
			`\| ^^^^`

			`error: aborting due to 5 previous errors`