[libcxx-commits] [libcxx] [libc++] Replace `__compressed_pair` with `[[no_unique_address]]` (PR #76756)

[Michael Buch via libcxx-commits]

Michael137 wrote:

> I am looking into this on our end. While I don't have an exact reproducer (yet), I can provide some details. Basically I think we're dealing with two problems:
> 
> 1. lldb thinks that `alignof(std::string)` is one -- in the unstable ABI at least. This is the bit that is changed by this patch, and it causes issues when computing layouts of structs (containing strings). I don't know why that happens, though I seem to remember some mentions of "packed" structs on the no_unique_address patches. AFAICT, this happens for any compiler flag combination.
> 2. lldb ignores DW_AT_member_offset for (some?) structs. Normally going by unnoticed, this issue significantly increases the blast radius of the previous bug. _This_ part is triggered by -flimit-debug-info, and it occurs when lldb parses the type (the one which has std::string as a member) from a non-defining declaration (this probably also means that our changes to delay definition searching are implicated). From what I can tell, this happens because lldb causes a type to be laid out before it computes its (DWARF-driven) layout. This happens due to this line [here](https://github.com/llvm/llvm-project/blob/41145feb77ddcb90b6628e3d11eea69e1ecf71c2/lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp#L2132), which triggers a recursive attempt to complete the type. Indeed, deleting that line makes the class layout come out right (despite the first bug), but:
> 
> * I don't understand the full impact of doing that, or how this could have ever worked
> * it breaks one other test (Shell/SymbolFile/DWARF/x86/DW_AT_declaration-with-children.s) -- probably by exposing some other bug. I haven't looked into that yet, though I think/hope this should be fairly easy to fix.

Thanks for the details! Regarding (1), i think you might be running into: https://github.com/llvm/llvm-project/pull/97443. Which was causing issues for the `std::map`/`std::unordered_map` formatters (which used to synthesize new Clang types and incorrectly calculate the `FieldOffsets` into those types) until that was fixed in https://github.com/llvm/llvm-project/pull/97579. Is this happening for some of your internal formatters perhaps?

https://github.com/llvm/llvm-project/pull/76756