Tracking issue for RFC 2043: Add `align_offset` intrinsic (formerly: and `[T]::align_to` function)

[aturon]

This is a tracking issue for the RFC "Add align_offset intrinsic and [T]::align_to function " (rust-lang/rfcs#2043). align_to is stable, so this tracks just align_offset now.

Steps:

• Implement the RFC (align_offset: Add align_offset intrinsic #43903; align_to: Implement [T]::align_to #50319)
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge): align_to: stabilize slice_align_to #53754

Unresolved questions:

• "produce a lint in case sizeof<T>() % sizeof<U>() != 0 and in case the expansion is not part of a monomorphisation, since in that case align_to is statically known to never be effective

[SimonSapin]

@oli-obk Is it useful to stabilize align_offset before align_to is implemented?

[oli-obk]

Generally yes, because that's the key feature. Align_to is just convenience

[SimonSapin]

Alright, then. Let’s stabilize align_offset and leave this issue open for tracking align_to.

@rfcbot fcp merge

[rfcbot]

Team member @SimonSapin has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Kimundi
• @SimonSapin
• @alexcrichton
• @aturon
• @dtolnay
• @sfackler
• @withoutboats

Concerns:

• motivation-and-ergonomics resolved by Tracking issue for RFC 2043: Add align_offset intrinsic (formerly: and [T]::align_to function) #44488 (comment)

Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[alexcrichton]

@rfcbot concern motivation-and-ergonomics

The original motivation for these functions (unless it's changed, which it may have!) I believe was for miri and const evaluating various functions. Is that still the main motivation for these functions? If so do we expect that more things to be available on stable once these are stabilized?

I'm a little unclear about how and when such an intrinsic would be used so I'm mostly looking to straighten up my own thinking! In particular the clause "If it is not possible to align the pointer, the implementation returns usize::max_value()." I'm having trouble wrapping my head around in how it'd be expected to get used.

Is the long term plan to make this a const fn but otherwise disallow operations like *mut T as usize in a const fn?

In terms of ergonomics I'd also naively expect a signature like:

pub fn align_to(self, align: usize) -> Option<*mut Self>;

but would that create the same problems it's trying to avoid?