Allow borrowing array elements from packed structs with ABI align <= packed align #145419

hns1971 · 2025-08-15T03:12:11Z

Summary

This PR fixes a false positive E0793 ("reference to packed field is unaligned")
when borrowing from a #[repr(C, packed)] struct field whose type is a const-generic array
with an element type that has ABI alignment <= the struct's packed alignment.

Example before this change:

#[repr(C, packed)]
struct PascalString<const CAP: usize> {
    len: u8,
    buf: [u8; CAP],
}

fn bar<const CAP: usize>(s: &PascalString<CAP>) -> &str {
    std::str::from_utf8(&s.buf[0..s.len as usize]).unwrap()
}

Reference PR:

docs: add comprehensive documentation for borrowing from repr(packed)… reference#1984

- Add fallback mechanism in is_disaligned() when layout computation fails - Handle TooGeneric errors by computing element alignment from type structure - Fix packed-array-const-generic.rs test to pass compilation - Resolves issue where const generic parameters couldn't be resolved during alignment checks

rustbot · 2025-08-15T03:12:16Z

r? @SparrowLii

rustbot has assigned @SparrowLii.
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

rustbot · 2025-08-15T03:12:18Z

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

gralpli

Hey, I’m the bug reporter. Just what I noticed on a first glance.

compiler/rustc_const_eval/src/util/alignment.rs

tests/ui/packed/packed-array-const-generic.rs

lcnr · 2025-08-15T14:06:37Z

compiler/rustc_const_eval/src/util/alignment.rs

