An LLVM 19-aligned libc++ was released with macOS 15.4 (and corresponding OSes), and LLVM-20 aligned with macOS 26.0. This patch adds availability markup to reflect that.
This patch reverts e15025dd and 88e15b781 which were temporary measures until we had figured out the underlying issues. It turns out that recent OSes updated localization data, removing the need for several Apple-specific workarounds in the tests. Fixes #135385
Like #135202 this fixes another issue after the XCode update.
This patch removes many annotations that are not relevant anymore since we don't support or test back-deploying to macOS < 10.13. It also cleans up raw usage of target triples to identify versions of dylibs shipped on prior versions of macOS, and uses the target-agnostic Lit features instead. Finally, it reorders both the Lit backdeployment features and the corresponding availability macros in the library in a way that makes more sense, and reformulates the Lit backdeployment features in terms of when a version of LLVM was introduced instead of encoding the system versions on which it hasn't been introduced yet. Although one can be derived from the other, encoding the negative form is extremely error-prone. Fixes #80901
We were not making any distinction between e.g. the "Apple-flavored" libc++ built from trunk and the system-provided standard library on Apple platforms. For example, any test that would be XFAILed on a back-deployment target would unexpectedly pass when run on that deployment target against the tip of trunk Apple-flavored libc++. In reality, that test would be expected to pass because we're running against the latest libc++, even if it is Apple-flavored. To solve this issue, we introduce a new feature that describes whether the Standard Library in use is the one provided by the system by default, and that notion is different from the underlying standard library flavor. We also refactor the existing Lit features to make a distinction between availability markup and the library we're running against at runtime, which otherwise limit the flexibility of what we can express in the test suite. Finally, we refactor some of the back-deployment versions that were incorrect (such as thinking that LLVM 10 was introduced in macOS 11, when in reality macOS 11 was synced with LLVM 11). Fixes #82107
Previously, the list of libc++abi symbols that we re-export from libc++ would be partly encoded in libc++abi (and re-exported automatically via the cxxabi-reexports target), and partly hard-coded in libcxx/lib/libc++abi.exp. The duplication of information led to symbols not being exported from libc++ after being added to libc++abi when they should have been. This patch removes the duplication of information. After this patch, the full list of symbols to re-export from libc++abi is handled by the cxxabi-reexports target and is stored in libcxxabi. The symbols newly re-exported from libc++ are mainly new fundamental typeinfos and a bunch of functions and classes that are part of libc++abi but are most likely implementation details. In the future, it would be possible to try to trim down the set of what we export from libc++abi (and hence what we re-export from libc++) to remove some implementation detail symbols. Fixes #79008
We've stopped doing it in libc++ for a while now because these names would end up rotting as we move things around and copy/paste stuff. This cleans up all the existing files so as to stop the spreading as people copy-paste headers around.
Instead of having different names for the same Lit feature accross code bases, use the same name everywhere. This NFC commit is in preparation for a refactor where all three projects will be using the same Lit feature detection logic, and hence it won't be convenient to use different names for the feature. Differential Revision: https://reviews.llvm.org/D78370
Otherwise, we don't seem to get the DYLD_LIBRARY_PATH set up correctly and the tests are run against the system libc++abi dylib. llvm-svn: 358937