diff options
author | Felipe de Azevedo Piovezan <fpiovezan@apple.com> | 2022-09-10 07:21:27 -0400 |
---|---|---|
committer | Felipe de Azevedo Piovezan <fpiovezan@apple.com> | 2022-09-12 12:34:11 -0400 |
commit | fc04749957f17f42b1eab538fa3e68857034facb (patch) | |
tree | 4e9cb60d70e3d7966e56074a8d3ea18a1b487dc1 /llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp | |
parent | 4ca25c66d41ab136d1587b33571d3e58cd5989f8 (diff) | |
download | llvm-fc04749957f17f42b1eab538fa3e68857034facb.zip llvm-fc04749957f17f42b1eab538fa3e68857034facb.tar.gz llvm-fc04749957f17f42b1eab538fa3e68857034facb.tar.bz2 |
[lldb] Fix detection of existing libcxx
The CMake variable LLDB_HAS_LIBCXX is passed to
`llvm_canonicalize_cmake_booleans`, which transforms TRUE/FALSE into
'1'/'0'. It also transforms undefined variables to '0'.
In particular, this means that the configuration script for LLDB API's
test always has _some_ value for the `has_libcxx` configuration:
```
config.has_libcxx = '@LLDB_HAS_LIBCXX@'
```
When deciding whether a libcxx exist, the testing scripts would only
check for the existence of `has_libcxx`, but not for its value. In other
words, because `if ('0')` is true in python we always think there is a
libcxx.
This was caught once D132940 was merged and most tests started to use
libcxx by default if `has_libcxx` is true. Prior to that, no failures
were seen because only tests are marked with
`@add_test_categories(["libc++"])` would require a libcxx, and these
would be filtered out on builds without the libcxx target. Furthermore,
the MacOS bots always build libcxx.
We fix this by making `has_libcxx` a boolean (instead of a string) and
by checking its value in the test configuration.
Differential Revision: https://reviews.llvm.org/D133639
Diffstat (limited to 'llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp')
0 files changed, 0 insertions, 0 deletions