+        Ok(normalized) => normalized,
+        Err(_) => {
+            // If normalization fails, fall back to the original type
+            ty


why? it feels a lot safer to conservatively return true here, same as when layout_of fails

still relevant

lcnr · 2025-08-15T14:50:03Z

compiler/rustc_const_eval/src/util/alignment.rs

+            // For const generic arrays like [u8; CAP], we can make a reasonable assumption
+            // about their alignment based on the element type.


we're not making a reasonable assumption. Their layout literally only depend son the layout of their element type, doesn't it?

Getting this right is soundness critical, so we need to be confident about that we don#t introduce false negatives.

Also, please rename this function to is_potentially_disaligned, to clarify that it's allowed to return false positives, but not false nnegatives

We use "misaligned" elsewhere in the compiler, maybe let's go with that instead of "disaligned" (which I never saw/heard before).

also still relevant

Thanks for the detailed feedback!

I agree with the soundness concern and with using the term “misaligned”.
I will:

rename the function to is_potentially_misaligned and update call sites/docs to clarify that it may return false positives but must not return false negatives (soundness-critical),

avoid relaxing the check when layout_of(ty) fails in general.

To still address the motivating case without introducing false negatives, I’ll only add a very small, layout-free special-case:
when ty.kind() is Array(elem, _) and elem is u8 or i8 (which have ABI alignment 1 by definition, independent of the array length), we treat the borrow as not potentially misaligned. All other cases remain conservative and return true when layout_of(ty) fails.

This fixes the [u8; CAP] packed-struct case while keeping the function strictly conservative for any type whose ABI alignment could exceed the packed alignment.

If you’d prefer the even stricter variant (no special-casing at all), I can drop the exception and keep returning true on layout_of failure across the board.

I think ignoring the length and only checking the argument is fine. My issue was with the comment, not the behavior. We already guarantee that the alignment constraints are equal:

you can get a &T out of an &[T], so [T] must have stronger requirements than &T

you can get a &[T] from a &T via std::array::from_ref , so T must have stronger requirements than &[T]

Thanks! I’ve updated the comment to formally justify that align([T]) == align(T),
using the two directions you mentioned (&[T] -> &T and std::array::from_ref(&T)).
Behavior remains unchanged: we only consider the element type’s ABI alignment and
ignore the array length.

… clarity; Unified to ty::Array(element_ty, _) | ty::Slice(element_ty) => …; Modify Chinese comments to English comments

… clarity

rustbot · 2025-08-18T05:21:52Z

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

hns1971 · 2025-08-18T05:24:06Z

Fixed:

Rename is_disaligned to is_potentially_disaligned for better semantic clarity
Unified to ty::Array(element_ty, _) | ty::Slice(element_ty) => …
Modify Chinese comments to English comments.

Thanks

hns1971 · 2025-08-20T01:48:36Z

I've updated the PR as requested (renamed function, updated comment, removed special-casing). Just let me know if further adjustments are needed.

lcnr · 2025-08-22T08:59:18Z

compiler/rustc_const_eval/src/util/alignment.rs

+            // Only allow u8 and i8 arrays when layout computation fails
+            // Other types are conservatively assumed to be misaligned
+            match element_ty.kind() {


properly compute the of the element_ty here, limiting it to only u8 and i8 feels unnecessary 🤔

hns1971 · 2025-08-28T04:05:24Z

Thanks for the detailed feedback!

I’ve updated the PR with the following:

Generalized the check to any [T; N]: when layout_of([T; N]) is unavailable,
we compute layout_of(T) and compare abi_align(T) to the packed alignment.
This relies on align([T]) == align(T) (length is irrelevant).
I also updated the comment with the proof sketch:
(1) &[T] -> &T implies align([T]) >= align(T)
(2) std::array::from_ref(&T) -> &[T; 1] implies align(T) >= align([T])
Hence align([T]) == align(T).
Renamed the helper to is_potentially_misaligned and switched terminology to “misaligned”.
The doc comment now explicitly states that this may return false positives, but must not
return false negatives (soundness-critical).
Merged tests into a single file and renamed it to packed-array-generic-length.rs.
The test covers:
- allowed: [u8; N], [i8; N], [NonZeroU8; N], [MaybeUninit<u8>; N],
  and #[repr(transparent)](u8) wrappers
- still error: [u16; N], [NonZeroU16; N], and #[repr(transparent)](u16) wrappers

I’ve also drafted the exact rules in the PR description and opened a Reference PR
documenting this behavior (see rust-lang/reference#1984).
Please let me know if you want the rules tweaked further or if there’s a preferred place
in the Reference to put this.

tmandry · 2025-09-10T15:28:02Z

Does this PR create a new semver hazard? For example..

// In a remote crate
struct Remote(u8);

// In local crate
#[repr(packed)]
struct Local {
  remote: Remote,
}

let remote = &Local::default().remote;

Then Remote can be changed to have a u16, which is now a semver-breaking change.

@rfcbot concern semver hazard

Otherwise, +1 for the overall idea.

@rfcbot reviewed

RalfJung · 2025-09-10T15:33:14Z

That semver hazard already exists outside of arrays. This PR just makes the logic that figures out the alignment of a type smarter: we can know the alignment of [T; N] without knowing N.

RalfJung · 2025-09-10T15:36:52Z

compiler/rustc_const_eval/src/util/alignment.rs

+            // Soundness: For any `T`, the ABI alignment requirement of `[T]` equals that of `T`.
+            // Proof sketch:
+            //  (1) From `&[T]` we can obtain `&T`, hence align([T]) >= align(T).
+            //  (2) Using `std::array::from_ref(&T)` we can obtain `&[T; 1]` (and thus `&[T]`),
+            //      hence align(T) >= align([T]).
+            // Therefore align([T]) == align(T). Length does not affect alignment.


Suggested change

// Soundness: For any `T`, the ABI alignment requirement of `[T]` equals that of `T`.

// Proof sketch:

// (1) From `&[T]` we can obtain `&T`, hence align([T]) >= align(T).

// (2) Using `std::array::from_ref(&T)` we can obtain `&[T; 1]` (and thus `&[T]`),

// hence align(T) >= align([T]).

// Therefore align([T]) == align(T). Length does not affect alignment.

// We can't compute the layout of `T`. But maybe we can still compute the alignment:

// For any `T`, the ABI alignment requirement of `[T]` and `[T; N]` equals that of `T`.

// Length does not affect alignment.

I don't think referencing standard library operations here makes much sense. Maybe we can reference the Reference wherever it defines the alignment of arrays, but TBH that doesn't seem necessary. What's relevant is to explicitly invoke the fact o that arrays are aligned like their element type, that's the one key reasoning step needed here. Let's not drown that in noise.

still relevant

RalfJung · 2025-09-10T15:37:16Z

compiler/rustc_const_eval/src/util/alignment.rs

+    match ty.kind() {
+        ty::Array(elem_ty, _) | ty::Slice(elem_ty) => {
+            // Try to obtain the element's layout; if we can, use its ABI align.
+            match tcx.layout_of(typing_env.as_query_input(*elem_ty)) {


I'd recommend inlining this function at its only call site, this seems unnecessarily verbose.

If you want to make a helper function, it'd be get_type_align containing the entire match tcx.layout_of(typing_env.as_query_input(ty)) {.

still relevant, I would personally prefer adding a single get_type_align function which does the nested layout_of call

RalfJung · 2025-09-10T15:38:50Z

tests/ui/packed/packed-array-generic-length.rs

+}
+
+fn main() {
+    // Run pass cases (fail cases only check diagnostics)


These never get run anyway since the file fails to compile, so this is quite pointless.

I would split this test into a pass and a fail version. Having them in the same test may not actually test the pass cases as we often end up hiding errors if others have been emitted.

I don't have an opinion on whether to make that a run-pass test or not

RalfJung · 2025-09-10T15:40:30Z

tests/ui/packed/packed-array-generic-length.rs

+mod pass_i8 {
+    #[repr(C, packed)]
+    pub struct S<const N: usize> {
+        buf: [i8; N],
+    }
+    pub fn run() {
+        let s = S::<4> { buf: [1, 2, 3, 4] };
+        let _ok = &s.buf[..]; // no E0793
+    }
+}
+
+mod pass_nonzero_u8 {
+    use super::*;
+    #[repr(C, packed)]
+    pub struct S<const N: usize> {
+        buf: [NonZeroU8; N],
+    }
+    pub fn run() {
+        let s = S::<3> {
+            buf: [
+                NonZeroU8::new(1).unwrap(),
+                NonZeroU8::new(2).unwrap(),
+                NonZeroU8::new(3).unwrap(),
+            ],
+        };
+        let _ok = &s.buf[..]; // no E0793
+    }
+}
+
+mod pass_maybeuninit_u8 {
+    use super::*;
+    #[repr(C, packed)]
+    pub struct S<const N: usize> {
+        buf: [MaybeUninit<u8>; N],
+    }
+    pub fn run() {
+        let s = S::<2> { buf: [MaybeUninit::new(1), MaybeUninit::new(2)] };
+        let _ok = &s.buf[..]; // no E0793
+    }
+}
+
+mod pass_transparent_u8 {
+    #[repr(transparent)]
+    pub struct WrapU8(u8);
+
+    #[repr(C, packed)]
+    pub struct S<const N: usize> {
+        buf: [WrapU8; N],
+    }
+    pub fn run() {
+        let s = S::<2> { buf: [WrapU8(1), WrapU8(2)] };
+        let _ok = &s.buf[..]; // no E0793
+    }
+}


All of these already pass before your PR, so they don't actually test what you want them to test.

You need to make the N generic, like in pass_u8. (In the fail tests it should also be generic to ensure it hits the same codepath.)

RalfJung · 2025-09-10T15:40:48Z

tests/ui/packed/packed-array-generic-length.rs

+    pub fn run() {
+        let p = PascalString::<10> { len: 3, buf: *b"abc\0\0\0\0\0\0\0" };
+        let s = bar(&p);
+        assert_eq!(s, "abc");
+    }


There's no reason I can see for this function to exist.

still relevant

nikomatsakis · 2025-09-17T15:36:44Z

@rfcbot reviewed

The intent (make the warning more precise for cases where the packed struct fields do not actually have stricter alignment requirements) makes sense to me.

tmandry · 2025-09-17T15:44:21Z

Hmm, I wish we could address the semver hazard with repr(packed), but now that I understand what this PR actually does I can see it's not relevant.

@rfcbot resolve semver hazard

scottmcm · 2025-09-17T15:58:58Z

Thanks for the reference update.
@rfcbot resolve exact-rules-list

I do think that, from an implementation perspective, it's a bit icky for this particular check to do this dance of "fail to get layout, then do extra layout calculations". It feels like there ought to be a general query for "layout but I only care about alignment (or an under- or over-estimate thereof)" that everywhere that doesn't care about things like niches and field offsets, just the alignment, could use so that checks like this would always be consistent. (Like const prop of the Align UnOp in a MIR optimization arguably wants this as well.)

rust-rfcbot · 2025-09-17T15:59:05Z

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

RalfJung · 2025-09-17T17:18:49Z

I do think that, from an implementation perspective, it's a bit icky for this particular check to do this dance of "fail to get layout, then do extra layout calculations". It feels like there ought to be a general query for "layout but I only care about alignment (or an under- or over-estimate thereof)" that everywhere that doesn't care about things like niches and field offsets, just the alignment, could use so that checks like this would always be consistent. (Like const prop of the Align UnOp in a MIR optimization arguably wants this as well.)

Yeah, agreed.

Seems worth at least filing a C-cleanup issue for?

hns1971 · 2025-09-27T06:38:02Z

I do think that, from an implementation perspective, it's a bit icky for this particular check to do this dance of "fail to get layout, then do extra layout calculations". It feels like there ought to be a general query for "layout but I only care about alignment (or an under- or over-estimate thereof)" that everywhere that doesn't care about things like niches and field offsets, just the alignment, could use so that checks like this would always be consistent. (Like const prop of the Align UnOp in a MIR optimization arguably wants this as well.)

Yeah, agreed.

Seems worth at least filing a C-cleanup issue for?

Hi @RalfJung,

Thank you for the insightful architectural suggestion. I agree that a general align_of query would be a cleaner and more consistent solution, not only for this check but also for other parts of the compiler like const prop.

To keep the scope of this current PR focused and ensure it can be merged smoothly, I plan to file a follow-up issue to track this idea after this PR is merged. This will allow us to discuss and design the general query interface properly without blocking the immediate improvement here.

Thanks again for the review and the valuable idea.

RalfJung · 2025-09-27T09:17:38Z

Sounds good. :) Note that I didn't even make the architectural suggestion though. Also, no need to be so formal in your writing :) . Short and to the point beats long and verbose.

rust-rfcbot · 2025-09-27T16:03:33Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

bors · 2025-09-29T12:53:46Z

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

lcnr · 2025-09-30T09:05:00Z

@rustbot author

rustbot · 2025-09-30T09:05:06Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

hns1971 added 7 commits August 15, 2025 09:53

Fix code formatting issues

19f51f2

Fix remaining code formatting issues

a2a94b9

Fix TypingEnv formatting to match rustfmt requirements

2e84ab8

Fix TypingEnv formatting to match rustfmt requirements

d8785b9

Fix TypingEnv formatting to match rustfmt requirements

dd1537c

Fix TypingEnv formatting to match rustfmt requirements

99dedb0

rustbot assigned SparrowLii Aug 15, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 15, 2025

hns1971 mentioned this pull request Aug 15, 2025

Compiler doesn’t allow creating u8 slices when using const generics #145376

Open

This comment has been minimized.

Sign in to view

fix: update is_disaligned check and tests

4620527

gralpli reviewed Aug 15, 2025

View reviewed changes

compiler/rustc_const_eval/src/util/alignment.rs Outdated Show resolved Hide resolved

tests/ui/packed/packed-array-const-generic.rs Outdated Show resolved Hide resolved

lcnr reviewed Aug 15, 2025

View reviewed changes

hns1971 added 3 commits August 18, 2025 13:16

Rename is_disaligned to is_potentially_disaligned for better semantic…

2fe4b7f

… clarity; Unified to ty::Array(element_ty, _) | ty::Slice(element_ty) => …; Modify Chinese comments to English comments

Rename is_disaligned to is_potentially_disaligned for better semantic…

f0c8e9e

… clarity

Rename is_disaligned to is_potentially_disaligned for better semantic…

4a65fdc

… clarity

hns1971 requested review from RalfJung, lcnr and gralpli August 18, 2025 07:13

hns1971 added 2 commits August 18, 2025 16:38

Add test cases to verify u8/i8 array fix

585af05

updated the comment to formally justify that align([T]) == align(T)

b37f571

lcnr reviewed Aug 22, 2025

View reviewed changes

refactor: improve get_element_alignment function for packed arrays

ef2538b

This comment has been minimized.

Sign in to view

hns1971 mentioned this pull request Aug 27, 2025

docs: add comprehensive documentation for borrowing from repr(packed)… rust-lang/reference#1984

Open

modify commit for check

8c07e0a

RalfJung reviewed Sep 10, 2025

View reviewed changes

rust-rfcbot added final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. and removed proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. labels Sep 17, 2025

traviscross removed I-lang-nominated Nominated for discussion during a lang team meeting. P-lang-drag-1 Lang team prioritization drag level 1. https://rust-lang.zulipchat.com/#narrow/channel/410516-t-lang labels Sep 17, 2025

rustbot mentioned this pull request Sep 27, 2025

Tracking issue for release notes of #145419: Allow borrowing array elements from packed structs with ABI align <= packed align #147096

Open

workingjubilee mentioned this pull request Sep 27, 2025

cleanup quasi-layout alignment computations #147107

Open

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 30, 2025

		// For const generic arrays like [u8; CAP], we can make a reasonable assumption
		// about their alignment based on the element type.

Allow borrowing array elements from packed structs with ABI align <= packed align #145419

Are you sure you want to change the base?

Allow borrowing array elements from packed structs with ABI align <= packed align #145419

Uh oh!

Conversation

hns1971 commented Aug 15, 2025 • edited by traviscross Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Uh oh!

rustbot commented Aug 15, 2025

Uh oh!

rustbot commented Aug 15, 2025

Uh oh!

This comment has been minimized.

gralpli left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lcnr Aug 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lcnr Aug 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rustbot commented Aug 18, 2025

Uh oh!

hns1971 commented Aug 18, 2025

Uh oh!

hns1971 commented Aug 20, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

hns1971 commented Aug 28, 2025

Uh oh!

tmandry commented Sep 10, 2025

Uh oh!

RalfJung commented Sep 10, 2025

Uh oh!

RalfJung Sep 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nikomatsakis commented Sep 17, 2025

Uh oh!

tmandry commented Sep 17, 2025

Uh oh!

scottmcm commented Sep 17, 2025

Uh oh!

hns1971 commented Aug 15, 2025 •

edited by traviscross

Loading

lcnr Aug 15, 2025 •

edited

Loading

lcnr Aug 18, 2025 •

edited

Loading

RalfJung Sep 10, 2025 •

edited

Loading