Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1.59 accidentally stabilized dropping Box<T>s in const fns #94804

Closed
steffahn opened this issue Mar 10, 2022 · 3 comments · Fixed by #94805
Closed

1.59 accidentally stabilized dropping Box<T>s in const fns #94804

steffahn opened this issue Mar 10, 2022 · 3 comments · Fixed by #94805
Assignees
Labels
P-high High priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@steffahn
Copy link
Member

steffahn commented Mar 10, 2022

const fn f<T>(_: Box<T>) {}

(playground)

Note that this works even if T implements Drop in a non-const way. This seems hightly problematic, especially provided we eventually want to support constructing Box at 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 Trait are 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.

@rustbot rustbot added regression-from-stable-to-stable Performance or correctness regression from one stable version to another. I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Mar 10, 2022
@apiraino apiraino added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label Mar 10, 2022
@oli-obk
Copy link
Contributor

oli-obk commented Mar 10, 2022

cc @rust-lang/wg-const-eval

@oli-obk oli-obk added P-high High priority and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Mar 10, 2022
@lcnr
Copy link
Contributor

lcnr commented Mar 10, 2022

#[rustc_const_unstable(feature = "const_box", issue = "92521")]
unsafe impl<#[may_dangle] T: ?Sized, A: Allocator> const Drop for Box<T, A> {
    fn drop(&mut self) {
        // FIXME: Do nothing, drop is currently performed by compiler.
    }
}

that impl should be illegal, shouldn't it? I would expect us to need an explicit T: ~const Drop here. But also, reverting and maybe even backporting that impl for now seems like the right choice to me

@oli-obk oli-obk self-assigned this Mar 10, 2022
@RalfJung
Copy link
Member

RalfJung commented Mar 10, 2022

Good catch!

Actually calling this leads to odd behavior:

const fn f(_: Box<i32>) {}

pub const C: () = {
    unsafe { f(std::mem::transmute(&0)) };
};
error: any use of this value will cause an error
    |
   ::: src/lib.rs:3:1
    |
3   | / pub const C: () = {
4   | |     unsafe { f(std::mem::transmute(&0)) };
5   | | };
    | |__-
    |
    = note: `#[deny(const_err)]` on by default
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, [see issue #71800 <https://github.com/rust-lang/rust/issues/71800>](https://github.com/rust-lang/rust/issues/71800)

It doesn't even say what went wrong. I expected an error saying a non-const function was called as part of the Box drop glue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P-high High priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants