align_offset, align_to: no longer allow implementations to spuriously fail to align

[RalfJung]

For a long time, we have allowed align_offset to fail to compute a properly aligned offset, and align_to to return a smaller-than-maximal "middle slice". This was done to cover the implementation of align_offset in const-eval and Miri. See #62420 for more background. For about the same amount of time, this has caused confusion and surprise, where people didn't realize they have to write their code to be defensive against align_offset failures.

Another way to put this is: the specification is effectively non-deterministic, and non-determinism is hard to test for -- in particular if the implementation everyone uses to test always produces the same reliable result, and nobody expects it to be non-deterministic to begin with.

With #117840, Miri has stopped making use of this liberty in the spec; it now always behaves like rustc. That only leaves const-eval as potential motivation for this behavior. I do not think this is sufficient motivation. Currently, none of the relevant functions are stably const: align_offset is unstably const, align_to is not const at all. I propose that if we ever want to make these const-stable, we just accept the fact that they can behave differently at compile-time vs at run-time. This is not the end of the world, and it seems to be much less surprising to programmers than unexpected non-determinism. (Related: rust-lang/rfcs#3352.)

@thomcc has repeatedly made it clear that they strongly dislike the non-determinism in align_offset, so I expect they will support this. @oli-obk, what do you think? Also, whom else should we involve? The primary team responsible is clearly libs-api, so I will nominate this for them. However, allowing const-evaluated code to behave different from run-time code is t-lang territory. The thing is, this is not stabilizing anything t-lang-worthy immediately, but it still does make a decision we will be bound to: if we accept this change, then

• either align_offset/align_to can never be called in const fn,
• or we allow compile-time behavior to differ from run-time behavior.

So I will nominate for t-lang as well, with the question being: are you okay with accepting either of these outcomes (without committing to which one, just accepting that it has to be one of them)? This closes the door to "have align_offset and align_to at compile-time and also always have compile-time behavior match run-time behavior".

Closes #62420

r? @cuviper

rustbot has assigned @cuviper.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Note that the opposite of this PR exists at #105296

Not sure in which sense that is the "opposite". I think having these APIs you propose is a good idea no matter what we do with align_to. But I also think having those APIs does not stop us from removing a footgun in align_to if we don't have sufficient motivation to keep the footgun.

But I also think having those APIs does not stop us from removing a footgun in align_to if we don't have sufficient motivation to keep the footgun.

those were only ever added to support making str::from_utf8 const at some point. That was their original motivation. If we close the door for that, it'll just mean we have to add the same function, but fallible, again.

I guess public usage of the functions does show what people want out of these APIs, so 🤷 let's just do it and figure things out when we're ready to make more stuff const

those were only ever added to support making str::from_utf8 const at some point. That was their original motivation. If we close the door for that, it'll just mean we have to add the same function, but fallible, again.

We're not closing the door on that though. from_utf8 can use align_offset and it will be correct

• at run-time, for obvious reasons
• at compile-time, because from_utf8 is written in a way to be robust to align_offset failing due to compile-time constraints

We discussed this in the libs-api meeting, and those present were happy with this change.

@rfcbot merge

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

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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.

🔔 This is now entering its final comment period, as per the review above. 🔔

With my lang hat on:

If I'm understanding correctly, these can differ at compile time precisely because the concept of addresses and them having alignment isn't the same at compile-time and runtime. That seems fine. We will still have options at compile-time; for instance, if we want to track the concept of "sufficiently aligned" at compile time, we could decide to do so in an abstract way.

If I'm understanding correctly, these can differ at compile time precisely because the concept of addresses and them having alignment isn't the same at compile-time and runtime.

Yes. The only time compile-time would give a "weird" answer is when the information required to give the expected answer is inherently unavailable at compile-time.

We will still have options at compile-time; for instance, if we want to track the concept of "sufficiently aligned" at compile time, we could decide to do so in an abstract way.

I think that might be tricky, e.g. if one crate declares a [u8; N] buffer stored somewhere then even tracking abstract alignment means downstream crates could be adding alignment constraints to that, e.g. deciding that it must be 4-aligned. I also don't think we actually want align_to to change the alignment of these static global objects.

Ah, align_to isn't const fn. Saying it won't be, and thus we can make strict promises about that function makes good sense to me, given all the complaints about it.

We can add a different function for const fn later if really needed.

@rustbot labels -I-lang-nominated

We discussed this in the lang call on 2024-03-13 and agreed that we were OK with this having been merged and the consequences of that noted in the original nomination.

Sorry, I hadn't realized the T-lang discussion was still open when this got approved.