feat(rustc_lint): add dyn_drop#86848
Conversation
|
r? @varkor (rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
|
@rustbot label: +A-lint |
|
The actual implementation looks fine to me, but since adding new lints is a decision for the lang team, I'll defer to r? @scottmcm. |
|
Given that we have the @bors r=varkor since we can always tweak or remove it later. cc @rust-lang/lang just in case someone else has strong feelings |
|
📌 Commit 20e1791b9e54dff4fb96c9155a86bf7ca44105b4 has been approved by |
|
⌛ Testing commit 20e1791b9e54dff4fb96c9155a86bf7ca44105b4 with merge 83e6f6d4ab726c5aa02bc0620946451c9807c8cd... |
This comment has been minimized.
This comment has been minimized.
|
💔 Test failed - checks-actions |
Based on the conversation in rust-lang#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>) {} ```
These are all testing corner-cases in the compiler. Adding a new warning broke these test cases, but --cap-lints stops it from actually breaking things in production.
20e1791 to
e054522
Compare
|
@bors r=varkor |
|
📌 Commit e054522 has been approved by |
|
☀️ Test successful - checks-actions |
Based on the conversation in #86747.
Explanation
A trait object bound of the form
dyn Dropis most likely misleading and not what the programmer intended.Dropbounds do not actually indicate whether a type can be trivially dropped or not, because a composite type containingDroptypes does not necessarily implementDropitself. Naïvely, one might be tempted to write a deferred drop system, to pull cleaning up memory out of a latency-sensitive code path, usingdyn Droptrait objects. However, this breaks down e.g. whenTisString, which does not implementDrop, but should probably be accepted.To write a trait object bound that accepts anything, use a placeholder trait with a blanket implementation.