make `sizeof`, `alignof`, `offsetof` and other type calculations available for use in constants

[nikomatsakis]

Currently, the standard library offers functions like size_of, but they are not available for use in constant expressions. It would be useful to be able to call such functions from constants, but it raises some interesting questions. For example:

1. only the backend can faithfully compute the size of a type, but sometimes the front-end may need to know the actual value of a constant to decide (e.g.) if two constants are equal. (Some of these issues also arise with associated constants.)
2. do we want keywords for these computations (like C), or should we try to adapt functions (perhaps via const fn)?
3. etc

Related RFCs and comments:

• Sizeof, alignof, offsetof, typeof #591 -- add sizeof, alignof, offsetof intrinsics, etc
• This comment by @eddyb, which sketches out how associated constants and some compiler magic could be used instead of keywords.
• Constants that depend on type parameters in generic code #1062 -- constants that depend on type parameters in generic code

[Mr-Byte]

For consistency, I'd be in favor of these being const fn instead of actual keywords.

[eddyb]

There is a compromise we can make to avoid going the static structural reflection route:

Allow dereferencing raw pointers which were cast from an integer, and produce an internal AddressLvalue(addr) constant value, equivalent to *(addr as *const _) in an unsafe context.
Only operations which are arithmetic on addr are accepted, e.g. field access, indexing, .offset.

Taking a reference to such lvalue results in Ref(AddressLvalue(addr)), which can be coerced to *const T, producing addr as *const, which can, in turn, be cast back to an integer type to retrieve addr.

At the API "membrane" level, constants (global/associated/generic const and const fn arguments/returns, maybe excluding intrinsics) have to be pure, which means no AddressLvalue present anywhere in them, and the origin of raw pointers cannot be assumed to be a safe reference, nor an integer address, so both dereferencing and casting back to integers is disallowed at that point.

This is enough to implement the "traditional" offsetof macro, with the representation logic lifted up from trans/LLVM to rustc proper.

[comex]

👍 was just reminded that some of my code would really benefit from this.

[kennytm]

In rust-lang/rust#32021, @huonw wrote

Unfortunately, the feature has some (possibly) surprising subtleties that make it trickier than one might hope.

I'm not sure what kind of subtleties are there in making mem::size_of (not size_of_val) a const fn. It doesn't involve any kind of AddressLvalue AFAICT.

[eddyb]

@kennytm FWIW I was talking about offsetof.

[joshtriplett]

For size_of and align_of, I'd like to see them as functions, not keywords. offset_of seems like it requires a macro, to accept a field name.

[burdges]

Is there an issue with making these associated constants?

As an aside, I noticed the associated constants i16::MIN and i16::MAX are painful to access, while min_value() and max_value() remain easy.

[Binero]

Could be made accessible through a trait so you can be generic over integers with different reaches.

[cptroot]

Is there any update on the status of offsetof? I would love to have access to it for the purpose of kernel internal linked lists.