When demangling a template template parameter (`method<bool,
Bar>(Bar<bool> b)`), the current demangler version first enters the
template argument (`bool`) into the substitutions list, then the whole
template specialization (`Bar<bool>`). The template name (`Bar`) never
becomes a substitution candidate on its own.
This is different when mangling. Mangling `method<bool, Bar>(Bar<bool>
b, Bar<int> i)` substitutes the `Bar` in the second parameter with the
substitution for `TemplateTemplateParmDecl`.
This leads to a discrepancy between mangler and demangler, see
https://github.com/llvm/llvm-project/issues/108009.
This improves the demangling for non-type template arguments that
contain string literals. Previously we'd produce
char [4]{(char)65, (char)66, (char)67}
(which isn't valid C or C++), and now we produce `"ABC"`.
The new demangling is always shorter, even when using an escape sequence
for every character, and much more readable when the char array contains
text.
The demangling terminate handler uses a function `demangle()` to perform
the demangling. This function returns an `std::unique_ptr`, relying on
custom deleter and `const_cast` hacks to deal with the facts that only
one branch actually allocates, and that the pointer type needs to be
`const char*`. However, the destructor of the returned `std::unique_ptr`
will never actually run, because the sole place this function is ever
called is right before the terminate handler aborts the program. So all
this is unnecessary, and creates a dependency onto `<memory>`. This
change removes the `demangle()` function and replaces the call with an
immediately invoked lambda expression that simply returns a raw pointer
in both cases, which should be fine because the memory can never be
freed here anyways.
The demangler is shared between libcxxabi and llvm/lib/Demangle, see
libcxxabi/src/demangle/README.txt. The copy in llvm/lib/Demangle cannot
use __cxxabi_config.h. Remove the include. It was only used to identify
clang, which can easily be done without the include as well.
No intended behavior change.
This fixes testing with MinGW, if built without
__USE_MINGW_ANSI_STDIO=1.
On x86 MinGW, such a configuration fails printf tests with long doubles
due to mismatches between 80 and 64 bit long doubles - but on ARM,
there's no such issue, so building without __USE_MINGW_ANSI_STDIO=1 is
perfectly valid there.
Add another similar XFAIL to a libcxxabi test; this test isn't executed
in MSVC environments, so no XFAIL has been needed so far.
This patch applies the comments provided on #84573. This is done as a
separate PR to avoid merge conflicts with downstreams that already had
ptrauth support.
In order to test libc++ under the "Apple System Library" configuration,
we need to run the tests using DYLD_LIBRARY_PATH. This is required
because libc++ gets an install_name of /usr/lib when built as a system
library, which means that we must override the copy of libc++ used by
the whole process. This effectively reverts 2cf2f1b, which was the wrong
solution for the problem I was having.
Of course, this assumes that the just-built libc++ is sufficient to
replace the system library, which is not actually the case
out-of-the-box. Indeed, the system library contains a few symbols that
are not provided by the upstream library, leading to undefined symbols
when replacing the system library by the just-built one.
To solve this problem, we separately build shims that provide those
missing symbols and we manually link against them when we build
executables in the tests. While this is somewhat brittle, it provides a
localized and unintrusive way to allow testing the Apple system
configuration in an upstream environment, which has been a frequent
request.
GCC 14 has been released a while ago. We've updated the CI to use GCC 14
now. This removes any old annotations in the tests and updates the
documentation to reflect the updated version requirements.
This is the continuation of #96112 which implements proposal from Louis.
Using PRIVATE option on target_compile_options() fixes the issue of
propagating the option into lib++.
This adds a new `__cxa_call_terminate`, which GCC 14 generates calls to
now. Clang had `__clang_call_terminate` for the same use-case for a long
time. It also fixes a test that is enabled now, since GCC has the
`__has_feature` FTM now.
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
We use target_compile_options to pass the libc++ variant of this flag,
so we should be consistent for libc++abi. This is actually not only a
matter of consistency: target_compile_options handles duplicate CMake
options in a certain way (it removes duplicates but has an escape hatch
using the "SHELL:" prefix), and it is important for both libc++ and
libc++abi options to be handled in the same way.
This patch makes a few adjustments to the way we run the tests in the
Apple configuration on macOS:
First, we stop using DYLD_LIBRARY_PATH. Using that environment variable
leads to libc++.dylib being replaced by the just-built one for the whole
process, and that assumes compatibility between the system-provided
dylib and the just-built one. Unfortunately, that is not the case
anymore due to typed allocation, which is only available in the system
one. Instead, we want to layer the just-built libc++ on top of the
system-provided one, which seems to be what happens when we set a rpath
instead.
Second, add a missing XFAIL for a std::print test that didn't work as
expected when building with availability annotations enabled. When we
enable these annotations, std::print falls back to a non-unicode and
non-terminal output, which breaks the test.
We weren't applying the libdir subdir to header directories but this is
necessary for correctness when building e.g. ASan variant. This change
also updates path construction logic accross all runtimes and ensures
they're consistent.
Instead of using FOO_TEST_DEPS global variables that don't get updated
properly from subdirectories, use targets to propagate the dependencies
across directories.
A while back, the cxx_under_test Lit parameter was removed. This patch
reintroduces a Lit parameter called "compiler" which controls the value
of the %{cxx} substitution used in the test suite.
To run the test suite with a different compiler, one can now pass
--param compiler=<path>.
Update the folder titles for targets in the monorepository that have not
seen taken care of for some time. These are the folders that targets are
organized in Visual Studio and XCode
(`set_property(TARGET <target> PROPERTY FOLDER "<title>")`)
when using the respective CMake's IDE generator.
* Ensure that every target is in a folder
* Use a folder hierarchy with each LLVM subproject as a top-level folder
* Use consistent folder names between subprojects
* When using target-creating functions from AddLLVM.cmake, automatically
deduce the folder. This reduces the number of
`set_property`/`set_target_property`, but are still necessary when
`add_custom_target`, `add_executable`, `add_library`, etc. are used. A
LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's
root CMakeLists.txt.
- No indirect syscalls on OpenBSD. Instead there is a `futex` function
which issues a direct syscall.
- Monotonic clock is available despite the full POSIX suite of timers
not being available in its entirety.
See https://lists.boost.org/boost-bugs/2015/07/41690.php and
c98b1f459a
for a description of an analogous problem and fix for Boost.
The destructors generated by the legacy IBM `xlclang++` compiler can
take 1 or 2 arguments and the differences were handled by type `cast`
where it is needed. Clang now treats the `cast` here as an error after
999d4f8407
landed with `-Xextra -Werror`. The issue had been worked around by using
`#pragma GCC diagnostic push/pop`. This patch defines 2 separate
destructor types for 1 argument and 2 arguments respectively so `cast`
is not needed.
clang treats the cast here as an error since 999d4f840777bf8de26d45947192aa0728edc0fb landed
with -Xextra -Werror. We believe this cast to be safe for the reasons noted in comment, but
we should do some further cleanup at some point.
This is an exact upstreaming of the downstream diff. Minor
simplifications can be made in the future but upstreaming as-is will
make it easier for us to deal with downstream merge conflicts.
Partially fixes#83805
27ce26b06655cfece3d54b30e442ef93d3e78ac7 added the new option
-fvisibility-global-new-delete=, where -fvisibility-global-new-delete=force-hidden
is equivalent to the old option -fvisibility-global-new-delete-hidden.
At the same time, the old option was deprecated.
Test for and use the new option form first; if unsupported, try
using the old form.
This avoids warnings in the MinGW builds, if built with Clang 18 or
newer.
We always provide the std:: exception types, even when exceptions are
disabled. This is a bit counter-intuitive, but these exception types are
just normal types at the end of the day so we made the decision to
always provide their definition. Failure to re-export these types would
cause libc++ to fail to link on Apple platforms when exceptions are
disabled.
The Itanium C++ ABI specifies that FP literals are encoded using a
lowercase hexadecimal string. Previously, libc++abi allowed uppercase
A-F characters but decoded them by subtracting 'a' from them, producing
negative digit values. It is especially confusing to accept an 'E' digit
because 'E' marks the end of the FP literal.
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
Chrome rolls libc++ and libc++abi as separate projects. As a result, they
may not always be updated in lockstep, and this can lead to build failures
when mixing libc++ that doesn't have <__thread/support.h> with libc++abi
that requires it.
This patch adds a workaround to make libc++abi work with both versions.
While Chrome's setup is not supported, this workaround will allow them
to go back to green and do the required work needed to roll libc++ and
libc++abi in lockstep. This workaround will be short-lived -- I have a
reminder to go back and remove it by EOW.
The <__threading_support> header is a huge beast and it's really
difficult to navigate. I find myself struggling to find what I want
every time I have to open it, and I've been considering splitting it up
for years for that reason.
This patch aims not to contain any functional change. The various
implementations of the threading base are simply moved to separate
headers and then the individual headers are simplified in mechanical
ways. For example, we used to have redundant declarations of all the
functions at the top of `__threading_support`, and those are removed
since they are not needed anymore. The various #ifdefs are also
simplified and removed when they become unnecessary.
Finally, this patch adds documentation for the API we expect from any
threading implementation.
In D144319, Clang tried to land a change that would cause some functions
that are not supposed to return nullptr to optimize better. As reported
in https://reviews.llvm.org/D144319#4203982, libc++ started seeing
failures in its CI shortly after this change was landed.
As explained in D146379, the reason for these failures is that libc++'s
throwing `operator new` can in fact return nullptr when compiled with
exceptions disabled. However, this contradicts the Standard, which
clearly says that the throwing version of `operator new(size_t)` should
never return nullptr. This is actually a long standing issue. I've
previously seen a case where LTO would optimize incorrectly based on the
assumption that `operator new` doesn't return nullptr, an assumption
that was violated in that case because libc++.dylib was compiled with
-fno-exceptions.
Unfortunately, fixing this is kind of tricky. The Standard has a few
requirements for the allocation functions, some of which are impossible
to satisfy under -fno-exceptions:
1. `operator new(size_t)` must never return nullptr
2. `operator new(size_t, nothrow_t)` must call the throwing version and
return nullptr on failure to allocate
3. We can't throw exceptions when compiled with -fno-exceptions
In the case where exceptions are enabled, things work nicely.
`new(size_t)` throws and `new(size_t, nothrow_t)` uses a try-catch to
return nullptr. However, when compiling the library with
-fno-exceptions, we can't throw an exception from `new(size_t)`, and we
can't catch anything from `new(size_t, nothrow_t)`. The only thing we
can do from `new(size_t)` is actually abort the program, which does not
make it possible for `new(size_t, nothrow_t)` to catch something and
return nullptr.
This patch makes the following changes:
1. When compiled with -fno-exceptions, the throwing version of `operator
new` will now abort on failure instead of returning nullptr on failure.
This resolves the issue that the compiler could mis-compile based on the
assumption that nullptr is never returned. This constitutes an API and
ABI breaking change for folks compiling the library with -fno-exceptions
(which is not the general public, who merely uses libc++ headers but use
a shared library that has already been compiled). This should mostly
impact vendors and other folks who compile libc++.dylib themselves.
2. When the library is compiled with -fexceptions, the nothrow version
of `operator new` has no change. When the library is compiled with
-fno-exceptions, the nothrow version of `operator new` will now check
whether the throwing version of `operator new` has been overridden. If
it has not been overridden, then it will use an implementation
equivalent to that of the throwing `operator new`, except it will return
nullptr on failure to allocate (instead of terminating). However, if the
throwing `operator new` has been overridden, it is now an error NOT to
also override the nothrow `operator new`. Indeed, there is no way for us
to implement a valid nothrow `operator new` without knowing the exact
implementation of the throwing version.
In summary, this change will impact people who fall into the following
intersection of conditions:
- They use the libc++ shared/static library built with `-fno-exceptions`
- They do not override `operator new(..., std::nothrow_t)`
- They override `operator new(...)` (the throwing version)
- They use `operator new(..., std::nothrow_t)`
We believe this represents a small number of people.
Fixes#60129
rdar://103958777
Differential Revision: https://reviews.llvm.org/D150610
