-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Tracking Issue for const_box
#92521
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
The non-ZST allocator issue has been resolved and should be removed from the unresolved questions list. |
Thanks for the information. I've removed it. |
I'm sorry for my shallow understanding, but can't |
Aparently it is possible on stable to Deref Was this intentional? |
Currently it cannot. Rust's specialization doesn't yet support const-impl enough, so some rust/library/alloc/src/alloc.rs Lines 424 to 443 in 8c0f83d
This behavior is not caused by this feature. It can be reproduced in pre-1.58.0. It may be due to the compiler's special |
This feature has been mostly removed by #110393, and anyway |
That makes sense for me -- @rust-lang/wg-const-eval what do you think? |
It seems struct Zst;
const CONST_ZST: Box<Zst> = unsafe { std::mem::transmute(std::ptr::dangling::<Zst>()) };
fn main() {
let free_box = CONST_ZST;
dbg!(&raw const *free_box);
} |
Constructing |
So do you mean it has different requirement of validity (not sure if it's the correct word) for const and non-const context? I'm expecting const context can only be more strict and checked than runtime context, so if a code is guaranteed to be valid at runtime and it compiles at const context, it should be as valid/correct as runtime (excluding the result difference involving floating point calculations). Am I wrong on this? It's currently explicitly mentioned
|
That's definitely not correct; ptr-to-int transmutes (with their current de-facto but not-yet-stable semantics) are an example of that. |
ptr-to-int transmutes are rejected now in const-eval so it fails |
I don't know what you mean. They do not get rejected. Here's an example: const C: () = {
let x = &5;
let y: usize = unsafe { std::mem::transmute(x) };
}; |
remove remnants of const_box feature This feature requires major design work, and the few methods it gates currently aren't actually useful. Let's reset to a clean slate so when a design materializes, we can start from scratch. Closes rust-lang#92521 by removing the feature it tracks. r? `@oli-obk`
remove remnants of const_box feature This feature requires major design work, and the few methods it gates currently aren't actually useful. Let's reset to a clean slate so when a design materializes, we can start from scratch. Closes rust-lang#92521 by removing the feature it tracks. r? ``@oli-obk``
remove remnants of const_box feature This feature requires major design work, and the few methods it gates currently aren't actually useful. Let's reset to a clean slate so when a design materializes, we can start from scratch. Closes rust-lang#92521 by removing the feature it tracks. r? ```@oli-obk```
🤦 Okay seems I have some misunderstanding about const-eval and it's not rejected until "used" in some sense. Back to the original topic, you suggest that |
My first reaction was that this transmute is not specified to do anything in particular in any context, like all transmutes.
If we do indeed guarantee this at runtime (which is a t-libs-api question that I am not so sure about) then arguably it should also work at compiletime.
|
Rollup merge of rust-lang#138800 - RalfJung:const_box, r=oli-obk remove remnants of const_box feature This feature requires major design work, and the few methods it gates currently aren't actually useful. Let's reset to a clean slate so when a design materializes, we can start from scratch. Closes rust-lang#92521 by removing the feature it tracks. r? ````@oli-obk````
remove remnants of const_box feature This feature requires major design work, and the few methods it gates currently aren't actually useful. Let's reset to a clean slate so when a design materializes, we can start from scratch. Closes rust-lang#92521 by removing the feature it tracks. r? ````@oli-obk````
Uh oh!
There was an error while loading. Please reload this page.
Feature gate:
#![feature(const_box)]
This is a tracking issue for implementing const
Box<T, A>
methods.Public API
Steps / History
Box<T, A>
methods #91884Unresolved Questions
The text was updated successfully, but these errors were encountered: