[all-commits] [llvm/llvm-project] 56c4ec: [lldb][test] Add a layout simulator test for std::...

[Michael Buch via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 56c4ec92024ae9a425d29599d27885e4d45a309f
      https://github.com/llvm/llvm-project/commit/56c4ec92024ae9a425d29599d27885e4d45a309f
  Author: Michael Buch <michaelbuch12 at gmail.com>
  Date:   2024-07-16 (Tue, 16 Jul 2024)

  Changed paths:
    A lldb/packages/Python/lldbsuite/test/make/libcxx-simulators-common/compressed_pair.h
    A lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/unique_ptr/Makefile
    A lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/unique_ptr/TestDataFormatterLibcxxUniquePtrSimulator.py
    A lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx-simulators/unique_ptr/main.cpp
    M lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/string/simulator/main.cpp

  Log Message:
  -----------
  [lldb][test] Add a layout simulator test for std::unique_ptr (#98330)

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



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications