| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When lpStartEncoding is different from DW_EH_PE_omit, lpStart can be set
to zero which is a valid base address for landing pads. Such base value
is useful when landing pads are placed in different sections.
Fixes #72582.
|
|
C++23 removed `<ciso646>` from the standard library. The header is used
in a few places in order to pull in implementation-specific and feature
test macros. The new way of doing that is `<version>`, which should be
supported by all supported implementations. This change replaces all
those uses of `<ciso646>` with `<version>`.
|
|
This patch actually runs the tests for picolibc behind an emulator,
removing a few workarounds and increasing coverage.
Differential Revision: https://reviews.llvm.org/D155521
|
|
Picolibc is a C Standard Library that is commonly used in embedded
environments. This patch adds initial support for this configuration
along with pre-commit CI. As of this patch, the test suite only builds
the tests and nothing is run. A follow-up patch will make the test suite
actually run the tests.
Differential Revision: https://reviews.llvm.org/D154246
|
|
(#72881)
The mangling for an explicitly named object was introduced in
https://reviews.llvm.org/D140828
See following discussion for why a new mangling had to be introduced:
https://github.com/itanium-cxx-abi/cxx-abi/issues/148
Since clang started emitting names with the new mangling, this patch
implements support for demangling such names.
The approach this patch takes is to add a new `ExplicitObjectParameter`
node that will print the first parameter of a function declaration with
a `this ` prefix, to reflect what was spelled out in source.
Example:
```
void MyClass::func(this MyClass const& self); // _ZNH7MyClass4funcERKS_
```
With this patch, the above demangles to:
```
_ZNH7MyClass4funcERKS_ -> MyClass::func(this MyClass const&)
```
Note that `func` is not marked as `const &`, since the
function-qualifiers are now encoded as part of the explicit `this`. C++
doesn't allow specifying the function-qualifiers in the presence of an
explicit object parameter, so this demangling is consistent with the
source spelling.
|
|
(#73503)
Adding test-cases to the `cases` array causes `git clang-format` to
split the strings of many of the existing test-cases, making them harder
to read/work with in most cases.
This patch disables `clang-format` for the `cases` array so it doesn't
catch anyone off-guard in the future.
|
|
The runtimes now have a principled way of doing assertions in relation
to hardening, so we should use that instead of raw calls to assert()
inside libc++abi. This patch aims to maintain the behavior of the
demangler code when it is used from within LLVM by introducing a simple
DEMANGLE_ASSERT(...) macro that is then defined to the appropriate
assertion mechanism.
|
|
|
|
`LIBCXXABI_SYSROOT`, `LIBCXXABI_TARGET_TRIPLE` and
`LIBCXXABI_GCC_TOOLCHAIN` are not supported anymore. Based on the
comment, the warning should be removed after branching for LLVM 15.
|
|
|
|
This is necessary in order to implement some papers like P2467R1, which
require using C++23 declarations in the dylib. It is a good habit to
keep building the dylib with a recent standard version regardless.
With this patch, we also stop strictly enforcing that the targets are
built with C++23. Concretely, C++23 will soon be required in order to
build the dylib, but not enforcing it strictly works around some issues
like the documentation bots using an old and unsupported compiler. Since
these bots do not actually build the library, not strictly enforcing the
C++ Standard makes our CMake build more resilient to these kinds of
situation. This is just a workaround though, the better way of going
about would be to update the compiler on the documentation bot but we
don't seem to have control over that.
|
|
Android's librt and libpthread functionality is part of libc.{a,so}
instead. The atomic APIs are part of the compiler-rt builtins archive.
Android does have libdl.
Android's libc.so has `__cxa_thread_atexit_impl` starting in API 23, and
the oldest supported API is 21, so continue using feature detection for
that API.
These settings need to be declared explicitly for the sake of the fuzzer
library's custom libc++ build `add_custom_libcxx`. That macro builds
libc++ using `-DCMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY`, which
breaks the feature detection.
|
|
These tests do not need to be updated when making changes to the API.
|
|
This will allow for configuring tests according to AIX version.
Reviewed By: daltenty, #libc, Mordante
Differential Revision: https://reviews.llvm.org/D149660
|
|
This patch moves `VectorKind` to namespace scope, and make it complete at the point its bit-field is declared. It also converts it to a scoped enum.
|
|
This addresses issues found by https://lab.llvm.org/buildbot/#/builders/68/builds/62599 introduced in d71ac4b05bcf2804368ec7217a13c2c47fce7479
|
|
Leak could be real, as the code terminates before freeing the memory.
|
|
Mark tests as necessary to accommodate Android L (5.0 / API 21) and up.
Add three Android lit features:
- android
- android-device-api=(21,22,23,...)
- LIBCXX-ANDROID-FIXME (for failures that need follow-up work)
Enable an AIX workaround in filesystem_test_helper.h for the broken
chmod on older Android devices.
Mark failing test with XFAIL or UNSUPPORTED:
- Mark modules tests as UNSUPPORTED, matching other configurations.
- Mark a gdb test as UNSUPPORTED.
- XFAIL tests for old devices that lack an API (fmemopen).
- XFAIL various FS tests (because SELinux blocks FIFO and hard linking,
because fchmodat is broken on old devices).
- XFAIL various locale tests (because Bionic has limited locale
support). (Also XFAIL an re.traits test.)
- XFAIL some print.fun tests because the error exception has no system
error string.
- Mark std::{cin,wcin} tests UNSUPPORTED because they hang with
adb_run.py on old devices.
- Mark a few tests UNSUPPORTED because they allocate too much memory.
- notify_one.pass.cpp is flaky on Android.
- XFAIL libc++abi demangler test because of Android's special long
double on x86[-64].
N.B. The `__ANDROID_API__` macro specifies a minimum required API level
at build-time, whereas the android-device-api lit feature is the
detected API level of the device at run-time. The android-device-api
value will be >= `__ANDROID_API__`.
This commit was split out from https://reviews.llvm.org/D139147.
Fixes: https://github.com/llvm/llvm-project/issues/69270
|
|
I could probably break this commit into more pieces.
---
This patch adds libc++ support for Android L (Android 5.0+) and up,
tested using the Android team's current compiler, a recent version of
the AOSP sysroot, and the x86[-64] Android Emulator.
CMake and Lit Configuration:
Add runtimes/cmake/android/Arch-${ARCH}.cmake files that configure CMake
to cross-compile to Android without using CMake's built-in NDK support
(which only works with an actual packaged NDK).
Add libcxx/cmake/caches/AndroidNDK.cmake that builds and tests libc++
(and libc++abi) for Android. This file configures libc++ to match what
the NDK distributes, e.g.:
- libc++_shared.so (includes libc++abi objects, there is no
libc++abi.so). libunwind is linked statically but not exported.
- libc++_static.a (does not include libc++abi) and libc++abi.a
- `std::__ndk1` namespace
- All the libraries are built with `__ANDROID_API__=21`, even when they
are linked to something targeting a higher API level.
(However, when the Android LLVM team builds these components, they do
not use these CMake cache files. Instead they use Python scripts to
configure the builds. See
https://android.googlesource.com/toolchain/llvm_android/.)
Add llvm-libc++[abi].android-ndk.cfg.in files that test the Android
NDK's libc++_shared.so. These files can target old or new Android
devices. The Android LLVM team uses these test files to test libc++ for
both arm/arm64 and x86/x86_64 architectures.
The Android testing mode works by setting %{executor} to adb_run.py,
which uses `adb push` and `adb shell` to run tests remotely. adb_run.py
always runs tests as the "shell" user even on an old emulator where "adb
unroot" doesn't work. The script has workarounds for old Android
devices. The script uses a Unix domain socket on the host
(--job-limit-socket) to restrict concurrent adb invocations. Compiling
the tests is a major part of libc++ testing run-time, so it's desirable
to exploit all the host cores without overburdening the test devices,
which can have far fewer cores.
BuildKite CI:
Add a builder to run-buildbot, `android-ndk-*`, that uses Android Clang
and an Android sysroot to build libc++, then starts an Android emulator
container to run tests.
Run the emulator and an adb server in a separate Docker container
(libcxx-ci-android-emulator), and create a separate Docker image for
each emulator OS system image. Set ADB_SERVER_SOCKET to connect to the
container's adb server. Running the only adb server inside the container
makes cleanup more reliable between test runs, e.g. the adb client
doesn't create a `~/.android` directory and the adb server can be
restarted along with the emulator using docker stop/run. (N.B. The
emulator insists on connecting to an adb server and will start one
itself if it can't connect to one.)
The suffix to the android-ndk-* job is a label that concisely specifies
an Android SDK emulator image. e.g.:
- "system-images;android-21;default;x86" ==> 21-def-x86
- "system-images;android-33;google_apis;x86_64" ==> 33-goog-x86_64
Fixes: https://github.com/llvm/llvm-project/issues/69270
Differential Revision: https://reviews.llvm.org/D139147
|
|
(#69407)
This will make it easier to implement new(nothrow) without calling the
throwing version of new when exceptions are disabled. See
https://llvm.org/D150610 for the full discussion.
|
|
This makes it a lot easier to make wide ranging changes like I am
about to do in https://llvm.org/D150610.
|
|
Change aade74675c15d3bae5fdfa67f7b4b6ed9dac3d20 updated exception
handling in parts of libc++, but forgot to include <exceptions> in
cxa_demangle.cpp. This commit corrects that issue.
|
|
Since 78d649a417b48cb8a2ba2e755f0e7c8fb8b1bb83 the recommended way to
pass an executor is to use the _TEST_PARAMS variable, which means we now
pass more complicated value (including ones that may contain multiple
`=`) as part of this variable. However, the `REGEX REPLACE` being used
has greedy matches so everything up to the last = becomes part of the
variable name which results in invalid syntax in the generated lit
config file.
This was noticed due to builder failures for those using the
CrossWinToARMLinux.cmake cache file.
---------
Co-authored-by: Vladimir Vereschaka <vvereschaka@accesssoftek.com>
|
|
This is useful when trying to run multiple tests with different
arguments to the executor script. This is needed in my case since I
do not know the correct ssh connection arguments when building libc++.
The testing script I have spawns multiple QEMU instances that listen on
a given port on localhost and runs lit with the --num-shards/--run-shard
argument. In order to connect each shard to the right QEMU instances I
need to customize the arguments passed to ssh.py (--extra-ssh-args and
--extra-scp-args) but can't do this at configure time since the target
port is only known when running the tests but not when calling CMake.
This change allows me to pass `executor=ssh.py <args>` to lit once I
know
the right hostname/port for running the tests.
This also deprecates the `LIB{CXX,CXXABI,UNWIND}_EXECUTOR` CMake
variable
as the same can be achieved by adding `executor=...` to the
`LIB{CXX,CXXABI,UNWIND}_TEST_PARAMS` variable.
|
|
This adds Wasm-specific libc++abi changes to support Wasm exception
handling (https://github.com/WebAssembly/exception-handling).
Wasm EH requires `__USING_WASM_EXCEPTIONS__` to be defined. Wasm EH's
LSDA handling mostly shares that of SjLj EH.
Changes are:
- In Wasm, a destructor returns its argument.
- Wasm EH currently only has one phase (search) that does both search
and cleanup. So added an additional `set_registers` to support that.
The bulk of these changes was added back in Mar 2020 in
https://github.com/emscripten-core/emscripten/pull/10577 to emscripten
repo and has been used ever since. Now we'd like to upstream this so
that other toolchains that don't use emscripten libraries, e.g., WASI,
can use this too.
Companion patch: D158919
Reviewed By: dschuff, #libc_abi, phosek
Differential Revision: https://reviews.llvm.org/D158918
|
|
Since GCC now supports -nostdlib++, we can remove some complexity in the
test configurations and do the same as Clang. However, we can't fully
remove the GCC test configuration for libc++ because we apparently need
to explicitly link against libm for some tests to work.
|
|
We don't support these compilers anymore so these Lit annotations were
never used.
|
|
On Apple platforms, we always support the -nostdlib++ flag. Hence, it is
not necessary to manually link against system libraries. In fact, doing
so causes us to link against libSystem explicitly, which messes up with
the order of libraries we should use. Indeed:
Before patch, using the system unwinder (LIBCXXABI_USE_LLVM_UNWINDER = OFF)
===========================================================================
$ otool -L lib/{libc++.1.dylib,libc++abi.1.dylib,libunwind.1.dylib}
lib/libc++.1.dylib:
@rpath/libc++.1.dylib
/usr/lib/libSystem.B.dylib
@rpath/libc++abi.1.dylib
lib/libc++abi.1.dylib:
@rpath/libc++abi.1.dylib
/usr/lib/libSystem.B.dylib
lib/libunwind.1.dylib:
@rpath/libunwind.1.dylib
/usr/lib/libSystem.B.dylib
After patch, using the system unwinder (LIBCXXABI_USE_LLVM_UNWINDER = OFF)
===========================================================================
$ otool -L lib/{libc++.1.dylib,libc++abi.1.dylib,libunwind.1.dylib}
lib/libc++.1.dylib:
@rpath/libc++.1.dylib
@rpath/libc++abi.1.dylib
/usr/lib/libSystem.B.dylib
lib/libc++abi.1.dylib:
@rpath/libc++abi.1.dylib
/usr/lib/libSystem.B.dylib
lib/libunwind.1.dylib:
@rpath/libunwind.1.dylib
/usr/lib/libSystem.B.dylib
Before patch, with the LLVM unwinder (LIBCXXABI_USE_LLVM_UNWINDER = ON)
=======================================================================
$ otool -L lib/{libc++.1.dylib,libc++abi.1.dylib,libunwind.1.dylib}
lib/libc++.1.dylib:
@rpath/libc++.1.dylib
/usr/lib/libSystem.B.dylib
@rpath/libc++abi.1.dylib
@rpath/libunwind.1.dylib
lib/libc++abi.1.dylib:
@rpath/libc++abi.1.dylib
/usr/lib/libSystem.B.dylib
@rpath/libunwind.1.dylib
lib/libunwind.1.dylib:
@rpath/libunwind.1.dylib
/usr/lib/libSystem.B.dylib
After patch, with the LLVM unwinder (LIBCXXABI_USE_LLVM_UNWINDER = ON)
======================================================================
$ otool -L lib/{libc++.1.dylib,libc++abi.1.dylib,libunwind.1.dylib}
lib/libc++.1.dylib:
@rpath/libc++.1.dylib
@rpath/libc++abi.1.dylib
@rpath/libunwind.1.dylib
/usr/lib/libSystem.B.dylib
lib/libc++abi.1.dylib:
@rpath/libc++abi.1.dylib
@rpath/libunwind.1.dylib
/usr/lib/libSystem.B.dylib
lib/libunwind.1.dylib:
@rpath/libunwind.1.dylib
/usr/lib/libSystem.B.dylib
As we can see, libSystem appears before the just-built libraries before
the patch, which causes the libunwind.dylib bundled in libSystem.dylib
to be used instead of the just-built libunwind.dylib.
We didn't notice the issue until recently when I tried to update the
macOS CI builders to macOS 13.5, where it is necessary to use the right
libunwind library (the exact reason still needs to be investigated).
|
|
Fixed: https://github.com/llvm/llvm-project/issues/62127
https://reviews.llvm.org/D116203 introduced several compiler builtin
equivalents of the unary type traits. In some cases (e.g. template)
those builtin will be dependent and need to be mangle.
This patch add the check for `u{builtin}I{type}E` to demangle it.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D148465
|
|
This implements proposals from:
- https://github.com/itanium-cxx-abi/cxx-abi/issues/24: mangling for
constraints, requires-clauses, requires-expressions.
- https://github.com/itanium-cxx-abi/cxx-abi/issues/31: requires-clauses and
template parameters in a lambda expression are mangled into the <lambda-sig>.
- https://github.com/itanium-cxx-abi/cxx-abi/issues/47 (STEP 3): mangling for
template argument is prefixed by mangling of template parameter declaration
if it's not "obvious", for example because the template parameter is
constrained (we already implemented STEP 1 and STEP 2).
This changes the manglings for a few cases:
- Functions and function templates with constraints.
- Function templates with template parameters with deduced types:
`typename<auto N> void f();`
- Function templates with template template parameters where the argument has a
different template-head:
`template<template<typename...T>> void f(); f<std::vector>();`
In each case where a mangling changed, the change fixes a mangling collision.
Note that only function templates are affected, not class templates or variable
templates, and only new constructs (template parameters with deduced types,
constrained templates) and esoteric constructs (templates with template
template parameters with non-matching template template arguments, most of
which Clang still does not accept by default due to
`-frelaxed-template-template-args` not being enabled by default), so the risk
to ABI stability from this change is relatively low. Nonetheless,
`-fclang-abi-compat=17` can be used to restore the old manglings for cases
which we could successfully but incorrectly mangle before.
Fixes #48216, #49884, #61273
Reviewed By: erichkeane, #libc_abi
Differential Revision: https://reviews.llvm.org/D147655
|
|
LIBCXXABI_SHARED_LIBRARIES doesn't exist anymore, so this always expanded
to nothing at all.
|
|
Add UNSUPPORTED to pass tests on VE. VE uses SjLj libunwind, so
_Unwind_Backtrace and _Unwind_ForcedUnwind are not implemented.
Reviewed By: MaskRay, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D159446
|
|
Support VE in long double demangler. This patch corrects
libcxxabi/test/test_demangle.pass.cpp on VE.
Reviewed By: MaskRay, #libc_abi, ldionne
Differential Revision: https://reviews.llvm.org/D159004
|
|
the test suite
This is a follow up to https://reviews.llvm.org/D144694.
Fixes https://github.com/llvm/llvm-project/issues/60977.
Differential Revision: https://reviews.llvm.org/D144775
|
|
I'm making a change in this area (https://reviews.llvm.org/D138461), so update the test:
* Add proper synchronization instead of a sleep.
* Avoid some unnecessary size_t casts.
* Spawn the number of hardware threads instead of 10.
* Check that `__cxa_get_globals` and `__cxa_get_globals_fast` return
the same values.
* Split the test in with-threads and without-threads tests to simplify
the code.
Differential Revision: https://reviews.llvm.org/D138460
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
|
|
This reverts commit 31cc069b5f4cb1b120c72f4dcbaa1b5a212120df.
|
|
Fixed: https://github.com/llvm/llvm-project/issues/62127
https://reviews.llvm.org/D116203 introduced several compiler builtin
equivalents of the unary type traits. In some cases (e.g. template) those
builtin will be dependent and need to be mangle.
This patch add the check for `u{builtin}I{type}E` to demangle it.
Reviewed By: rjmccall
Differential Revision: https://reviews.llvm.org/D148465
|
|
This commit contains refactorings around __dynamic_cast without changing
its behavior. Some important changes include:
- Refactor __dynamic_cast into various small helper functions;
- Move dynamic_cast_stress.pass.cpp to libcxx/benchmarks and refactor
it into a benchmark. The benchmark performance numbers are updated
as well.
Differential Revision: https://reviews.llvm.org/D138006
|
|
https://reviews.llvm.org/D138460 touches that test a bunch, so we might
as well clang-format it first.
|
|
Inside the Itanium demangler, we would previously call std::terminate()
after failing to (re)allocate. However, programs are free to install a
custom terminate_handler which does non-trivial things. In fact, by
default libc++abi itself installs a demangling_terminate_handler() which
tries to demangle the currently active exception before aborting the
program.
In case of an out-of-memory exception caused by the system truly having
no more memory (as opposed to attempting to allocate INT_MAX just once),
we will end up trying to demangle the exception, failing to do so because
we can't grow the OutputBuffer inside ItaniumDemangle.h, and then calling
std::terminate() there. That will call the demangling_terminate_handler(),
which will then start this loop again. We eventually end up crashing due
to a stack overflow.
To fix this problem, this patch calls std::abort() directly from the
demangler instead of going through std::terminate(). After all, calling
std::abort() is the default behavior for std::terminate() according
to the Standard, so this behavior is definitely valid. The downside of
this approach is that in case of a "true" out-of-memory condition:
1. the program will throw an exception
2. std::terminate() will be called if uncaught
3. demangling_terminate_handler() will be called and will fail
4. abort() will be called
We'll end up aborting the program without mentioning the cause, which
normally looks like:
terminating due to uncaught exception of type <TYPE>: <what()-MESSAGE>
Another option would be to properly handle failure-to-allocate inside
ItaniumDemangle.h and to propagate something like an error code or a
std::expected to the caller of all functions in the demangler that
can allocate. Then, we could make sure that __cxa_demangle returns
nullptr when it fails to demangle the input due to any error, as it is
supposed to (but today "true" out-of-memory conditions are not handled
properly). The demangling_terminate_handler() would then see that
__cxa_demangle failed to do its job and would still print the
appropriate message, simply using the non-demangled exception type.
However, this is akin to a partial rewrite of the demangler code since
a large number of functions would now have to return a std::expected
to account for out-of-memory conditions.
Using exceptions would be a lot simpler in terms of code changes and
would achieve the same result, however the demangler can't use exceptions
because it is used inside LLVM and libc++abi implements the exception
runtime anyway (so while it might be possible to use them in that
context, I'd argue we'd only be playing with fire).
rdar://110767664
Differential Revision: https://reviews.llvm.org/D155598
|
|
Those fixes were taken from https://reviews.llvm.org/D137338.
|
|
If we attempt to use unwind_shared when LIBUNWIND_ENABLE_SHARED is OFF,
we'll get link errors. LIBCXXABI_STATICALLY_LINK_UNWINDER_IN_SHARED_LIBRARY
avoids that, but it seems redundant to have to specify it manually.
Automatically switch libunwind statically when its shared build is
disabled, which also matches compiler-rt [1].
[1] https://github.com/llvm/llvm-project/blob/71bfec762bd970e7834f58c158ddc15f93402d7a/compiler-rt/CMakeLists.txt#L238-L240
Reviewed By: #libc_abi, phosek
Differential Revision: https://reviews.llvm.org/D158789
|
|
This patch fixes a few CMake options that were set using incorrect
mechanisms.
CMake's man page for the -D <var>=<value> option states: If a command in
the project sets the type to PATH or FILEPATH, then the <value> will be
converted to an absolute path. That's not what we want for most of the
paths we have as configuration options. Otherwise, using -D to set the
configuration option results in an absolute path being used, which
breaks things.
option() denotes a boolean variable, but what was desired was a
string/list variable. Fix this to prevent cmake from changing any
non-empty user provided values to 'ON'.
Differential Revision: https://reviews.llvm.org/D157926
|
|
Reviewed By: #libc, #libc_abi, Mordante
Spies: arphaman, Mordante, libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D157060
|
|
|
|
|
|
Our threading support layer is currently a huge mess. There are too many
configurations with too many confusing names, and none of them are tested
in the usual CI. Here's a list of names related to these configurations:
LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY
_LIBCPP_BUILDING_THREAD_LIBRARY_EXTERNAL
LIBCXXABI_BUILD_EXTERNAL_THREAD_LIBRARY
_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
LIBCXX_HAS_EXTERNAL_THREAD_API
_LIBCPP_HAS_THREAD_API_EXTERNAL
This patch cleans this up by removing the ability to build libc++ with
an "external" threading library for testing purposes, removing 4 out of
6 "names" above. That setting was meant to be used by libc++ developers,
but we don't use it in-tree and it's not part of our CI.
I know the ability to use an external threading API is used by some folks
out-of-tree, and this patch doesn't change that. This only changes the
way they will have to test their external threading support. After this
patch, the intent would be for them to set `-DLIBCXX_HAS_EXTERNAL_THREAD_API=ON`
when building the library, and to provide their usual `<__external_threading>`
header when they are testing the library. This can be done easily now
that we support custom lit configuration files in test suites.
The motivation for this patch is that our threading support layer is
basically unmaintainable -- anything beyond adding a new "backend" in
the slot designed for it requires incredible attention. The complexity
added by this setting just doesn't pull its weigh considering the
available alternatives.
Concretely, this will also allow future patches to clean up
`<__threading_support>` significantly.
Differential Revision: https://reviews.llvm.org/D154466
|
|
To fix expensive check builds that were failing when using MSVC's
std::string_view::iterator::operator*, I added a few expressions like
&*std::string_view::begin. @nico pointed out that this is literally the
same thing and more clearly expressed as std::string_view::data.
Link: https://github.com/llvm/llvm-project/issues/63740
Reviewed By: #libc_abi, ldionne, philnik, MaskRay
Differential Revision: https://reviews.llvm.org/D154876
|
|
|
|
This allows mechanically copying any changes made to `operator new`
from libc++ into libc++abi as-is. This is also a step towards
de-duplicating this code entirely.
Differential Revision: https://reviews.llvm.org/D153035
|
