The [lldb-aarch64-windows](https://lab.llvm.org/buildbot/#/builders/141)
buildbot failed with:
```
lld-link: error: undefined symbol: printf
>>> referenced by main.o:(main)
```
I'm assuming that's because of the use of `__builtin_printf`. In other
tests, we use `printf` form `stdio.h` and these build fine, so I added
an include and used `printf`.
It seems there may be a formatter bug when there's a time zone
difference between the target machine being debugged, and the host the
debugger is running on.
This is driven by the Swift language. In Swift many data types such as
Int, and String are structs, and LLDB provides summary formatters and
synthetic child providers for them. For String, for example, a summary
formatter pulls out the string data from the implementation, while a
synthetic child provider hides the implementation details from users, so
strings don't expand their children.
rdar://171646109
Synthetic providers for collection types use a child name format of
"[N]".
This `ValueObjectSynthetic` to automatically convert child names in this
convention to the index embedded in the subscript string. With this
change, synthetic formatters for collections will only need to implement
`GetIndexOfChildWithName` or `get_child_index` for non-indexed
collection children. Some examples of non-indexed children are
`$$dereference$$` support, or "hidden" children.
The automatic conversion applies to N values that are less than the
number of children reported by the synthetic provider.
After https://github.com/llvm/llvm-project/pull/182297, we started generated `-gsimple-template-names` debug-info by default on macOS. The test was expecting template parameters in the error message. But with `simple-template-names` typenames would not contain template parameters (unless LLDB reconstructs them to do so). This formatter test was expecting template parameters, which would fail on macOS > 26.
Because the test is just concerned with checking that the `std::valarray` formatter works as expected (not that LLDB can retrieve typenames with/without template names), this patch relaxes the assertion.
In a follow-up we should fix up any type-name printing that would break with `simple-template-names`.
PR #181720 introduced shared builds for LLDB API tests to improve test
efficiency. But several data formatter tests requiring PDB debug info
are failing on Windows x64 and AArch64 platforms.
This patch disables shared builds for these tests by setting
SHARED_BUILD_TESTCASE = False
The shared build optimization breaks these tests because they reuse
build artifacts between test methods
The test runs may could use multiple methods with different debug
formats or compiler flags. When a test runs first it builds with one set
of flags, but then it runs again but **make** sees the source unchanged
so it skips rebuilding and reuses the same old binary instead of
rebuilding with correct flags.
This changes Python API tests to use a single build shared across all
test functions, instead of the previous default behavior of a separate
build dir for each test function.
This build behavior opt-out, tests can use the previous behavior of one
individual (unshared) build directory per test function, by setting
`SHARED_BUILD_TESTCASE` to False (in the test class).
The motivation is to make the test suite more efficient, by not
repeatedly building the same test source. When running tests on my macOS
machine, this reduces the time of `ninja check-lldb-api` by almost 60%
(sample numbers: from ~492s down to ~207s = 58%). Almost 5min time
saved.
Each test function still calls `self.build()`, but only the first call
will do a build, in the subsequent tests `make` will be a no-op because
the sources won't have changed.
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.
Depends on:
* https://github.com/llvm/llvm-project/pull/174385
(only last commit is relevant for this review)
The `${var%s}` format isn't capable of formatting references to
C-strings. So the summary for those becomes `<no value available>`. This
patch prevents the system C-string formatter from applying to
references, which means the summary for such types will be empty. This
prompts LLDB to instead print the child, which is the referenced
C-string.
Before:
```
(lldb) v ref
(const char *&) ref = 0x000000016fdfe960 <no value available>
```
After:
```
(lldb) v ref
(const char *&) ref = 0x000000016fdfec40 (&ref = "hi")
```
An alternative would be to support references in the `ValueObject` dump
methods. We assume C-string are pointers/arrays in a lot of places, so
such a fix would be a more intrusive undertaking, and I'm not sure we
would want to support references there in the first place. So for now I
went with the fallback logic in this PR.
Printing references to C-strings doesn't work properly at the moment. This patch provides coverage for those cases and should fail once the underlying issue gets fixed (see https://github.com/llvm/llvm-project/pull/174398).
Motivation here is that I'm planning to add more test cases to this and
it's easier to read/maintain as an API test.
Drive-by:
* I also removed the `std::string` checks since those belong in the STL
formatter tests.
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.
These no longer compile because the warning now defaults to an error
after #157364, so downgrade the error to a warning for now; I’m not
familiar enough with either LLDB or MacOS to fix these warnings properly
(assuming they’re unintended).
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
