const_fn usage

[birkenfeld]

I know it's hard/impossible right now, but are you tracking the ongoing const_fn changes to ensure that offset_of! can be used in constants at some point? It's usually very useful in tandem with size_of(), which is already const fn.

[Gilnaa]

I sure am.

iirc const fns cannot receive pointers at the moment and it might block this feature, but I have yet to experiment with this.

[RalfJung]

Status update: Doing offset_of in const was possible until very recently, but only in a way that triggered UB. Now the const engine got better at finding UB, and that trick does not work any more.

We'll keep this issue open to track adding const support here once that's possible.

Also see the discussion starting here.

[thedrow]

I just bumped into this myself.
I would love to have a solution.

[RalfJung]

Cc rust-lang/rust#63810

[RalfJung]

rust-lang/rust#63810 has landed; with that we should be able to allow const-fn usage on nightly. :)

[Gilnaa]

Should we feature-gate it further than just on nightly to avoid future breakages?
Do you have an ETA for when it'll be stable?

[RalfJung]

Should we feature-gate it further than just on nightly to avoid future breakages?

That's probably a good idea.

Do you have an ETA for when it'll be stable?

No.

[Gilnaa]

A'right, I'll try working on it tomorrow

[RalfJung]

Lol, I was going to do the same. ;)

[RalfJung]

@Gilnaa Go ahead then, I'll review your PR. ;)
See this for one possible option; we'd have to adjust this a bit but I like putting the entire computation into an intermediate const. That way we can be sure that anything weird we do only happens at compile-time, not at run-time.

[martinboehme]

I would be interested in using memoffset in a const fn context without having to use unstable features. Do you have a sense of how far along these features are in the stabilization process -- i.e. how much additional time and effort will be required to stabilize them?

I'm happy to ask on the individual tracking bugs for the features and do some work to get them stabilized, I just figured I should ask here first.

[RalfJung]

I am not quite sure, @oli-obk might know better.

We currently need the following features: const_ptr_offset_from, const_maybe_uninit_as_ptr, const_raw_ptr_deref, const_refs_to_cell (the latter only if the struct you use with offset_of contains interior mutability).

[oli-obk]

This is all still blocked on me finishing rust-lang/nomicon#221, after which we can finally start stabilizing lots of unsafe const things

[kupiakos]

I think I have a way to calculate this in stable CTFE that doesn't require pointer offset, it's just more expensive at compile-time: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2910d9be2d2b7a1c9e584bde946306ee. The key here is that you can create a buffer that holds the bytes of the offset, ptr::addr_of! into the buffer as if it were a T, and do a *const u8 deref. No pointer math, but expensive-ish setup.

What are your thoughts, other than Deref coercion?

[RalfJung]

What happens if the offset does not fit into a u8?