Support leak sanitizer in libcxx.
Simple addition for leak checking when running the libcxx testsuite.
Differential Revision: https://reviews.llvm.org/D100775
This allows us to turn -Wdeprecated-copy back on. We turned it off
in 3b71de41cc because Clang's implementation became more stringent
and started diagnosing the old code here.
Differential Revision: https://reviews.llvm.org/D101183
The straightforward `AddLinkFlag('-lc++experimental')` approach doesn't
work on e.g. MSVC. For linking to libc++ itself, a more convoluted logic
is used (see configure_link_flags_cxx_library).
Differential Revision: https://reviews.llvm.org/D99177
Certain fields of shared ptr have virtual functions and therefore
have their debug info homed in libc++. But if libc++ wasn't built
with debug info, the pretty printer would fail.
This patch makes the pretty printer tolerate such conditions and
updates the test harness.
This patch significantly reworks a previous attempt.
This addresses https://bugs.llvm.org/show_bug.cgi?id=48937
Differential Revision: https://reviews.llvm.org/D100610
Since we have a tool to detect cycles now; and since we're entering
a phase where people can easily introduce cycles by accident (D100682)
or by request (D90999), I think it's increasingly important to shift
the burden of detecting these cycles onto the buildbot instead of
the poor human reviewer.
Also, grep for non-ASCII characters (such as U+200B and U+00AD)
and hard tabs; don't let those get checked in.
Differential Review: https://reviews.llvm.org/D100703
This is the initial patch to implement ranges in libc++.
Implements parts of:
- P0896R4 One Ranges Proposal
- P1870 forwarding-range is too subtle
- LWG3379 in several library names is misleading
Reviewed By: ldionne, #libc, cjdb, zoecarver, Quuxplusone
Differential Revision: https://reviews.llvm.org/D90999
After this patch, we can use `--param std=c++20` even if the compiler only
supports -std=c++2a. The test suite will handle that for us. The only Lit
feature that isn't fully baked will always be the "in development" one,
since we don't know exactly what year the standard will be ratified in.
This is another take on https://reviews.llvm.org/D99789.
Differential Revision: https://reviews.llvm.org/D100210
This adds a CI job validating that the output of
utils/generate_feature_test_macro_components.py,
libcxx/utils/generate_header_inclusion_tests.py, and
utils/generate_header_tests.py are up to date.
The validation method has been copied from the Format job.
Differential Revision: https://reviews.llvm.org/D99862
As mandated by the Standard's various synopses, e.g. [iterator.synopsis].
Searching the TeX source for '#include' is a good way to find all of these
mandates.
The new tests are all autogenerated by utils/generate_header_inclusion_tests.py.
I was SHOCKED by how many mandates there are, and how many of them
libc++ wasn't conforming with.
Differential Revision: https://reviews.llvm.org/D99309
This improves the naming of the fields `depends`/`internal_depends`. It
also adds the documentation for this script. The changes are based on
D99290 and its review comments.
Differential Revision: https://reviews.llvm.org/D99615
This matches what we link the library itself against (set in
CMakeLists.txt). When testing a static library version of libc++,
this is needed for essentially every test due to libc++ object files
requiring it.
Also with libc++ built as a DLL, some tests directly call functions that
are provided by msvcprt (such as std::set_new_handler), thus this fixes
a number of tests in that configuration too.
Differential Revision: https://reviews.llvm.org/D99263
Without this patch, we'd always try to codesign the first argument in
the command line, which in some cases is not something we can codesign
(e.g. `bash` for some .sh.cpp tests).
Note that this "hack" is the same thing we do in `ssh.py` - we might need
to admit that it's not a hack after all in the future, but I'm not ready
for that yet.
Differential Revision: https://reviews.llvm.org/D99726
This will avoid typos like `_LIBCPP_STD_VERS` (<future>) or using `#if TEST_STD_VER > 17` without including "test_macros.h".
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D99515
The directories in LIB normally only contain import libraries or
static libraries, no runtime DLLs that would need to be found
while running tests.
This code stems from 1cd196e7b4,
which (among other things) tried to do this:
> * [Test] Fix handling of library runtime search paths by correctly adding them
> to the PATH variable when running the tests.
It's unclear to me exactly what this fixed (or tried to) at the time,
as the LIB var doesn't normally point to runtime libs.
Differential Revision: https://reviews.llvm.org/D99241
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.
This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.
It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.
Differential Revision: https://reviews.llvm.org/D97572
Download older roots from Dropbox instead of Green Dragon, which is too
unreliable. Also XFAIL tests that were broken for back-deployment
configurations by D98097.
Differential Revision: https://reviews.llvm.org/D99359
In Python 3, math.floor returns int when both arguments are ints.
In Python 2, math.floor returns float. This leads to a failure
because the result of math.floor is used as an array index. While
Python 2 is on its way out, it's still used in some places so use
an integer division instead.
Differential Revision: https://reviews.llvm.org/D99520
Need to exclude nasty_macros.h from check-cxx on z/OS due to conflicts within system headers.
Sample failure in `random_shuffle.depr_in_cxx14.verify.cpp` libcxx test.
```
error: 'error' diagnostics seen but not expected:
Line 1268: expected ')'
Line 1268: unknown type name 'This'
Line 1268: expected ')'
```
caused by the following macros in `nasty_macros.h`
```
#define NASTY_MACRO This should not be expanded!!!
#define _E NASTY_MACRO
```
The name collision is observed in the following code snippet whre `_E` is being used as parameter name:
```
inline int iswalnum(wint_t _E) {return __iswalnum(_E);}
```
It is reasonable to exclude `nasty_macros.h` on z/OS similarly as it was done on Windows.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D99378
This patch changes the variant even in pre-C++2b.
It should not break anything, only allow use cases that didn't work previously.
Notes:
`__as_variant` is used in `__visitation::__variant::__visit_alt`, but I haven't used it in `__visitation::__variant::__visit_alt_at`.
That's because it is used only in `__visit_value_at`, which in turn is always used on variant specializations (that's in comparison operators).
* https://wg21.link/P2162
Reviewed By: ldionne, #libc, Quuxplusone
Differential Revision: https://reviews.llvm.org/D97394
This safeguards against cases if some of the env vars contain chars
that are problematic for shells, e.g. if called with --env "X=Y;Z".
(In cases of cross testing for windows, the PATH variable can end up
specified with semicolon separators - even if specifying a PATH when
cross testing in such differing environments might not make sense or
do anything - but this makes ssh.py not break on such a variable.)
Differential Revision: https://reviews.llvm.org/D99242
My attempts to play around with the old graph_header_deps.py were mostly fruitless;
I needed to modify it in various ways to make it work, and then even when I got it
working, it generated pretty ugly graphs.
Old graph_header_deps.py (after my local changes to simplify the usage)
(producing https://i.imgur.com/zATrsaP.jpg )
mkdir foo
time ./graph_header_deps.py --libcxx-only -o foo --clang-command ~/llvm-project/build/bin/clang++
dot -Tpng < foo/all_headers.dot > old.png
file old.png
real 0m37.453s
old.png: PNG image data, 25882 x 3035, 8-bit/color RGBA, non-interlaced
New graph_header_deps.py
(producing https://i.imgur.com/ZU0G52U.png )
time ./graph_header_deps.py | dot -Tpng > new.png
file new.png
real 0m1.063s
new.png: PNG image data, 6162 x 1344, 8-bit/color RGBA, non-interlaced
Differential Revision: https://reviews.llvm.org/D99124
I was trying to fix something else and I stumbled upon several methods
that are not used anymore in target_info.py.
Differential Revision: https://reviews.llvm.org/D98896
`__cpp_lib_default_template_type_for_algorithm_values` is 52 characters long,
which is enough to reduce the multiplier to less-than-zero, producing an empty
string between the name of the macro and its numeric value. Ensure there's
always a space between the name of the macro and its value.
Differential Revision: https://reviews.llvm.org/D98869
Instead of setting mcpu like the previous bots,
set the target triple.
Each config builds either Arm only or Thumb only
code. This gives us some coverage of thumb specific
issues.
The new agents on Linaro's side are running on v8 hardware
so will report arch "armv8l" just like the v8 bots.
(and buildkite can choose any of them for v7/v8 jobs)
Reviewed By: #libc, curdeius, Mordante
Differential Revision: https://reviews.llvm.org/D98019
If cross testing (and manually specifying a LIBCXX_TARGET_INFO in the
cmake configuration, as the default is to match the build platform),
we want the accessors for querying the target platform, is_windows,
is_darwin, to return the right value depending on which target info
class is used, not based on what platform is running the build and
driving the tests.
When LIBCXX_TARGET_INFO isn't defined, the right target info class
is chosen automatically based on the platform one is running on, so
this shouldn't make any practical difference for such setups.
Differential Revision: https://reviews.llvm.org/D98045
The former was the old unusual name of the out-of-tree backend but it
was renamed to M68k during the code review process to conform with how
almost everything refers to the Motorola 68000 family of processors.
Thus, update the comments to avoid confusion when the backend lands.
If cross testing on Windows via WSL (at least with WSL 1), the Windows
executables can't be executed if they are in WSL specific directories
(like /tmp).
Differential Revision: https://reviews.llvm.org/D98028
Apple back-deployment testing is currently failing because Green Dragon
is down. To avoid stalling the whole CI pipeline because of that, I am
temporarily disabling those jobs until Green Dragon is back, or even
better we have found a different way to store those small artifacts.
Normally, the run.py wrapper script runs the child processes in
a clean environment, with only the environment variables available
that are passed via the --env parameter.
However, the COMSPEC and TEMP variables are kind of necessary when
running some tests; COMSPEC is necessary for finding the interpreter
when executing commands via std::system().
Before f1a96de1bc, tests were executed
via an intermediate shell which implicitly readded the COMSPEC variable.
The TEMP variable allows temp files to be placed in a sensible
location; if unset, they're placed in the default temp fallback of
C:\Windows instead.
Differential Revision: https://reviews.llvm.org/D97452
Several contributors have been asking me how to reproduce the CI
environment locally. This is the last step towards making that work
out-of-the-box. Basically, just run `libcxx/utils/ci/run-buildbot-container`
and you're good to go.
Differential Revision: https://reviews.llvm.org/D97782
Before this patch, we could only link against the back-deployment libc++abi
dylib. This patch allows linking against the just-built libc++abi, but
running against the back-deployment one -- just like we do for libc++.
Also, add XFAIL markup to flag expected errors.
Differential Revision: https://reviews.llvm.org/D91069
libc++ was previously a bit confused by what the value of __cpp_concepts
should be. Also replaces `__floating_point` with `floating_point` now
that it exists.
Differential Revision: https://reviews.llvm.org/D97015
Xcode does bundle Ninja, so we can use that Ninja if there's no system-wide
Ninja installed. This is useful on some CI bots we have that don't come
with Ninja pre-installed.
This can't easily be autodetected (unless LIBCXX_TARGET_TRIPLE is
specified, or unless we query what the compiler's default target is,
which only is supported by clang), but can be chosen manually via
LIBCXX_TARGET_INFO.
This chooses mingw style lib naming, and uses -nostdlibc++ instead
of -nodefaultlib -nostdlib (as the latter requires specifying a lot of
details manually - this is done in the cmake config though).
Differential Revision: https://reviews.llvm.org/D97294
This fixes building libunwind with a new enough version of cmake.
(libunwind treats its asm sources as C depending on the cmake version
on some platforms; this fixes builds when such workarounds aren't used,
when cmake treats asm correctly on its own.)
Differential Revision: https://reviews.llvm.org/D97399
Passing the MSVC include dirs via -isystem makes them included before
clang's own include resource dir (<prefix>/lib/clang/<version>/include).
This causes includes of stddef.h to bypass clang's stddef.h which
defines max_align_t, which libc++ needs defined.
This was added in 4372f06d0f when the
initial windows testing support was added, and has been brought along
since. It's unclear if this was needed back then - now it no longer is
needed at least, and since libc++ started depending on max_align_t, this
became an issue.
Differential Revision: https://reviews.llvm.org/D97167
This matches how libc++ itself is built. This avoids errors due to
mismatch if linking libc++ statically.
Differential Revision: https://reviews.llvm.org/D97169
Switch StdTuple printer from python 2-style "next" to python 3.
Nested iteration changed enough to make the original bitset iteration
code a bit trickier than it needs to be, so unnest.
The end node of a map iterator is sometimes hard to detect in isolation,
don't fail in that case.
Differential Revision: https://reviews.llvm.org/D96167
Note: contrary to what I said previously, I didn't change .clang-format nor utils/generate_feature_test_macro_components.py script.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D92229
Before this patch, feature-test macros didn't take special availability
markup into account, which means that feature-test macros can sometimes
appear to "lie". For example, if you compile in C++20 mode and target
macOS 10.13, the __cpp_lib_filesystem feature-test macro will be provided
even though the <filesystem> declarations are marked as unavailable.
This patch fixes that.
rdar://68142369
Differential Revision: https://reviews.llvm.org/D94983
This will allow running back-deployment testing on macOS only on systems
running the right version of macOS. For the time being, we're cheating
because we don't have actual machines running older than 10.15.
This is the first step at implementing <format>. It adds the <format> header
and implements the `format_error`. class.
Implemnts parts of:
-P0645 Text Formatting
Reviewed By: ldionne, #libc, miscco, curdeius
Differential Revision: https://reviews.llvm.org/D92214
Currently all these tests are XFAILED on Linux even though the problem
only seems to be with the few checks that look at collation. To retain
test coverage this splits the locale-dependent tests into a separate
.pass.cpp that is XFAILed as before.
This commit also XFAILs the locale-dependent tests on FreeBSD since the
[=M=] and [.ch.] behaviour for cs_CZ also doesn't seem to match the
behaviour that is expected by these tests.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D94969
Previously, LIBCXX_ENABLE_FILESYSTEM controlled only whether the filesystem
support was compiled into libc++'s library. This commit promotes the
setting to a first-class option like LIBCXX_ENABLE_LOCALIZATION, where
the whole library is aware of the setting and features that depend on
<filesystem> won't be provided at all. The test suite is also properly
annotated such that tests that depend on <filesystem> are disabled when
the library doesn't support it.
This is an alternative to https://llvm.org/D94824, but also an improvement
along the lines of LIBCXX_ENABLE_LOCALIZATION that I had been wanting to
make for a while.
Differential Revision: https://reviews.llvm.org/D94921
cmake_minimum_required(VERSION) calls cmake_policy(VERSION),
which sets all policies up to VERSION to NEW.
LLVM started requiring CMake 3.13 last year, so we can remove
a bunch of code setting policies prior to 3.13 to NEW as it
no longer has any effect.
Reviewed By: phosek, #libunwind, #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D94374
I've been playing a bit with the `generate_feature_test_macro_components.py` script and replaced some hardcoded values with extra code generation (generate ALL the things).
The output is the same and it makes updating the script less work for the coming 25 C++ standards (until 2 digit number overflow).
Feel free to 'veto' if you think it's overkill.
Differential Revision: https://reviews.llvm.org/D94530
This adds `// clang-format off` in the auto-generated file to avoid lint warnings.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D94410
I accidentally disabled this feature-test macro in my D93830,
due to a rebasing conflict. It had been enabled by my D93815,
and should have remained enabled.
It's still a little confusing because in many cases C++17 and C++20
have different values, and libc++ implements the C++17 behavior but
not the C++20 behavior; 'unimplemented' can't represent that scenario.
Ultimately we probably ought to completely redesign the script to be
in terms of paper numbers, rather than language revisions, and make
it generate the CSV files like "Cxx2aStatusPaperStatus.csv" as well.
Most newly added macros are unimplemented. I've marked a few as implemented,
though, based on my reading of the code; for example I was pretty sure
`__cpp_lib_latch` is implemented since we have `<latch>`.
Differential Revision: https://reviews.llvm.org/D93830
* The only exception is that the flag -std=c++2a is still used not to break compatibility with older compilers (clang <= 9, gcc <= 9).
* Bump _LIBCPP_STD_VER for C++20 to 20 and use 21 for the future standard (C++2b).
That's a preparation step to add c++2b support to libc++.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D93383
On macOS 10.14 /usr/lib/system/libcompiler_rt.dylib contains all the
`__atomic_load*`, etc. functions but does not include the `__atomic_is_lock_free`
function. The lack of this function causes the non-lockfree-atomics feature
to be set to false even though large atomic operations are actually
supported, it's just the is_lock_free() function that is missing.
This is required so that the !non-lockfree-atomics feature can be used
to XFAIL tests that require runtime library support (D88818).
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D91911
Installing clang-format-11 doesn't seem to work if it's done before
we've installed LLVM. I must admit I didn't try to get to the bottom
of the issue, since installing it after seems to work.
Two problems fixed:
* an old version of clang-format get installed by default (6.0).
* git-clang-format is not present, only git-clang-format-<version> (e.g. git-clang-format-6.0).
Solution:
* install clang-format-11 with explicit version
* make symlink git-clang-format to the latest version of git-clang-format-<version>
Differential Revision: https://reviews.llvm.org/D93201
Otherwise they come out in random (inode?) order.
Also `chmod +x` the generator, and re-run it. Somehow on Marek's
machine it produced \r\n line endings?! Open all files with
`newline='\n'` so that (if the Python3 docs are correct)
that won't happen again.
Differential Revision: https://reviews.llvm.org/D93137
Idea from D92525.
This script globs include/ directory and updates the tests in test/libcxx.
This patch does not generate module.modulemap nor CMakeLists.txt.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D92656
The goal was to add coverage for back-deployment over the filesystem
library, but it was added in macOS 10.15, not 10.14.
Differential Revision: https://reviews.llvm.org/D92937
It adds coverage for back-deploying to a system that contains the
filesystem library, which 10.9 (currently our only back-deployment
target in the CI) does not have.
Differential Revision: https://reviews.llvm.org/D92794
By encoding ABI-affecting properties in the name of the ABI list, it
makes it clear when an ABI list test should or should not be available,
and what results we should expect.
Note that we clearly don't encode all ABI-affecting parameters in the
name right now -- I just ported over what we supported in the code that
was there previously. As we encounter configurations that we wish to
support but produce different ABI lists, we can add those to the ABI
identifier and start supporting them.
This commit also starts checking the ABI list in the CI jobs that run
a supported configuration. Eventually, all configurations should have
a generated ABI list and the test should even run implicitly as part of
the Lit test suite.
Differential Revision: https://reviews.llvm.org/D92194
I'm not 100% sure what the issue actually is since I can't reproduce it
locally, however what I explain in the comment is my best attempt to
explain what's going on.
Differential Revision: https://reviews.llvm.org/D92131
Implements P1956: On the names of low-level bit manipulation functions.
Users may use older versions of libc++ or other standard libraries with the old names. In order to keep compatibility the old functions are kept, but marked as deprecated.
The patch also adds a new config macro `_LIBCPP_DEPRECATED_MSG`. Do you prefer a this is a separate patch?
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D90551
Also, enable them whenever we detect that gdb is available. Previously,
these tests would basically never run because they relied on a CMake
configuration option that defaulted to OFF.
Differential Revision: https://reviews.llvm.org/D91434
Summary:
Before this patch, we could only link against the back-deployment libc++abi
dylib. This patch allows linking against the just-built libc++abi, but
running against the back-deployment one -- just like we do for libc++.
Also, add XFAIL markup to flag expected errors.
The current way we test this is pretty cheap, i.e. we download previously
released macOS dylibs and run against that. Ideally, we would require a
full host running the appropriate version of macOS, and we'd execute the
tests using SSH on that host. But since we don't have such hosts available
easily for now, this is better than nothing.
At the same time, also fix some tests that were failing when back
deploying.
Differential Revision: https://reviews.llvm.org/D90869
Remove Phabricator, which isn't needed anymore since we don't report
the job results ourselves. Also, install python3-sphinx instead of
sphinx-doc, since the latter doesn't provide the sphinx-build binary.
Currently, vendor-specific availability markup is enabled by default.
This means that even when building against trunk libc++, the headers
will by default prevent you from using some features that were not
released in the dylib on your target platform. This is a source of
frustration since people building libc++ from sources are usually not
trying to use some vendor's released dylib.
For that reason, I've been thinking for a long time that availability
annotations should be off by default, which is the primary change that
this commit enables.
In addition, it reworks the implementation to make it easier for new
vendors to add availability annotations for their platform, and it
refreshes the documentation to reflect the current state of the codebase.
Finally, a CMake configuration option is added to control whether
availability annotations should be turned on for the flavor of libc++
being created. The intent is for vendors like Apple to turn it on, and
for the upstream libc++ to leave it off (the default).
Differential Revision: https://reviews.llvm.org/D90843
`mftb` and `mftbl` are equivalent, there is no need to have two names for doing the same thing, rename `mftbl` to only have `mftb`.
Differential Revision: https://reviews.llvm.org/D89506
Unfortunately, executing these tests correctly on platforms that do not
support a shell is very challenging. Since the executor can't just negate
the result of the command, we'd have to ship a portable program capable
of running the actual test executable, and negating its result.
Doing this portably is challenging. Since we do not currently have strong
use cases for tests that fail at runtime (we effectively have no tests
using that capability right now), it is difficult to justify making them
work portably. Instead, it makes more sense to remove this feature until
we can implement it properly (i.e. without requiring shell support).
This makes us closer to running the test suite on platforms where the
legacy test suite configuration doesn't work.
One notable change after this commit is that the tests will be run with
warnings enabled on GCC too, which wasn't the case before. However,
previous commits should have tweaked the test suite to make sure it
passes with warnings enabled on GCC.
Note that warnings can still be disabled with `--param enable_warnings=False`,
as before.
Differential Revision: https://reviews.llvm.org/D90432
Instead of having to remember the command-line to use every time, this
commit adds a CMake target to generate the ABI list in the current
configuration, if it is supported.
As a fly-by change, remove scripts that are now unused (sym_match.py
and sym_extract.py).
GCC tries to be nice and tell us that we probably want to also implement
sized deallocation functions when we override the normal ones. However,
we know what we're doing in the test suite and don't want to override
them.
This will allow adding bare compiler flags through the new
configuration DSL. Previously, this would have required adding
a Lit feature for each such flag.
Differential Revision: https://reviews.llvm.org/D90429
This patch add the target-* (x86_64-*) as used elsewhere in llvm.
Reviewed By: #libc, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D88027
When porting libc++ to embedded systems, it can be useful to drop support
for localization, which these systems don't implement or care about.
Differential Revision: https://reviews.llvm.org/D90072
This is a massive revert of the following commits (from most revent to oldest):
2b9b7b5775.
529ac3319728270234f169c2087283b5aa67446e5d796645d6
After checking-in the __config_site change, a lot of things started breaking
due to widespread reliance on various aspects of libc++'s build, notably the
fact that we can include the headers from the source tree, but also reliance
on various "internal" CMake variables used by the runtimes build and compiler-rt.
These were unintended consequences of the change, and after two days, we
still haven't restored all the bots to being green. Instead, now that I
understand what specific areas this will blow up in, I should be able to
chop up the patch into smaller ones that are easier to digest.
See https://reviews.llvm.org/D89041 for more details on this adventure.
Now libc++ pipeline will be triggered from the "premerge-checks" and the
combined result are going to be returned to Harbormaster.
Reviewed-by: ldionne
Differential Revision: https://reviews.llvm.org/D89113
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.
This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.
It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.
This commit was originally applied in 1e46d1aa3 and reverted in eb60c487
because it broke the libc++abi and libunwind test suites. This has now
been fixed.
Differential Revision: https://reviews.llvm.org/D89041
Sterling Augustine
