Make `align_of` behave like `min_align_of`.

[huonw]

This removes a footgun, since it is a reasonable assumption to make that
pointers to T will be aligned to align_of::<T>(). This also matches
the behaviour of C/C++. min_align_of is now deprecated.

Closes #21611.

[rust-highfive]

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

[brson]

These functions have changed so many times. How can we know this time is right? It even seems to conflict with the deleted comment 'We use the preferred alignment as the default alignment for a type. This appears to be what clang migrated towards as well'.

This is a stable breaking change and should be marked as such.

[brson]

cc @aturon re breakage

[alexcrichton]

I think that the "breakage" here in this sense is fine (through deprecation), but I agree with @brson that this may want some more research into what clang is using and why (e.g. do we still match them?)

[bors]

☔️ The latest upstream changes (presumably #25790) made this pull request unmergeable. Please resolve the merge conflicts.

[brson]

It's not breaking because of the deprecation but because it changes the values reported by the non-deprecated stable align_of function.

[brson]

Nominating this because of the breakiness. If this is important we should do it fast.

[huonw]

I have a strong suspicion this won't cause any significant actual breakage. In fact, I suspect this change will unbreak more code than it breaks (code that was assuming that T pointers are guaranteed to have align_of::<T>() alignment, which is far more true after this patch).

I looked through all the search results for "mem align_of" and didn't see anything where this would cause breakage. Essentially all uses of align_of::<T>() are fed into allocate/reallocate/deallocate calls, and these are all fine as long as (a) the alignment is valid for type T (which is true), and (b) each of those functions gets called with the same alignment value (also true).

(I did notice some places in the search results which fall prey to making invalid assumptions about align_of... including in my own code. whoops.)

---

Unfortunately, I just realised this change still doesn't guarantee that every &T pointer will be aligned to align_of::<T>(), due to packed fields, e.g. this prints 1, but "should" print 0:

use std::mem;

#[repr(packed)]
struct Foo {
    _x: u8,
    y: u32,
}
fn main() {
    let x = Foo { _x: 0, y: 0 };

    println!("{}", &x.y as *const _ as usize % mem::align_of::<u32>())
}

However, I think this is still an improvement: the example in #21611 seems like a footgun (there's nothing special about the struct in that example).

We use the preferred alignment as the default alignment for a type. This appears to be what clang migrated towards as well

It seems we're currently using a different definition of preferred, e.g. clang's behaviour is what I'd expect Rust to do.

[Gankro]

I'm in favour of this change; basically no one on on stable could have been using this (it's only really useful for the heap::allocate API AFAICT). Everyone on unstable was wrong if they were using align_of. If they were correctly using min_align_of then they get a correct error.

[alexcrichton]

I, too, would be in favor of this to bring us in line with clang. I share @brson's concerns in that very low-level code like this often has very large ramifications later on down the road, but I'm fairly confident that those kinds of libraries have yet to be written (or are still underway), so now's definitely the time for a change like this.

[alexcrichton]

This PR is now entering its week-long final comment period.

[nikomatsakis]

I feel very strongly that anything called "align-of" (with no qualifier) ought to be doing the same thing that you would get with C/C++'s alignof operator. I don't have the C or C++ spec handy, but some quick web searching suggests to me that "min align of" is indeed that value. (For all I know, the precise semantics of the alignof operator are only loosely defined in the spec -- but in either case being compatible with gcc/clang is very likely to meet expectations.)

Therefore: 👍

[alexcrichton]

The consensus of the library subteam was to merge this, and @huonw has taken a blood oath that this is the correct implementation, assuaging @brson's fears.

r=me with a rebase, thanks @huonw!

[brson]

Nominating for backport to 1.2. Needs to be added to relnotes as a change in behavior.

[huonw]

@bors r=alexcrichton

[bors]

📌 Commit 225b116 has been approved by alexcrichton

[bors]

⌛️ Testing commit 225b116 with merge 378a370...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt

[alexcrichton]

triage: beta-accepted