Use bytemuck which provides out-of-the-box safe abstractions for POD types.
If you are seeking performance improvements, use <[_]>::align_to(). This is still unsafe, but it at least gets the alignment right.
*Some people debate this, asserting that some of the Miri positives are merely "not yet settled" in the language definition. I think the principled and correct way is to treat those as UB, pretty much by definition – let's not start/continue this debate here, please.
Actually, miri has a flag -Zmiri-symbolic-alignment-check which prevents "discovering" that a pointer is more aligned than is required. (And this is documented as causing false positives when code does alignment checks itself.) This is (part of) the reason align_to is allowed to "fail" to provide a maximal middle part.
-Zmiri-symbolic-alignment-check makes the alignment check more strict. By default, alignment is checked by casting the pointer to an integer, and making sure that is a multiple of the alignment. This can lead to cases where a program passes the alignment check by pure chance, because things "happened to be" sufficiently aligned -- there is no UB in this execution but there would be UB in others. To avoid such cases, the symbolic alignment check only takes into account the requested alignment of the relevant allocation, and the offset into that allocation. This avoids missing such bugs, but it also incurs some false positives when the code does manual integer arithmetic to ensure alignment. (The standard library align_to method works fine in both modes; under symbolic alignment it only fills the middle slice when the allocation guarantees sufficient alignment.)
Based on the described behavior, my first guess would be that this flag is getting set somehow (MIRIFLAGS?), and doesn't get unset by -Zmiri-disable-alignment-check; with the alignment check disabled, this error shouldn't happen at all.
-Zmiri-disable-alignment-check disables checking pointer alignment, so you can focus on other failures, but it means Miri can miss bugs in your program. Using this flag is unsound.
There's not a direct way, as far as I'm aware. You can, however, set a #[global_allocator] which rounds up align/size to whatever base alignment you want to model this.
I don't think this contradicts what I wrote. The allocation itself was never properly aligned, so using it was always incorrect. It could have dynamically led to UB upon any future execution, as it only happened to work by pure chance. I don't think working by pure chance counts as "properly aligned".
It's at best not reliable, at worst UB, and the subject of the scrutiny should not be what happened to "work" upon one particular execution; it should be how the code must be modified to achieve a reliably correct execution at all times.
However, the code in the OP never performs any manual aligning or even alignment checks itself. I guess this definition of a "false" positive is not very useful, specifically in cases where such "obvious"(ly wrong) code is being run under Miri. Here, the Miri error does point out a legitimate problem in the code, and it is most definitely the code that should be fixed, not Miri's definition of an error.
Thanks for the reply.
Interesting that vec! changes the behavior.
Miri seems to complain even if I check alignment before converting to a reference.
I don't know how to set -Zmiri-seed on playground, but I get the error on my local machine with a seed that meets the alignment.
I know the code is fundamentally unsafe, but there is a large piece of code that would take much time to fix, and I want to find other bugs first if I can, ignoring the alignment because the system allocator has minimum alignment anyways.
Interestingly, using global_allocator to force layout.align() to 8 seems to work!