Add Align type with const generic controlled alignment#154730
Add Align type with const generic controlled alignment#154730beepster4096 wants to merge 1 commit intorust-lang:mainfrom
Conversation
f12a0b4 to
df7c1c7
Compare
| @@ -0,0 +1,21 @@ | |||
| // FIXME: should this pass? | |||
There was a problem hiding this comment.
My instinct is that it definitely shouldn't pass, but maybe it doesn't fail elegantly -- perhaps it fails in the same way that [u32; usize::MAX / 4] fails, for example.
There was a problem hiding this comment.
Hm, types that are too large don't fail in these positions either
There was a problem hiding this comment.
Oh, because it's just a check build or something?
If it's consistent with malformed arrays that's probably fine -- for now at least.
|
|
||
| let mut repr = def.repr(); | ||
|
|
||
| // FIXME: should this have a flag on the adtdef? |
There was a problem hiding this comment.
My instinct is no, because everything other than layout should just treat it as a normal type with a generic-dependent layout, never switch on some type flag to detect it.
| const MAX_SUPPORTED_ALIGN: usize = 1 << 29; | ||
|
|
||
| const _: () = { | ||
| // FIXME: should this fail? |
There was a problem hiding this comment.
Yes, same as #[repr(align(0))] and mem::Alignment::new(0).unwrap().
(And how https://doc.rust-lang.org/std/primitive.usize.html#method.is_power_of_two does not treat zero as a power of two.)
|
☔ The latest upstream changes (presumably #139087) made this pull request unmergeable. Please resolve the merge conflicts. |
Added:
Unresolved problems/questions:
Align<N>with invalid N will compile as long as its layout is never needed (seetests\ui\layout\align-type\invalid-unused.rs) Should this happen?Align<0>is valid and has an alignment of 1. Is this okay?r? scottmcm