Tracking issue for const_size_of_val and const_align_of_val

This is a tracking issue for constness of the following stable API:

// core::mem

pub const fn size_of_val<T: ?Sized>(val: &T) -> usize;
pub const fn align_of_val<T: ?Sized>(val: &T) -> usize;

It would be useful for macros to be able to do things like:

static KEY: [u8; size_of_val($byte_string)] = $byte_string;

I believe the rust-objc devs would like something like this to properly set up statics containing messageSend selectors (which are magically processed by the objc runtime by putting them in the right linker sections).

I believe this is currently blocked on miri becoming the primary/only CTFE provider.

@eddyb

cc @eddyb @oli-obk

I think this is possible without miri const eval, but it would be wasteful to implement in old ctfe

Yeah I consider "the people who would implement/review this are able but unwilling" to be a blocker

I believe this is currently blocked on miri becoming the primary/only CTFE provider.

Where can that status be followed? If such a transition were quite a while out, would it be possible to support with only miri and/or feature flag of some kind?

Miri is here. So it's mostly a matter of opening a PR by copying over the code from https://github.com/solson/miri/blob/master/miri/intrinsic.rs#L501

i'm implementing this

Making these functions const would greatly interfere with custom DST.

Custom DSTs will need the user to implement some custom functions to derive the size. Thus, semantically, making size_of_val const would mean custom DST now need to depend on the postponed rust-lang/rfcs#2337.

Implementation-wise, if we want to support size_of_val for a thin CStr, we would need a const strlen, which means Miri would need to support some selected FFI functions (outside wasm), and also need to perform loop and dereference raw pointers (for wasm target).

Therefore I'm 👎 to making size_of_val and align_of_val const until we have a concrete plan on custom DST. I don't mind having a const fn len() on [T] and str though.

we would need a const strlen, which means Miri would need to support some selected FFI functions (outside wasm)

Why isn't it possible to implement strlen in Rust instead?

Why isn't it possible to implement strlen in Rust instead?

This is done for wasm, but as noted, that would require loops, which have an RFC, but it's not been accepted yet: rust-lang/rfcs#2344 and additionally requires branches, which have an accepted RFC, but no implementation yet

It also requires dereferencing a raw pointer and offset it, which probably needs the unsafe guideline.

pub unsafe fn strlen(mut s: *const c_char) -> usize {
    let mut n = 0;
    while *s != 0 {      // <-- loop & deref
        n += 1;
        s = s.offset(1); // <-- raw pointer offset
    }
    return n
}

Triage: looks like the original PR didn't get merged. We've been making more and more stuff const fn, what's the current status here?

@Gankra

@Gankra #63770 solves your problem, albeit not with size_of_val

@davidtwco

@davidtwco so just to be sure, you are fine with moving ahead here with const stabilization, and do not think this will adversely affect the future of your RFC or the entire unsized types / extern type / only-runtime-sized type situation?

@davidtwco so just to be sure, you are fine with moving ahead here with const stabilization, and do not think this will adversely affect the future of your RFC or the entire unsized types / extern type / only-runtime-sized type situation?

I think it should be okay for this to proceed. As long as this can be changed to ~const ?Sized backwards compatibly, and I believe it can be, then it wouldn't interfere with the current proposal.

If that bound is equivalent to ~const ValueSized then yeah that should work -- whatever transition deals with existing size_of_val calls outside const should be able to also deal with size_of_val calls inside const.

This does require const traits though, so the new hierarchy couldn't be stabilized until const traits are stable. But const traits are already a core part of that story so I assume that is anyway the case.

Stabilization PR is up: #133762

Rollup merge of rust-lang#133762 - RalfJung:const-size-of-val, r=work…

Unrolled build for rust-lang#133762

Rollup merge of #133762 - RalfJung:const-size-of-val, r=workingjubilee

Rollup merge of rust-lang#133762 - RalfJung:const-size-of-val, r=work…

Navigation Menu

Repository navigation

Tracking issue for `const_size_of_val` and `const_align_of_val` #46571

33 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for const_size_of_val and const_align_of_val #46571

Description

Activity

Gankra commented on Dec 7, 2017

Gankra commented on Dec 7, 2017

oli-obk commented on Dec 7, 2017

Gankra commented on Dec 7, 2017

polarathene commented on Apr 27, 2018

oli-obk commented on Apr 27, 2018

Gankra commented on May 9, 2018

kennytm commented on May 9, 2018

whitequark commented on May 9, 2018

oli-obk commented on May 9, 2018

kennytm commented on May 9, 2018

steveklabnik commented on Sep 22, 2019

oli-obk commented on Sep 22, 2019

33 remaining items

RalfJung commented on Nov 27, 2024

davidtwco commented on Dec 2, 2024

RalfJung commented on Dec 2, 2024

RalfJung commented on Dec 2, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tracking issue for `const_size_of_val` and `const_align_of_val` #46571