Add debuginfo_transparent attribute for structs #144223

bjorn3 · 2025-07-20T15:09:27Z

This attribute causes the struct to be unwrapped at the debuginfo level the same way that repr(transparent) unwraps it at the ABI level. This is useful for preventing types like NonNull and Unique from making the debuginfo harder to read when pretty printers aren't used.

rustbot · 2025-07-20T15:09:31Z

r? @petrochenkov

rustbot has assigned @petrochenkov.
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-07-20T15:09:33Z

Some changes occurred in compiler/rustc_passes/src/check_attr.rs

cc @jdonszelmann

Some changes occurred in compiler/rustc_attr_data_structures

cc @jdonszelmann

Some changes occurred in compiler/rustc_attr_parsing

cc @jdonszelmann

bjorn3 · 2025-07-20T15:10:21Z

compiler/rustc_codegen_llvm/src/debuginfo/metadata.rs

    };

+    if find_attr!(cx.tcx.get_all_attrs(adt_def.did()), AttributeKind::DebuginfoTransparent(..)) {
+        let ty = struct_type_and_layout.non_1zst_field(cx).unwrap().1.ty;


Is there a way to ensure that #[debuginfo_transparent] can only be used when #[repr(transparent)] is also used? And how should I handle the case where all fields are 1zst's?

I've implemented a restriction to #[repr(transparent)] types.

bjorn3 · 2025-07-20T15:12:49Z

tests/debuginfo/strings-and-strs.rs


 // gdb-command:print plain_string
-// gdb-check:$1 = alloc::string::String {vec: alloc::vec::Vec<u8, alloc::alloc::Global> {buf: alloc::raw_vec::RawVec<u8, alloc::alloc::Global> {inner: alloc::raw_vec::RawVecInner<alloc::alloc::Global> {ptr: core::ptr::unique::Unique<u8> {pointer: core::ptr::non_null::NonNull<u8> {pointer: 0x[...]}, _marker: core::marker::PhantomData<u8>}, cap: core::num::niche_types::UsizeNoHighBit (5), alloc: alloc::alloc::Global}, _marker: core::marker::PhantomData<u8>}, len: 5}}
+// gdb-check:$1 = alloc::string::String {vec: alloc::vec::Vec<u8, alloc::alloc::Global> {buf: alloc::raw_vec::RawVec<u8, alloc::alloc::Global> {inner: alloc::raw_vec::RawVecInner<alloc::alloc::Global> {ptr: 0x[...], cap: 5, alloc: alloc::alloc::Global}, _marker: core::marker::PhantomData<u8>}, len: 5}}


This is the improvement this PR causes. Further improvements could be made using future #[debuginfo_flatten] and #[debuginfo_hidden] attributes on RawVec/RawVecInner and the _marker field, which would result in

alloc::string::String {vec: alloc::vec::Vec<u8, alloc::alloc::Global> {ptr: 0x[...], cap: 5, alloc: alloc::alloc::Global, len: 5}}

bjorn3 · 2025-07-20T15:14:52Z

src/etc/gdb_providers.py

Similar changes would need to be made for LLDB, but LLDB is broken on the dev-desktop.

rustbot · 2025-07-20T15:29:51Z

There are changes to the tidy tool.

cc @jieyouxu

petrochenkov · 2025-07-21T17:01:21Z

I don't have a strong opinion on whether this attribute should be added or not.
On one hand it duplicates functionality of gdb pretty-printers or equivalents + maybe #[debugger_visualizer], on the other hand it's clearly easier to use.

I'll delegate this to the lang team, because it approves new attributes anyway.

Also, for the implementation maybe find some other reviewer more interested in debuginfo?

bjorn3 · 2025-07-22T12:49:52Z

For the NonZero* and NonNull types it completely removes the need for the pretty-printers. I only kept their pretty-printers for backwards compatibility reasons.

rustbot · 2025-08-06T15:50:03Z

Some changes occurred in compiler/rustc_hir/src/attrs

cc @jdonszelmann

bors · 2025-08-07T02:48:41Z

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

bors · 2025-08-15T00:27:24Z

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

This attribute causes the struct to be unwrapped at the debuginfo level the same way that repr(transparent) unwraps it at the ABI level. This is useful for preventing types like NonNull and Unique from making the debuginfo harder to read when pretty printers aren't used.

rust-log-analyzer · 2025-08-15T09:00:22Z

The job tidy failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

tidy check
Checking tidy rustdoc_json...
No error code explanation was removed!
tidy: Skipping binary file check, read-only filesystem
##[error]tidy error: /checkout/compiler/rustc_feature/src/unstable.rs:463: no tracking issue for feature debuginfo_attrs
removing old virtual environment
creating virtual environment at '/checkout/obj/build/venv' using 'python3.10' and 'venv'
creating virtual environment at '/checkout/obj/build/venv' using 'python3.10' and 'virtualenv'
Requirement already satisfied: pip in ./build/venv/lib/python3.10/site-packages (25.1.1)
Collecting pip
---

added 291 packages in 34s
Running eslint on rustdoc JS files
info: ES-Check: there were no ES version matching errors!  🎉
some tidy checks failed
Command `/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-tools-bin/rust-tidy /checkout /checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo /checkout/obj/build 4 /node/bin/npm --extra-checks=py,cpp,js` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/tool.rs:1583:23
Executed at: src/bootstrap/src/core/build_steps/test.rs:1225:29

Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:02:02
  local time: Fri Aug 15 09:00:11 UTC 2025
  network time: Fri, 15 Aug 2025 09:00:11 GMT
##[error]Process completed with exit code 1.
Post job cleanup.

Walnut356 · 2025-10-19T10:55:12Z

Just a heads up, LLDB would also need a backwards compatibility fix (lldb_providers.unwrap_unique_or_non_null()). I also think there are some places that don't call that function but should, meaning they will break as well (e.g. StdStringSyntheticProvider.update() which manually traverses the inner vec and its nonnull)

Weighing in from the debug info perspective, this sort of problem is the main purpose of visualizer scripts and it seems a bit odd to cater to not using them. C++ has similar issues, they just aren't as visible because (at least for LLDB) the equivalent pretty printers and SyntheticProviders exist in the debugger itself

When using a visualizer script, you can always opt-out of individual visualizers or temporarily "look through" it to see the raw layout (for LLDB, there are display options in the CLI that disable synthetics and the python API has SBValue.GetNonSyntheticValue()). Once you generate different debug nodes though, you are losing information that cannot be recovered by the debugger.

I'm not sure how much of a priority it is for the Rust team that raw debug info to be 1:1 with the Rust representation, but I do think it's somewhat important. Other cases where nodes are generated that don't match the Rust representation (e.g. enums), the justification is hard constraints imposed by the debug info format or the debuggers rather than convenience.

With the way this is implemented, AFAICT it is impossible to tell the difference at debug-time between a NonNull pointer, a Unique pointer, and a raw pointer since it inherits the full DI node. Also, any formatters, summaries, or synthetics applied to one will always be applied to the other. Wrapping the inherited DI node in a typedef might be a good middleground, as debuggers will "look through" the typedef when displaying the value, and inheriting formatters/summaries/synthetics can be opt-ed out

(lldb) help type synthetic add
Add a new synthetic provider for a type.

Syntax: type synthetic add <cmd-options> <name> [<name> [...]]
...
    -C <boolean> ( --cascade <boolean> )
            If true, cascade through typedef chains.
...

rustbot assigned petrochenkov Jul 20, 2025

bjorn3 commented Jul 20, 2025

View reviewed changes

src/etc/gdb_providers.py

Copy link

Member Author

bjorn3 Jul 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar changes would need to be made for LLDB, but LLDB is broken on the dev-desktop.