Ran my python script from
https://github.com/llvm/llvm-project/pull/97043 over the repo again and
there were 2 duplicate test-cases that have been introduced since I last
did this.
Also one of the WASM classes had a duplicate method which I just
removed.
When using `std::variant` with non-trivial types, we need to go through
multiple bases to find the `_Which` member. The MSVC STL implements this
in `xsmf_control.h` which conditionally adds/deletes copy/move
constructors/operators.
We now go to `_Variant_base` (the holder of `_Which`). This inherits
from `_Variant_storage`, which is our entry point to finding the n-th
storage (going through `_Tail`).
Similar to the other PRs, this looks up the type from a member variable.
Here, we can use the type of `_Mapptr`. On its own, that's enough to
pass the test with clang-cl.
`std::span` didn't have a formatter for MSVC's STL yet. The type is
quite useful in C++ 20, so this PR adds a formatter for it.
Since the formatter is new, I made it work with both DWARF and PDB from
the start.
The unordered containers re-use the formatters for `std::list` which
were fixed for PDB with #166953.
This should be the last fix for PDB in MSVC STL tests. Unfortunately,
the type names here are very long, because the types of keys/values are
repeated in the template (for hash/eq/allocator).
Because PDB doesn't know about templates, we need to get to `T` of
`std::atomic<T>` differently. The type includes the `value_type`
typedef, which is always equal to `T`. The native PDB plugin includes
this since #169248.
Then we can run the `std::atomic` test with (native) PDB.
Split off from #171489. This only adds the lookup of the active type for
a `std::variant` based on the head type (since PDB doesn't have template
info).
Similar to the other PRs, this runs the `std::optional` test with PDB.
Since we don't know that variables use typedefs, we check for the full
name when testing PDB.
Since PDB doesn't have template information, we need to get the element
type from somewhere else. I'm using the type of `_Myval` in a list node,
which holds the element type.
Runs the `std::shared/unique_ptr` tests with PDB with two changes:
- PDB uses the "full" name, so `std::string` is `std::basic_string<char,
std::char_traits<char>, std::allocator<char>>`
- The type of the pointer inside the shared/unique_ptr isn't the
`element_type` typedef
The test was added in #147252. On a 32-bit target, it fails with error:
```
File "...\TestDataFormatterLibcxxInvalidString.py", line 23, in test
self.skip()
^^^^^^^^^
AttributeError: 'LibcxxInvalidStringDataFormatterTestCase' object has no attribute 'skip'
```
PDB doesn't include the typedefs for types, so all types use their full
name. For `std::string` and friends, this means they show up as
`std::basic_string<char, std::char_traits<char>, std::allocator<char>>`.
This PR updates the `std::{,w,u8,u16,u32}string(_view)` tests to account
for this and runs them with PDB.
This enables testing with PDB for all tests that don't require any
changes to pass. I ran the
`lldb/test/API/functionalities/data-formatter/data-formatter-stl/generic`
tests locally and they passed.
From
https://github.com/llvm/llvm-project/pull/163077#issuecomment-3396435083:
Currently, `std::atomic<T>` will always use the MSVC STL synthetic
children and summary. When inspecting types from other STLs, the output
would not show any children.
This PR adds a check that `std::atomic` contains `_Storage` to be
classified as coming from MSVC's STL.
This came up in https://github.com/llvm/llvm-project/issues/155691.
For `std::basic_string` our formatter matching logic required the
allocator template parameter to be a `std::allocator`. There is no
compelling reason (that I know of) why this would be required for us to
apply the existing formatter to the string. We don't check the
`allocator` parameter for other STL containers either. This meant that
`std::string` that used custom allocators wouldn't be formatted. This
patch relaxes the regex for `basic_string`.
The LLVM Style Guide says the following about error and warning messages
[1]:
> [T]o match error message styles commonly produced by other tools,
> start the first sentence with a lowercase letter, and finish the last
> sentence without a period, if it would end in one otherwise.
I often provide this feedback during code review, but we still have a
bunch of places where we have inconsistent error message, which bothers
me as a user. This PR identifies a handful of those places and updates
the messages to be consistent.
[1] https://llvm.org/docs/CodingStandards.html#error-and-warning-messages
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.
This is a major change on how we represent nested name qualifications in
the AST.
* The nested name specifier itself and how it's stored is changed. The
prefixes for types are handled within the type hierarchy, which makes
canonicalization for them super cheap, no memory allocation required.
Also translating a type into nested name specifier form becomes a no-op.
An identifier is stored as a DependentNameType. The nested name
specifier gains a lightweight handle class, to be used instead of
passing around pointers, which is similar to what is implemented for
TemplateName. There is still one free bit available, and this handle can
be used within a PointerUnion and PointerIntPair, which should keep
bit-packing aficionados happy.
* The ElaboratedType node is removed, all type nodes in which it could
previously apply to can now store the elaborated keyword and name
qualifier, tail allocating when present.
* TagTypes can now point to the exact declaration found when producing
these, as opposed to the previous situation of there only existing one
TagType per entity. This increases the amount of type sugar retained,
and can have several applications, for example in tracking module
ownership, and other tools which care about source file origins, such as
IWYU. These TagTypes are lazily allocated, in order to limit the
increase in AST size.
This patch offers a great performance benefit.
It greatly improves compilation time for
[stdexec](https://github.com/NVIDIA/stdexec). For one datapoint, for
`test_on2.cpp` in that project, which is the slowest compiling test,
this patch improves `-c` compilation time by about 7.2%, with the
`-fsyntax-only` improvement being at ~12%.
This has great results on compile-time-tracker as well:
This patch also further enables other optimziations in the future, and
will reduce the performance impact of template specialization resugaring
when that lands.
It has some other miscelaneous drive-by fixes.
About the review: Yes the patch is huge, sorry about that. Part of the
reason is that I started by the nested name specifier part, before the
ElaboratedType part, but that had a huge performance downside, as
ElaboratedType is a big performance hog. I didn't have the steam to go
back and change the patch after the fact.
There is also a lot of internal API changes, and it made sense to remove
ElaboratedType in one go, versus removing it from one type at a time, as
that would present much more churn to the users. Also, the nested name
specifier having a different API avoids missing changes related to how
prefixes work now, which could make existing code compile but not work.
How to review: The important changes are all in
`clang/include/clang/AST` and `clang/lib/AST`, with also important
changes in `clang/lib/Sema/TreeTransform.h`.
The rest and bulk of the changes are mostly consequences of the changes
in API.
PS: TagType::getDecl is renamed to `getOriginalDecl` in this patch, just
for easier to rebasing. I plan to rename it back after this lands.
Fixes#136624
Fixes https://github.com/llvm/llvm-project/issues/43179
Fixes https://github.com/llvm/llvm-project/issues/68670
Fixes https://github.com/llvm/llvm-project/issues/92757
This PR adds synthetic children for std::deque from MSVC's STL.
Similar to libstdc++ and libc++, the elements are in a `T**`, so we need
to "subscript" twice. The [NatVis for
deque](313964b78a/stl/debugger/STL.natvis (L1103-L1112))
uses `_EEN_DS` which contains the block size. We can't access this, but
we can access the [constexpr
`_Block_size`](313964b78a/stl/inc/deque (L641)).
Towards #24834.
This PR adds formatters for `std::map`, `std::set`, `std::multimap`,
`std::multiset` as well as their iterators. It's done in one PR because
the types are essentially the same (a tree) except for their value type.
The iterators are required because of the tests.
`MsvcStlTreeIterSyntheticFrontEnd` is based on the libc++ equivalent. As
opposed to `std::list`, there aren't that many duplicates, so I didn't
create a generic type.
For reference, the tree is implemented in
313964b78a/stl/inc/xtree.
Towards #24834.
Adds synthetic children and a summary provider for `std::atomic` on
MSVC's STL. This currently only supports DWARF because it relies on the
template argument. Once there are PDB tests, this will probably use the
return type of some method like `value()` because template types aren't
available there.
Towards #24834.
Adds a summary and synthetic children for MSVC STL's `std::variant`.
This one is a bit complicated because of DWARF vs PDB differences. I put
the representations in comments. Being able to `GetChildMemberWithName`
a member in an anonymous union would make this a lot simpler
(`std::optional` will have something similar iirc).
Towards #24834.
Adds synthetic providers for MSVC's `std::forward_list` and `std::list`.
It refactors `LibCxxList` to be generic over the STL type (currently
libc++ or MSVC STL). The libstdc++ synthetic providers use something
similar in Python
[here](3092b765ba/lldb/examples/synthetic/gnu_libstdcpp.py (L134)).
Eventually, this could be ported to C++ as well.
Towards #24834.
This adds synthetic child providers for `std::vector<T>` and
`std::vector<bool>` for MSVC's STL.
The structure of a `std::vector<T>` is relatively similar to libc++'s
implementation that uses `__begin` and `__end`.
`std::vector<bool>` is different. It's a `std::vector<unsigned int>`
wrapper instead of `std::vector<uint8_t>`. This makes the calculation
slightly less simple. I put a comment in the `GetChildAtIndex` to make
this clear.
- [NatVis for
`std::vector<T>`](313964b78a/stl/debugger/STL.natvis (L1193-L1205))
- [NatVis for
`std::vector<bool>`](313964b78a/stl/debugger/STL.natvis (L1167-L1179))
Towards #24834.
Adds synthetic children for MSVC STL's
[`std::tuple`](313964b78a/stl/inc/tuple).
A `tuple` is a chain of base classes:
```cpp
template <>
class tuple<> {};
template <class _This, class... _Rest>
class tuple<_This, _Rest...> : private tuple<_Rest...> {
_Tuple_val<_This> _Myfirst;
};
```
So the provider walks the base classes to the desired one.
The implementation makes it hard to detect if the empty tuple is from
this STL. Fortunately, libstdc++'s synthetic children provider works for
empty MSVC STL tuples as well.
Towards #24834.
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?)
