Starting with https://github.com/llvm/llvm-project/pull/154686 the
compressed_pair children are now wrapped in an anonymous structure.
This patch adjusts the LLDB data-formatters to support that.
Outstanding questions:
1. Should GetChildMemberWithName look through anonymous structures? That
will break users most likely. But maybe introducing a new API is worth
it? Then we wouldnt have to do this awkward passing around of
`anon_struct_index`
2. Do we support the layout without the anonymous structure? It's not
too much added complexity. And we did release that version of libc++, so
there is code out there compiled against it. But there is no great way
of testing it (some of our macOS matrix bots do test it i suppose, but
not in a targeted way). We have the layout "simulator" tests for some of
the STL types which I will adjust.
Relands https://github.com/llvm/llvm-project/pull/108375 which had to be
reverted because it was failing on the Windows buildbot. Trying to
reland this with `msvc::no_unique_address` on Windows.
This is motivated by the upcoming refactor of libc++'s
`__compressed_pair` in https://github.com/llvm/llvm-project/pull/76756
As this will require changes to numerous LLDB libc++ data-formatters
(see early draft https://github.com/llvm/llvm-project/pull/96538), it
would be nice to have a test-suite that will actually exercise both the
old and new layout. We have a matrix bot that tests old versions of
Clang (but currently those only date back to Clang-15). Having them in
the test-suite will give us quicker signal on what broke.
We have an existing test that exercises various layouts of `std::string`
over time in `TestDataFormatterLibcxxStringSimulator.py`, but that's the
only STL type we have it for. This patch proposes a new
`libcxx-simulators` directory which will take the same approach for all
the STL types that we can feasibly support in this way (as @labath
points out, for some types this might just not be possible due to their
implementation complexity). Nonetheless, it'd be great to have a record
of how the layout of libc++ types changed over time.
Some related discussion:
*
https://github.com/llvm/llvm-project/pull/97568#issuecomment-2213426804
