-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
1.59 accidentally stabilized dropping Box<T>s in const fns #94804
Copy link
Copy link
Closed
Labels
P-highHigh priorityHigh priorityT-libsRelevant to the library team, which will review and decide on the PR/issue.Relevant to the library team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.Performance or correctness regression from one stable version to another.
Metadata
Metadata
Assignees
Labels
P-highHigh priorityHigh priorityT-libsRelevant to the library team, which will review and decide on the PR/issue.Relevant to the library team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.Performance or correctness regression from one stable version to another.
Type
Fields
Give feedbackNo fields configured for issues without a type.
(playground)
Note that this works even if
TimplementsDropin a non-constway. This seems hightly problematic, especially provided we eventually want to support constructingBoxat compile time.Relevant PR: #91884
Of course that impl claims to be unstable, but as we all know trait implementations are never unstable, unless the trait is unstable. (For ordinary traits, implementations of
const Traitare thus unstable merely due to the fact that no user can use any such implementations in stable code yet.)@rustbot label regression-from-stable-to-stable
I don’t know what team to tag.The fix should be straightforward: Remove the
const Drop for Box<T, A>implementation (i.e. revert it to be non-const), and add a test.