This PR adds a summary and synthetic children for `std::unique_ptr` from
MSVC's STL
([NatVis](313964b78a/stl/debugger/STL.natvis (L285-L303))).
As with libc++, the deleter is only shown if it's non-empty.
Tested both the shared_ptr and unique_ptr tests on Windows.
Towards #24834.
This PR adds formatters for `std::shared_ptr` and `std::weak_ptr`. They
are similar to the ones from libc++ and libstdc++.
[Section from MSVC STL
NatVis](313964b78a/stl/debugger/STL.natvis (L512-L578)).
To support debugging with PDB debug info, I had to add an early exit in
`GetDesugaredSmartPointerValue`, because with PDB, LLDB doesn't know
about template types. This isn't an issue here, since the typedef type
is already resolved there, so no casting is needed.
The tests don't check for PDB - maybe this should be changed? I don't
know a good way to do this. PDB has the downside that it resolves
typedefs. Here in particular, the test for `element_type` would need to
be replaced with `User` and `std::string` with
`std::basic_string<char,std::char_traits<char>,std::allocator<char> >`.
Towards #24834.
This combines the libc++ and libstdc++ test cases. The libstdcpp tests
were a subset of the libc++ test, so this patch moves the libcxx test
into generic and removes the libstdcpp test entirely.
There are currently no formatters for libstdcpp
std::unorderd_map::iterator. So I removed those test-cases. We already
test them for libc++ in `libcxx/unordered_map-iterator`. And we test
`std::unordered_map` in `generic/unorderd`. So these test-cases would be
redundant.
Split out from https://github.com/llvm/llvm-project/pull/146740
This just moves the test from `libcxx` to `generic`. There are currently
no `std::function` formatters for libstdc++ so I didn't add a test-case
for it.
Split out from https://github.com/llvm/llvm-project/pull/146740
This just moves the test from `libcxx` to `generic`. There are currently
no `std::initializer_list` formatters for libstdc++ so I didn't add a
test-case for it.
Split out from https://github.com/llvm/llvm-project/pull/146740
This just moves the test from `libcxx` to `generic`. There are currently
no `std::ranges::ref_view` formatters for libstdc++ so I didn't add a
test-case for it.
Split out from https://github.com/llvm/llvm-project/pull/146740
Now that most STL formatter tests have been moved to `generic`. Do the
same for the MSVC tests (which are currently just for `std::string`).
The `std::string` test was mostly the same (MSVC just had 1 additional
check, which I moved over).
We also only tested `u8string` with MSVC. So i moved those into
`generic` as-is. I kept it separate from the existing std::string tests
since it requires c++20.
The tests are currently failing for libc++ and libstdc++ because MSVC
had a test case which checked that:
```
std::string overwritten_zero("abc");
const_cast<char *>(overwritten_zero.data())[3] = 'd';
```
prints as `"abc"`. But libc++ and libstdc++ print it as `"abcd"` (which
seems like the more correct thing to do?)
This just moves the test from `libcxx` to `generic`. There are currently
no `std::valarray` formatters for libstdc++ so I didn't add a test-case
for it.
Split out from https://github.com/llvm/llvm-project/pull/146740
… directory
This just moves the test from `libcxx` to `generic`. There are currently
no `std::unordered_map::iterator` formatters for libstdc++ so I didn't
add a test-case for it.
Split out from https://github.com/llvm/llvm-project/pull/146740
This just moves the test from `libcxx` to `generic`. There are currently
no `std::span` formatters for libstdc++ so I didn't add a test-case for
it.
Split out from https://github.com/llvm/llvm-project/pull/146740
This just moves the test from `libcxx` to `generic`. There are currently
no `std::string_view` formatters for libstdc++ so I didn't add a
test-case for it.
Split out from https://github.com/llvm/llvm-project/pull/146740
This just moves the test from `libcxx` to `generic`. There are currently
no `std::queue` formatters for libstdc++ so I didn't add a test-case for
it.
Split out from https://github.com/llvm/llvm-project/pull/146740
Follow-up to
https://github.com/llvm/llvm-project/pull/147165#pullrequestreview-2992585513
Currently when we explicitly dereference a std::shared_ptr, both the
libstdc++ and libc++ formatters will cast the type of the synthetic
pointer child to whatever the `std::shared_ptr::element_type` is aliased
to. E.g.,
```
(lldb) v p
(std::shared_ptr<int>) p = 10 strong=1 weak=0 {
pointer = 0x000000010016c6a0
}
(lldb) v *p
(int) *p = 10
```
However, when we print (or dereference) `p.pointer`, the type devolves
to something less user-friendly:
```
(lldb) v p.pointer
(std::shared_ptr<int>::element_type *) p.pointer = 0x000000010016c6a0
(lldb) v *p.pointer
(std::shared_ptr<int>::element_type) *p.pointer = 10
```
This patch changes both formatters to store the casted type. Then
`GetChildAtIndex` will consistently use the unwrapped type.
This combines the libc++ and libstdc++ test cases. The main difference
was that the libstdcpp tests had additional tests for
references/pointers to std::string. I moved those over.
The libstdc++ formatters don't support `std::u16string`/`std::u32string`
yet, so I extracted those into XFAILed test cases.
There were also two test assertions that failed for libstdc++:
1. libstdc++ doesn't obey the capped/uncapped summary options
2. When a summary isn't available for a std::string, libc++ would print
"Summary Unavailable", whereas libstdc++ just prints "((null))". This
may be better suited for the STL-specific subdirectories, but left it
here for now.
I put those in separate XFAILed test-cases.
Split out from https://github.com/llvm/llvm-project/pull/146740
This combines the libc++ and libstdc++ test cases. The libstdc++ test
had an additional test-case for "reference to typedef". So I added those
to the generic test. The rest of the tests was the same as libc++.
I also moved the test-case for checking invalid variant indexes into a
separate libstdcpp test because it relied on the layout of the libstdc++
type. We should probably rewrite it in the "simulator" style. But for
now I just moved it.
This also removes some redundant checks for libc++ versions and
existence of the `variant` header, which at this point should be
available anywhere these tests are run.
Split out from https://github.com/llvm/llvm-project/pull/146740
This PR adds type summaries for
`std::{string,wstring,u8string,u16string,u32string}` from the MSVC STL.
See https://github.com/llvm/llvm-project/issues/24834 for the MSVC STL
issue.
The following changes were made:
- `dotest.py` now detects if the MSVC STL is available. It does so by
looking at the target triple, which is an additional argument passed
from Lit. It specifically checks for `windows-msvc` to not match on
`windows-gnu` (i.e. MinGW/Cygwin).
- (The main part): Added support for summarizing `std::(w)string` from
MSVC's STL. Because the type names from the libstdc++ (pre C++ 11)
string types are the same as on MSVC's STL, `CXXCompositeSummaryFormat`
is used with two entries, one for MSVC's STL and one for libstdc++.
With MSVC's STL, `std::u{8,16,32}string` is also handled. These aren't
handled for libstdc++, so I put them in `LoadMsvcStlFormatters`.
This combines the libc++ and libstdc++ test cases. The main difference
was that the libstdcpp tests had some tuple indexing tests that libc++
didn't have.
The libstdc++ formatter didn't support size summaries for std::tuple. So
I added a `ContainerSizeSummaryProvider` for it (like we do for libc++).
Additionally, the synthetic frontend would only apply to non-empty
tuples, so I adjusted the regex to match empty ones too. We do this for
libc++ already.
Split out from https://github.com/llvm/llvm-project/pull/146740
This combines the libc++ and libstdc++ test cases. The libstdcpp tests
were a subset of the libc++ test, so this patch moves the libcxx test
into `generic` and removes the libstdcpp test entirely.
Split out from https://github.com/llvm/llvm-project/pull/146740
As a pre-requisite to combine the libcxx and libstdcxx string formatter
tests (see https://github.com/llvm/llvm-project/pull/146740) this patch
splits out the libcxx specific parts into a separate test.
These are probably best tested with the libcxx-simulator tests. But for
now I just moved them.
The libc++ test was a subset of the tests in libstdc++. This test moves
the libc++ test into `generic` and somne additional test-cases from
`libstdc++` (specifically the recursive unique_ptr case). It turns out
the libstdc++ formatter supports dereferencing using the "object" or
"obj" names. We could either drop those from the tests or support the
same for libc++. I took the latter approach but don't have strong
opinions on this.
Split out from https://github.com/llvm/llvm-project/pull/146740
This combines the libc++ and libstdc++ test cases. The libstdcpp tests
were a subset of the libc++ test, so this patch moves the libcxx test
into generic and removes the libstdcpp test entirely.
Split out from https://github.com/llvm/llvm-project/pull/146740
This patch adjusts the libcxx and libstdcxx std::shared_ptr formatters
to look the same.
Changes to libcxx:
* Now creates a synthetic child called `pointer` (like we already do for
`std::unique_ptr`)
Changes to libstdcxx:
* When asked to dereference the pointer, cast the type of the result
ValueObject to the element type (which we get from the template argument
to std::shared_ptr).
Before:
```
(std::__shared_ptr<int, __gnu_cxx::_S_atomic>::element_type) *foo = 123
```
After:
```
(int) *foo = 123
```
Tested in https://github.com/llvm/llvm-project/pull/147141
The libc++ and libstdc++ tests were pretty much an exact copy of each
other. This test moves the libc++ test into generic removes it from
libstdc++. I moved the `GLIBCXX_DEBUG` case over from libstdcxx. For
some reason the libstdcxx test was skipped, but it passes on my Linux
machine. So I unskipped it for now.
Split out from https://github.com/llvm/llvm-project/pull/146740
The only difference is that with libc++ the summary string contains the
derefernced pointer value. With libstdc++ we currently display the
pointer itself, which seems redundant. E.g.,
```
(std::unique_ptr<int>) iup = 0x55555556d2b0 {
pointer = 0x000055555556d2b0
}
(std::unique_ptr<std::basic_string<char> >) sup = 0x55555556d2d0 {
pointer = "foobar"
}
```
This patch moves the logic into a common helper that's shared between
the libc++ and libstdc++ formatters.
After this patch we can combine the libc++ and libstdc++ API tests (see
https://github.com/llvm/llvm-project/pull/146740).
The libstdc++ test was a subset of the tests in libc++. This test moves
the libc++ test into `generic` and removes the `libstdc++` tests. I
retained the `-D_GLIBCXX_DEBUG` test cases though.
Split out from https://github.com/llvm/llvm-project/pull/146740
Previously the parameter wasn't respected. So we would only run the test
with whatever stdlib the `Makefile.rules` deduced.
Confirmed that
```
lldb-dotest -p TestDataFormatterGenericSet.py --category libstdcxx
```
passes on my machine.
The plan is to move all STL formatter API tests into a single directory.
The `std::deque` test is currently the only test that is duplicated
between the `libcxx` and `generic` directories. This patch moves the
libcxx deque tests into `generic` (moving over any functionality that
wasn't tested in the `generic` tests, mainly formatting
pointers/references to `std::deque`).
The actual `unordered_map` tests live in
`data-formatter-stl/generic/unordered`. The tests here are only testing
`std::unordered_map::iterator`. This patch renames the directory
accordingly. This is in preparation for moving all of the STL tests into
the `generic` directory.
This updates the DIL implementation to handle smart pointers (accessing
field members and dereferencing) in the same way the current 'frame
variable' implementation does. It also adds tests for handling smart
pointers, as well as some additional DIL tests.
Desugar any potential references/typedefs before checking
`isStdTemplate`. Previously, the typename might've been:
```
const std::unordered_map<...> &
```
for references. This patch gets the pointee type before grabbing the
canonical type. `GetNonReferenceType` will unwrap typedefs too, so we
should always end up with a non-reference before we get to
`GetCanonicalType`.
https://github.com/llvm/llvm-project/issues/145847
As part of https://github.com/llvm/llvm-project/pull/143177, I moved the
non-libc++ specific formatting of `std::string`s out to `CxxStringTypes`
as MSVC's STL `std::string` can also be thought of a pointer+size pair.
I named this kind of string "string buffer".
This PR picks that change, so the MSVC PR can be smaller.
Unfortunately, libstdc++'s `std::string` does not fit this (it also uses
a different string printer function).
This resolves two FIXMEs in the libc++ tests, where empty u16 and u32
strings didn't have any prefix (u/U).
This commit adjusts the pretty printer for `std::coroutine_handle` based
on recent personal experiences with debugging C++20 coroutines:
1. It adds the `coro_frame` member. This member exposes the complete
coroutine frame contents, including the suspension point id and all
internal variables which the compiler decided to persist into the
coroutine frame. While this data is highly compiler-specific, inspecting
it can help identify the internal state of suspended coroutines.
2. It includes the `promise` and `coro_frame` members, even if
devirtualization failed and we could not infer the promise type / the
coro_frame type. Having them available as `void*` pointers can still be
useful to identify, e.g., which two coroutine handles have the same
frame / promise pointers.
So far, the `DW_AT_linkage_name` of the coroutine `resume`, `destroy`,
`cleanup` and `noalloc` function clones were incorrectly set to the
original function name instead of the updated function names.
With this commit, we now update the `DW_AT_linkage_name` to the correct
name. This has multiple benefits:
1. it's easier for me (and other toolchain developers) to understand the
output of `llvm-dwarf-dump` when coroutines are involved.
2. When hitting a breakpoint, both LLDB and GDB now tell you which clone
of the function you are in. E.g., GDB now prints "Breakpoint 1.2,
coro_func(int) [clone .resume] (v=43) at ..." instead of "Breakpoint
1.2, coro_func(int) (v=43) at ...".
3. GDB's `info line coro_func` command now allows you to distinguish the
multiple different clones of the function.
In Swift, the linkage names of the clones were already updated. The
comment right above the relevant code in `CoroSplit.cpp` already hinted
that the linkage name should probably also be updated in C++. This
comment was added in commit 6ce76ff7eb7640, and back then the
corresponding `DW_AT_specification` (i.e., `SP->getDeclaration()`) was
not updated, yet, which led to problems for C++. In the meantime, commit
ca1a5b37c7236d added code to also update `SP->getDeclaration`, as such
there is no reason anymore to not update the linkage name for C++.
Note that most test cases used inconsistent function names for the LLVM
function vs. the DISubprogram linkage name. clang would never emit such
LLVM IR. This confused me initially, and hence I fixed it while updating
the test case.
Drive-by fix: The change in `CGVTables.cpp` is purely stylistic, NFC.
When looking for other usages of `replaceWithDistinct`, I got initially
confused because `CGVTables.cpp` was calling a static function via an
object instance.
after PR 138209 stopped applying data formatters
for T** by default, and this test expects that to
work. We'll need to figure out if we want to drop
this test, or adapt NSError/other objc formatters to
descend an extra level or two of depth.
Currently, the type `T`'s summary formatter will be matched for `T`,
`T*`, `T**` and so on. This is unexpected in many data formatters. Such
unhandled cases could cause the data formatter to crash. An example
would be the lldb's built-in data formatter for `std::optional`:
```
$ cat main.cpp
#include <optional>
int main() {
std::optional<int> o_null;
auto po_null = &o_null;
auto ppo_null = &po_null;
auto pppo_null = &ppo_null;
return 0;
}
$ clang++ -g main.cpp && lldb -o "b 8" -o "r" -o "v pppo_null"
[lldb crash]
```
This change adds an options `--pointer-match-depth` to `type summary
add` command to allow users to specify how many layer of pointers can be
dereferenced at most when matching a summary formatter of type `T`, as
Jim suggested
[here](https://github.com/llvm/llvm-project/pull/124048/#issuecomment-2611164133).
By default, this option has value 1 which means summary formatter for
`T` could also be used for `T*` but not `T**` nor beyond. This option is
no-op when `--skip-pointers` is set as well.
I didn't add such option for `type synthetic add`, `type format add`,
`type filter add`, because it useful for those command. Instead, they
all have the pointer match depth of 1. When printing a type `T*`, lldb
never print the children of `T` even if there is a synthetic formatter
registered for `T`.
The architectures provided to skipIf / expectedFail are regular
expressions (v. _match_decorator_property() in decorators.py
so on Darwin systems "arm64" would match the skips for "arm" (32-bit
Linux). Update these to "arm$" to prevent this, and also update
three tests (TestBuiltinFormats.py, TestCrossDSOTailCalls.py,
TestCrossObjectTailCalls.py) that were skipped for arm64 via this
behavior, and need to be skipped or they will fail.
This was moviated by the new TestDynamicValue.py test which has
an expected-fail for arm, but the test was passing on arm64 Darwin
resulting in failure for the CIs.
If libstdc++ is compiled with `_GLIBCXX_DEBUG` flag it puts the containers in the namespace `std::__debug`. this causes the summary and synthetic formatters not to match the types. The formatters is updated to optionally match the `__debug::`.
The formatters now clashed with the libc++ containers namespace regex which uses `std::__1` namespace
The libc++ formatter is loaded first, then the libstdc++ since the priority of the formatters in lldb is the last one added.
Fixes#60841
This is still leftover from the days when the libc++ and libstdc++
formatters were both written in python and in separate categories. Since
then we group libstdc++ and libc++ formatters into the same cateogry.
This patch removes references to the obsolete `gnu-libstdc++` category
from the docs (and a test).
See [this
thread](https://github.com/llvm/llvm-project/pull/140761#discussion_r2102386080)
for more context
Change the default from 256 to 24. The argument is that 256 is too large to be scanned
by eye, and too large to print in a terminal which can be only 40-50 lines in height.
When all children must be shown, `frame variable` and `expression` both support the `-A`
(`--show-all-children`) flag.
rdar://145327522
