Change `lldbtest.expect` to require the regexes in `patterns` be found in order – when the
`ordered` parameter is true. This matches the behavior of `substrs`.
The `ordered` parameter is true by default, so this change also fixes tests by either
tweaking the patterns to work in order, or by setting `ordered=False`.
I have often wanted to test with `patterns` and also verify the order. This change
allows that.
There was a bug in both the GNU and libc++ library synthetic child
providers when a typedef was used in the type of the variable. Previous
code was looking at the top level typename to try and determine if
std::unordered_ was a map or set and this failed when typedefs were
being used. This patch fixes both C++ library synthetic child providers
with updated tests.
A Clang change introduced in this version breaks this test. Said
change was reverted in `52a9ba7ca4fb9427706c28bb3ca15f7a56eecf3f`
in newer versions of Clang.
Follow-up to the LLDB std::optional data-formatter test failure caused
by https://github.com/llvm/llvm-project/pull/110355.
Two formats are supported:
1. `__val_` has type `value_type`
2. `__val_`'s type is wrapped in `std::remove_cv_t`
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 reverts commit d5f6e886ff.
Caused failure on Windows CI. Following test failed:
```
Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe
======================================================================
FAIL: test_r5_c2_ALTERNATE_LAYOUT (TestDataFormatterLibcxxStringSimulator.LibcxxStringDataFormatterSimulatorTestCase.test_r5_c2_ALTERNATE_LAYOUT)
partial(func, *args, **keywords) - new function with partial application
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\functionalities\data-formatter\data-formatter-stl\libcxx-simulators\string\TestDataFormatterLibcxxStringSimulator.py", line 23, in _run_test
self.expect_var_path("longstring", summary='"I am a very long string"')
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2552, in expect_var_path
value_check.check_value(self, eval_result, str(eval_result))
File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 321, in check_value
test_base.assertEqual(
AssertionError: '"I am a very long string"' != '""'
- "I am a very long string"
+ ""
: (std::__lldb::string) longstring = ""
Checking SBValue: (std::__lldb::string) longstring = ""
```
We may need to use `msvc::no_unique_address` around the simulators.
This patch is in preparation for the `__compressed_pair` refactor in
https://github.com/llvm/llvm-project/pull/76756.
This is mostly reviewable now. With the new layout we no longer need to
unwrap the `__compressed_pair`. Instead, we just need to look for child
members. E.g., to get to the underlying pointer of `std::unique_ptr` we
no longer do,
```
GetFirstValueOfCXXCompressedPair(GetChildMemberWithName("__ptr_"))
```
but instead do
```
GetChildMemberWithName("__ptr_")
```
We need to be slightly careful because previously the
`__compressed_pair` had a member called `__value_`, whereas now
`__value_` might be a member of the class that used to hold the
`__compressed_pair`. So before unwrapping the pair, we added checks for
`isOldCompressedLayout` (not sure yet whether folding this check into
`GetFirstValueOfCXXCompressedPair` is better).
IIUC, the history of `std::string`'s `__short` structure in the
alternate ABI layout (as recorded by the simulator test) looks as
follows:
* First layout ( `SUBCLASS_PADDING` is defined):
```
struct __short
{
value_type __data_[__min_cap];
struct
: __padding<value_type>
{
unsigned char __size_;
};
};
```
* Then:
```
struct __short
{
value_type __data_[__min_cap];
unsigned char __padding[sizeof(value_type) - 1];
unsigned char __size_;
};
```
* Then, post-`BITMASKS`:
```
struct __short
{
value_type __data_[__min_cap];
unsigned char __padding[sizeof(value_type) - 1];
unsigned char __size_ : 7;
unsigned char __is_long_ : 1;
};
```
Which is the one that's [on
top-of-tree](89c10e27d8/libcxx/include/string (L854-L859)).
But for `REVISION > 1`, `BITMASKS` is never set, so for those tests we
lose the `__padding` member.
This patch fixes this by splitting out the `SUBCLASS_PADDING` out of the
ifdef.
Drive-by:
* Also run expression evaluator on the string to provide is with some
extra coverage.
TargetProperties.td had a few settings listed as signed integral values,
but the Target.cpp methods reading those values were reading them as
unsigned. e.g. target.max-memory-read-size, some accesses of
target.max-children-count, still today, previously
target.max-string-summary-length.
After Jonas' change to use templates to read these values in
https://reviews.llvm.org/D149774, when the code tried to fetch these
values, we'd eventually end up calling OptionValue::GetAsUInt64 which
checks that the value is actually a UInt64 before returning it; finding
that it was an SInt64, it would drop the user setting and return the
default value. This manifested as a bug that target.max-memory-read-size
is never used for memory read.
target.max-children-count is less straightforward, where one read of
that setting was fetching it as an int64_t, the other as a uint64_t.
I suspect all of these settings were originally marked as SInt64 so a
user could do -1 for "infinite", getting it static_cast to a UINT64_MAX
value along the way. I can't find any documentation for this behavior,
but it seems like something Greg would have done. We've partially lost
that behavior already via
https://github.com/llvm/llvm-project/pull/72233 for
target.max-string-summary-length, and this further removes it.
We're still fetching UInt64's and returning them as uint32_t's but I'm
not overly pressed about someone setting a count/size limit over 4GB.
I added a simple API test for the memory read setting limit.
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
Depends on https://github.com/llvm/llvm-project/pull/97687
Similar to https://github.com/llvm/llvm-project/pull/97579, this patch
simplifies the way in which we retrieve the key/value pair of a
`std::map` (in this case of the `std::map::iterator`).
We do this for the same reason: not only was the old logic hard to
follow, and encoded the libc++ layout in non-obvious ways, it was also
fragile to alignment miscalculations
(https://github.com/llvm/llvm-project/pull/97443); this would break once
the new layout of std::map landed as part of
https://github.com/llvm/llvm-project/issues/93069.
Instead, this patch simply casts the `__iter_pointer` to the
`__node_pointer` and uses a straightforward
`GetChildMemberWithName("__value_")` to get to the key/value we care
about.
We can eventually re-use the core-part of the `std::map` and
`std::map::iterator` formatters. But it will be an easier to change to
review once both simplifications landed.
Depends on https://github.com/llvm/llvm-project/pull/97752
This patch changes the way we retrieve the key/value pair in the
`std::unordered_map::iterator` formatter (similar to how we are changing
it for `std::map::iterator` in
https://github.com/llvm/llvm-project/pull/97713, the motivations being
the same).
The old logic was not very easy to follow, and encoded the libc++ layout
in non-obvious ways. But mainly it was also fragile to alignment
miscalculations (https://github.com/llvm/llvm-project/pull/97443); this
would break once the new layout of `std::unordered_map` landed as part
of https://github.com/llvm/llvm-project/issues/93069.
Instead, this patch simply casts the `__hash_iterator` to a
`__node_pointer` (which is what libc++ does too) and uses a
straightforward `GetChildMemberWithName("__value_")` to get to the
key/value we care about.
The `std::unordered_map` already does it this way, so we align the
iterator counterpart to do the same. We can eventually re-use the
core-part of the `std::unordered_map` and `std::unordered_map::iterator`
formatters. But it will be an easier to change to review once both
simplifications landed.
In this version the internal data member has grown an additional
template parameter (bool), which was throwing the summary provider off.
This patch uses the type of the entire variant object. This is part of
the API/ABI, so it should be more stable, but it means we have to
explicitly strip typedefs and references to get to the interesting bits,
which is why I've extended the test case with examples of those.
Do not let the compiler gets failed in case the target platform does not
support the 'coroutine' C++ features. Just compile without it and let
lldb know about missed/unsupported feature.
These proxies are returned by operator[](...). These proxies all
"behave" the same. They store a pointer to the data of the valarray they
are a proxy for and they have an internal array of indices. This
internal array is considered its contents.
This uses [teyit](https://pypi.org/project/teyit/) to modernize asserts,
as recommended by the [unittest release
notes](https://docs.python.org/3.12/whatsnew/3.12.html#id3).
For example, `assertTrue(a == b)` is replaced with `assertEqual(a, b)`.
This produces better error messages, e.g. `error: unexpectedly found 1
and 2 to be different` instead of `error: False`.
This formatter
https://github.com/llvm/llvm-project/pull/78609
was originally passing the signed seconds (which can refer to times in
the past) with an unsigned printf formatter, and had tests that expected
to see negative values from the printf which always failed on macOS. I'm
not clear how they ever passed on any platform.
Fix the printf to print seconds as a signed value, and re-enable the
tests.
On macOS, the formatter is printing signed values as
unsigned, it seems, and the tests are expecting correctly
signed values. These tests were added in
https://github.com/llvm/llvm-project/pull/78609
This is a followup of #76983 and adds the libc++ data formatters for
- weekday,
- weekday_indexed,
- weekday_last,
- month_weekday,
- month_weekday_last,
- year_month,
- year_month_day_last
- year_month_weekday, and
- year_month_weekday_last.
This adds a subset of the C++20 calendar data formatters:
- day,
- month,
- year,
- month_day,
- month_day_last, and
- year_month_day.
A followup patch will add the missing calendar data formatters:
- weekday,
- weekday_indexed,
- weekday_last,
- month_weekday,
- month_weekday_last,
- year_month,
- year_month_day_last
- year_month_weekday, and
- year_month_weekday_last.
These tests were failing on the LLDB public matrix build-bots for older
clang versions:
```
clang-7: warning: argument unused during compilation: '-nostdlib++' [-Wunused-command-line-argument]
error: invalid value 'c++20' in '-std=c++20'
note: use 'c++98' or 'c++03' for 'ISO C++ 1998 with amendments' standard
note: use 'gnu++98' or 'gnu++03' for 'ISO C++ 1998 with amendments and GNU extensions' standard
note: use 'c++11' for 'ISO C++ 2011 with amendments' standard
note: use 'gnu++11' for 'ISO C++ 2011 with amendments and GNU extensions' standard
note: use 'c++14' for 'ISO C++ 2014 with amendments' standard
note: use 'gnu++14' for 'ISO C++ 2014 with amendments and GNU extensions' standard
note: use 'c++17' for 'ISO C++ 2017 with amendments' standard
note: use 'gnu++17' for 'ISO C++ 2017 with amendments and GNU extensions' standard
note: use 'c++2a' for 'Working draft for ISO C++ 2020' standard
note: use 'gnu++2a' for 'Working draft for ISO C++ 2020 with GNU extensions' standard
make: *** [main.o] Error 1
```
The test fails because we try to compile it with `-std=c++20` (which is
required for std::chrono::{days,weeks,months,years}) on clang versions
that don't support the `-std=c++20` flag.
We could change the test to conditionally compile the C++20 parts of the
test based on the `-std=` flag and have two versions of the python
tests, one for the C++11 chrono features and one for the C++20 features.
This patch instead just disables the test on older clang versions
(because it's simpler and we don't really lose important coverage).
This is relanding of https://github.com/llvm/llvm-project/pull/69253.
`TestTemplatePackArgs.py` is passing now.
https://github.com/llvm/llvm-project/pull/68012/files added new data
formatters for LibStdC++ std::variant.
However, this formatter can crash if std::variant's index field has
invalid value (exceeds the number of template arguments).
This can happen if the current IP stops at a place std::variant is not
initialized yet.
This patch fixes the crash by ensuring the index is a valid value and
fix GetNthTemplateArgument() to make sure it is not crashing.
Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
https://github.com/llvm/llvm-project/pull/68012/files added new data
formatters for LibStdC++ std::variant.
However, this formatter can crash if std::variant's index field has
invalid value (exceeds the number of template arguments).
This can happen if the current IP stops at a place std::variant is not
initialized yet.
This patch fixes the crash by ensuring the index is a valid value.
---------
Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
https://github.com/llvm/llvm-project/pull/68012 works on my CentOS Linux
and Macbook but seems to fail for certain build bots. The error log
complains "No Value" check failure for `std::variant` but not very
actionable without a reproduce.
To unblock the build bots, I am commenting out the "No Value" checks.
Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
(motivated by test failures after D157058)
With D157058 the base template for `std::char_traits` was removed from
libc++. Quoting the release notes:
```
The base template for ``std::char_traits`` has been removed. If you are using
``std::char_traits`` with types other than ``char``, ``wchar_t``, ``char8_t``,
``char16_t``, ``char32_t`` or a custom character type for which you
specialized ``std::char_traits``, your code will no longer work.
```
This patch simply removes all such instantiations to make sure the
tests that run against the latest libc++ version pass.
One could try testing the existence of this base template from within
the test source files but this doesn't seem like something we want
support.
Differential Revision: https://reviews.llvm.org/D157636
This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).
If you end up having problems merging this commit because you have made
changes to a python file, the best way to handle that is to run `git
checkout --ours <yourfile>` and then reformat it with black.
RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Differential revision: https://reviews.llvm.org/D151460
