Change:
<ins> // Test that unsized locals uphold alignment requirements. // Regression test for #71416. // run-pass #![feature(unsized_locals)] #![allow(incomplete_features)] use std::any::Any; #[repr(align(256))] #[allow(dead_code)] struct A { v: u8 } impl A { fn f(&self) -> *const A { assert_eq!(self as *const A as usize % 256, 0); self } } fn mk() -> Box<dyn Any> { Box::new(A { v: 4 }) } fn main() { let x = *mk(); let dwncst = x.downcast_ref::<A>().unwrap(); let addr = dwncst.f(); assert_eq!(addr as usize % 256, 0); } </ins>

Discussion:
Spawned off of Specifically this comment: quoted here: Also, this has been discussed before, hasn't it?
prioritize
(in ) is also statically unknown here, so yes this needs , that is indeed the entire point. ;)
Assigning as and removing . Assigning to myself as a followup of .
Here's a small optimization: pick some default alignment, maybe 16, then allocate bytes. If then because they are both powers of two, so the offset required to align to bytes is for , which is at most . If then the allocation will already be properly aligned, no offset required.

This is a variant of that was not fixed by still fails with
Given that libcore and liballoc enable this feature, I am rather concerned they could inadvertently use it in a way that is still unsound. Also, unless we can fix this, the feature should probably be to to warn people against using it.
rustc bootstraps successfully with applied, so at least right now that does not seem to be the case (modulo the part of libstd that rustc never monomorphizes). Of course, that could change any time, there is no check for this.
Yes, thanks for opening this. To be specific, the issue here is centered on this line: and the fact that we have , and LLVM alloca's don't respect the alignment requirements, right? I think there may be a separate issue on that. (Link?) But: one thing we had discussed was separating out the "sound" part and the "unsound" part into distinct feature gates, so that we can enable only the former in libstd. Perhaps that's a good focus for this issue?
cc who had discussed the separate feature gate, and who might be interested in doing the follow-up work to create that gate.
Yes. Oh, I didn't know that. Let's see if someone finds it.^^ Unlike the other unsound features, this is one where we don't even have a plan for how to soundly implement it. Not sure how much I like keeping that around.
Yes, I see that argument. I'm reminded of , which limits the max alignment to 4K because of limits in dynamic linkers, though there's no real connection. It's just that part of the challenge here is that the alignment of a is totally unknown -- it's not like we can conservatively align to 64 bytes or something.
If lands we could conservatively align to 4k here. :rofl: (no I am not serious)
Assigning as , removing and nominating for discussion on our next weekly meeting.
Can't we do something dynamic where we allocate and align it ourselves? Also, this has been discussed before, hasn't it?
With being stable, this can be observed in stable compiler: EDIT: its fixed in nightly, never mind.
I don't know -- in we mostly talked about how to mitigate the effect on stable Rust.

D'oh, I somehow forgot that one can manually implement "aligned" allocation on top of an unaligned allocator. Of course that would work. That's probably better than killing this part of codegen entirely.^^
, leaving the nomination up for now as requested by He wants to open some fresh issues about this.
Now that I've created more specific issues to track the important sub-tasks identified here, I think we can remove this from the nominated tickets.
Given that this feature has been removed from core/alloc and is unstable, I'm going to downgrade this to P-medium. This should obviously block stabilization of , but doesn't need special attention outside of that.