Use `#[repr(C)]` on debuginfo test structs by Walnut356 · Pull Request #162364 · rust-lang/rust

Walnut356 · 2026-09-06T10:41:56Z

This fixes a couple of issues.

LLDB reading PDB debug info re-orders fields and displays them in offset order instead of source-order like DWARF. While this has been fixed upstream, it'll be quite a while before it's reflected in CI runners and such
For all targets, the structs were often written (and named) under the assumption that they would have specific layouts. Nothing was actually enforcing those assumed layouts, so very often a type would be named e.g. HasInternalPadding but rust would reorder it such that no internal padding existed.

struct-with-destructor.rs is still iffy. I'll test it when I get home and can update my main PC's LLDB.

On my remote PC (lldb 22.1.2) it didn't fix the test, and it looked like the variable was straight up being read incorrectly:

// expected:
(struct_with_destructor::NestedOuter) nested = {a:{a:{x:7890, y:9870}}}
// got:
(struct_with_destructor::NestedOuter) nested = {a:{a:{y:1378684509906, x:9870}}

On my laptop when manually inspecting it (CodeLLDB which uses 22.1.8 under the hood) everything looked fine, so it might have been a bug that LLDB patched.

Part of the MSVC test fixes for #161657

r? @Kobzol, @jieyouxu

test-jobs: aarch64-apple-1
test-jobs: aarch64-msvc-1
test-jobs: x86_64-msvc-1
test-jobs: x86_64-mingw-1

rustbot · 2026-09-06T10:42:01Z

Kobzol is not on the review rotation at the moment.
They may take a while to respond.

jieyouxu

Yeah thanks, this definitely makes sense. I guess I'm more surprised that not more tests are failing due to assumed layouts.
r? me
You can r=me once the try jobs come back green.

View changes since this review

jieyouxu · 2026-09-06T10:51:02Z

@bors delegate+
@bors try

rust-bors · 2026-09-06T10:51:04Z

✌️ @Walnut356, you can now approve this pull request!

If @jieyouxu told you to "r=me" after making some further change, then please make that change and post @bors r=jieyouxu.

View changes since this delegation.

Use `#[repr(C)]` on debuginfo test structs

rust-bors · 2026-09-06T11:50:04Z

☀️ Try build successful (CI)
Build commit: e712a43 (e712a43793a5be62fafc25ae9f8da2fad1ca9a31)
Base parent: 46a266b (46a266b9fb0fb75e05fa4c9132f7355fcb62d4a4)

jieyouxu · 2026-09-06T12:21:35Z

@bors r+

rust-bors · 2026-09-06T12:21:37Z

📌 Commit 81fcec3 has been approved by jieyouxu

It is now in the queue for this repository.

@Kobzol

Use `#[repr(C)]` on debuginfo test structs This fixes a couple of issues. * LLDB reading PDB debug info re-orders fields and displays them in offset order instead of source-order like DWARF. While this has been [fixed upstream](llvm/llvm-project#218731), it'll be quite a while before it's reflected in CI runners and such * For all targets, the structs were often written (and named) under the assumption that they would have specific layouts. Nothing was actually enforcing those assumed layouts, so very often a type would be named e.g. `HasInternalPadding` but rust would reorder it such that no internal padding existed. `struct-with-destructor.rs` is still iffy. I'll test it when I get home and can update my main PC's LLDB. On my remote PC (lldb 22.1.2) it didn't fix the test, and it looked like the variable was straight up being read incorrectly: ``` // expected: (struct_with_destructor::NestedOuter) nested = {a:{a:{x:7890, y:9870}}} // got: (struct_with_destructor::NestedOuter) nested = {a:{a:{y:1378684509906, x:9870}} ``` On my laptop when manually inspecting it (CodeLLDB which uses 22.1.8 under the hood) everything looked fine, so it might have been a bug that LLDB patched. Part of the MSVC test fixes for rust-lang#161657 r? @Kobzol, @jieyouxu --- test-jobs: aarch64-apple-1 test-jobs: aarch64-msvc-1 test-jobs: x86_64-msvc-1 test-jobs: x86_64-mingw-1

…uwer Rollup of 5 pull requests Successful merges: - #159541 (Use query for Variant InhabitedPredicate) - #162364 (Use `#[repr(C)]` on debuginfo test structs) - #162215 (remove stale/duplicate tests) - #162335 (Add several new LLDB feature flags) - #162341 (add regression test for packus_epi16 issue)

@Kobzol

Use `#[repr(C)]` on debuginfo test structs This fixes a couple of issues. * LLDB reading PDB debug info re-orders fields and displays them in offset order instead of source-order like DWARF. While this has been [fixed upstream](llvm/llvm-project#218731), it'll be quite a while before it's reflected in CI runners and such * For all targets, the structs were often written (and named) under the assumption that they would have specific layouts. Nothing was actually enforcing those assumed layouts, so very often a type would be named e.g. `HasInternalPadding` but rust would reorder it such that no internal padding existed. `struct-with-destructor.rs` is still iffy. I'll test it when I get home and can update my main PC's LLDB. On my remote PC (lldb 22.1.2) it didn't fix the test, and it looked like the variable was straight up being read incorrectly: ``` // expected: (struct_with_destructor::NestedOuter) nested = {a:{a:{x:7890, y:9870}}} // got: (struct_with_destructor::NestedOuter) nested = {a:{a:{y:1378684509906, x:9870}} ``` On my laptop when manually inspecting it (CodeLLDB which uses 22.1.8 under the hood) everything looked fine, so it might have been a bug that LLDB patched. Part of the MSVC test fixes for rust-lang#161657 r? @Kobzol, @jieyouxu --- test-jobs: aarch64-apple-1 test-jobs: aarch64-msvc-1 test-jobs: x86_64-msvc-1 test-jobs: x86_64-mingw-1

…uwer Rollup of 7 pull requests Successful merges: - #162358 (Force u8/i8 numeric formatting on LLDB) - #162359 (Use `lldb.eTypeOptionHideChildren` for msvc tuples) - #162364 (Use `#[repr(C)]` on debuginfo test structs) - #162215 (remove stale/duplicate tests) - #162335 (Add several new LLDB feature flags) - #162341 (add regression test for packus_epi16 issue) - #162374 (Make `VaArgSafe` dyn-incompatible)

JonathanBrouwer · 2026-09-06T18:21:58Z

@bors try jobs=x86_64-mingw-1,x86_64-msvc-1

rust-bors · 2026-09-06T18:22:06Z

⌛ Trying commit 81fcec3 with merge 115f425…

To cancel the try build, run the command @bors try cancel.

Workflow: https://github.com/rust-lang/rust/actions/runs/34051488529

Use `#[repr(C)]` on debuginfo test structs try-job: x86_64-mingw-1 try-job: x86_64-msvc-1

JonathanBrouwer · 2026-09-06T18:22:41Z

@bors try cancel

rust-bors · 2026-09-06T18:22:45Z

Try build cancelled. Cancelled workflows:

https://github.com/rust-lang/rust/actions/runs/34051488529

Hint: if you want to run another try build, you do not need to manually cancel the previous one. Just run @bors try and bors will cancel the previous build automatically.

…uwer Rollup of 5 pull requests Successful merges: - #162358 (Force u8/i8 numeric formatting on LLDB) - #162359 (Use `lldb.eTypeOptionHideChildren` for msvc tuples) - #162364 (Use `#[repr(C)]` on debuginfo test structs) - #162215 (remove stale/duplicate tests) - #162335 (Add several new LLDB feature flags)

@Kobzol

Rollup merge of #162364 - Walnut356:debuginfo_repr, r=jieyouxu Use `#[repr(C)]` on debuginfo test structs This fixes a couple of issues. * LLDB reading PDB debug info re-orders fields and displays them in offset order instead of source-order like DWARF. While this has been [fixed upstream](llvm/llvm-project#218731), it'll be quite a while before it's reflected in CI runners and such * For all targets, the structs were often written (and named) under the assumption that they would have specific layouts. Nothing was actually enforcing those assumed layouts, so very often a type would be named e.g. `HasInternalPadding` but rust would reorder it such that no internal padding existed. `struct-with-destructor.rs` is still iffy. I'll test it when I get home and can update my main PC's LLDB. On my remote PC (lldb 22.1.2) it didn't fix the test, and it looked like the variable was straight up being read incorrectly: ``` // expected: (struct_with_destructor::NestedOuter) nested = {a:{a:{x:7890, y:9870}}} // got: (struct_with_destructor::NestedOuter) nested = {a:{a:{y:1378684509906, x:9870}} ``` On my laptop when manually inspecting it (CodeLLDB which uses 22.1.8 under the hood) everything looked fine, so it might have been a bug that LLDB patched. Part of the MSVC test fixes for #161657 r? @Kobzol, @jieyouxu --- test-jobs: aarch64-apple-1 test-jobs: aarch64-msvc-1 test-jobs: x86_64-msvc-1 test-jobs: x86_64-mingw-1

use #[repr(C)] on debuginfo test structs

81fcec3

rustbot assigned Kobzol Sep 6, 2026

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 Sep 6, 2026

jieyouxu approved these changes Sep 6, 2026

View reviewed changes

rustbot assigned jieyouxu and unassigned Kobzol Sep 6, 2026

This comment has been minimized.

Sign in to view

rust-bors Bot pushed a commit that referenced this pull request Sep 6, 2026

Auto merge of #162364 - Walnut356:debuginfo_repr, r=<try>

e712a43

Use `#[repr(C)]` on debuginfo test structs

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 6, 2026

JonathanBrouwer mentioned this pull request Sep 6, 2026

Rollup of 5 pull requests #162370

Closed

JonathanBrouwer mentioned this pull request Sep 6, 2026

Rollup of 7 pull requests #162375

Closed

rust-bors Bot pushed a commit that referenced this pull request Sep 6, 2026

Auto merge of #162364 - Walnut356:debuginfo_repr, r=<try>

115f425

Use `#[repr(C)]` on debuginfo test structs try-job: x86_64-mingw-1 try-job: x86_64-msvc-1

JonathanBrouwer mentioned this pull request Sep 6, 2026

Rollup of 5 pull requests #162382

Merged

rust-bors Bot merged commit 2a91880 into rust-lang:main Sep 6, 2026
13 of 14 checks passed

rustbot added this to the 1.100.0 milestone Sep 6, 2026

Navigation Menu

Uh oh!

Uh oh!

Use `#[repr(C)]` on debuginfo test structs - #162364

Use `#[repr(C)]` on debuginfo test structs#162364
rust-bors[bot] merged 1 commit into
rust-lang:mainfrom
Walnut356:debuginfo_repr

Walnut356 commented Sep 6, 2026 •

edited by jieyouxu

Loading

Uh oh!

rustbot commented Sep 6, 2026

Uh oh!

jieyouxu left a comment •

edited

Loading

Uh oh!

jieyouxu commented Sep 6, 2026

Uh oh!

rust-bors Bot commented Sep 6, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Sep 6, 2026

Uh oh!

jieyouxu commented Sep 6, 2026

Uh oh!

rust-bors Bot commented Sep 6, 2026

Uh oh!

JonathanBrouwer commented Sep 6, 2026

Uh oh!

rust-bors Bot commented Sep 6, 2026 •

edited

Loading

Uh oh!

JonathanBrouwer commented Sep 6, 2026

Uh oh!

rust-bors Bot commented Sep 6, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Uh oh!

Uh oh!

Conversation

Walnut356 commented Sep 6, 2026 • edited by jieyouxu Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Sep 6, 2026

Uh oh!

jieyouxu left a comment • 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!

jieyouxu commented Sep 6, 2026

Uh oh!

rust-bors Bot commented Sep 6, 2026

Uh oh!

This comment has been minimized.

rust-bors Bot commented Sep 6, 2026

Uh oh!

jieyouxu commented Sep 6, 2026

Uh oh!

rust-bors Bot commented Sep 6, 2026

Uh oh!

JonathanBrouwer commented Sep 6, 2026

Uh oh!

rust-bors Bot commented Sep 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

JonathanBrouwer commented Sep 6, 2026

Uh oh!

rust-bors Bot commented Sep 6, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Walnut356 commented Sep 6, 2026 •

edited by jieyouxu

Loading

jieyouxu left a comment •

edited

Loading

rust-bors Bot commented Sep 6, 2026 •

edited

Loading