Summary:
In r342843, I added deprecation warnings to some facilities that were
deprectated in C++14 and C++17. However, those deprecation warnings
were not enabled by default.
After discussing this on IRC, we had finally gotten consensus to enable
those warnings by default, and I'm getting around to doing that only
now.
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D58140
llvm-svn: 355961
When Clang tries to complete a type containing `std::optional` it
considers the `in_place_t` constructor with no arguments which checks
if the value type is default constructible. If the value type is a
nested class type, then this check occurs too early and poisons the
is_default_constructible trait.
This patch makes optional deduce `in_place_t` so we can prevent
this early SFINAE evaluation. Technically this could break people
doing weird things with the in_place_t tag, but that seems less
important than making the nested class case work.
llvm-svn: 355877
Summary:
I can't think of a reason for shipping this empty header. If there is
a reason to do so, then hopefully this review can uncover it.
Reviewers: mclow.lists, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59137
llvm-svn: 355829
Patch by Arthur O'Dwyer.
Reviewed as https://reviews.llvm.org/D47344
new_delete_resource().allocate(n, a) has basically two permissible results:
* Return an appropriately sized and aligned block.
* Throw bad_alloc.
Before this patch, libc++'s new_delete_resource would do a third and impermissible thing, which was
to return an appropriately sized but inappropriately under-aligned block. This is now fixed.
(This came up while I was stress-testing unsynchronized_pool_resource on my MacBook. If we can't
trust the default resource to return appropriately aligned blocks, pretty much everything breaks.
For similar reasons, I would strongly support just patching __libcpp_allocate directly, but I don't
care to die on that hill, so I made this patch as a <memory_resource>-specific workaround.)
llvm-svn: 355763
When dllimport is specified on a class, and
exclude_from_explicit_instatiation is specified on a member, clang-cl
will still expect a definition to be available externally. But this is
not correct.
Surprisingly one one symbol seems to be consistently affected by this
bug. So this patch simply works around it there.
llvm-svn: 355760
This reverts commit r355764.
CMake does not turn -fPIC on for us by default. so this patch breaks
standalone builds. The only reason it hasn't broken any bots is because
LLVM turns on and specifies '-fPIC' for us.
llvm-svn: 355756
Summary:
We need to pin the underlying type of C++20' `std::memory_order` to match the C++17 version. Anything less is an ABI break.
At the moment it's `unsigned` before C++20 and `int` after. Or if you're using `-fshort-enums` it's `unsigned char` before C++20 and `int` after.
This patch explicitly specifies the underlying type of the C++20 `memory_order` to be w/e type the compiler would have chosen for the C++17 version.
Reviewers: mclow.lists, ldionne
Reviewed By: ldionne
Subscribers: jfb, jdoerfert, #libc, zoecarver
Differential Revision: https://reviews.llvm.org/D59063
llvm-svn: 355755
comparator for std::sort()
Our debug comparator assumed that the comparator it wraps would always
accepts the values by const ref. This isn't required by the standard.
This patch makes our __debug_less comparator forward the constness.
llvm-svn: 355752
Summary:
Whether we build with -fPIC should be specified by the
CMAKE_POSITION_INDEPENDENT_CODE option at configure time.
Note that this patch doesn't change the behavior when building
by default, since -fPIC is used for shared libraries by default.
Reviewers: EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59146
llvm-svn: 355746
This change is a consequence of the discussion in "RFC: Place libs in
Clang-dedicated directories", specifically the suggestion that
libunwind, libc++abi and libc++ shouldn't be using Clang resource
directory. Tools like clangd make this assumption, but this is
currently not true for the LLVM_ENABLE_PER_TARGET_RUNTIME_DIR build.
This change addresses that by moving the output of these libraries to
lib/<target> and include/ directories, leaving resource directory only
for compiler-rt runtimes and Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D59013
llvm-svn: 355665
The issue is the following code:
__cn1->__add(*__ip);
(*__ip)->__c_ = __cn1;
`__ip` points into the array of iterators for container `__cn2`. This code adds
the iterator to the array of iterators for `__cn1`, and updates the iterator to
point to the new container.
This code works fine, except when `__cn1` and `__cn2` are the same container.
`__cn1->__add()` might need to grow the array of iterators, and when it does,
`__ip` becomes invalid, so the second line becomes a use-after-free error.
Simply swapping the order of the above two lines is not sufficient, because of
the memmove() below. The easiest and most performant solution is just to skip
touching any iterators if the containers are the same.
Differential Revision: https://reviews.llvm.org/D58926
llvm-svn: 355550
Summary:
Currently, libc++'s `<stdexcept>` doesn't play nice with `vcruntime`. Specifically:
* `logic_error` and `runtime_error` have a different layout.
* libc++'s `logic_error` and `runtime_error` override `what()` but `vcruntime` does not.
* `vcruntime` uses weak vtables for `<stdexcept>` types.
* libc++'s `<stdexcept>` constructors and assignment operators may have different manglings than `vcruntimes`.
This patch makes libc++'s declarations in `<stdexcept>` match those provided by MSVC's STL as closely as possible.
If MSVC doesn't declare a special member, then neither do we. This ensures that the implicit definitions have the same linkage, visibility, triviality, and noexcept-ness.
Reviewers: thomasanderson, ldionne, smeenai
Reviewed By: thomasanderson
Subscribers: jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D58945
llvm-svn: 355546
Summary:
This breaks ABI for folks using -fshort-enums, and does not really buy
us anything.
http://llvm.org/PR40977
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits, zoecarver
Differential Revision: https://reviews.llvm.org/D59029
llvm-svn: 355521
Otherwise, when testing trunk libc++ on an older system, lit will think
that the dylib features are disabled. Ideally, we'd have a notion of
running the tests with/without a deployment target (or, equivalently,
a deployment target representing trunk where everything is as recent
as can be). Since we always have a deployment target right now (which
defaults to the current system), we only enable those features when
we're going to also be testing with the system libc++.
We also need to disable the availability markup when we are not running
a system library flavor, because availability markup does not make sense
when building against the trunk libc++ (which has everything regardless
of what the current system is).
This is a re-application of r353319, which had been reverted due to
CI breakage. This time around, I made sure it didn't break our internal
CI before submitting.
This is also a partial undoing of r348296, in spirit at least. However,
with this patch, availability markup is enabled based on whether we're
using a system library or not, whereas previously one could enable
it or disable it arbitrarily. This was confusing as it led to testing
configurations that don't make sense (such as testing a system library
without availability markup, or trunk testing with availability markup).
llvm-svn: 355451
Revert "[libc++] Fix <atomic> failures on GCC"
Revert "[libc++] Change memory_order to an enum class"
Revert "[libc++] decoupling Freestanding atomic<T> from libatomic.a"
The lldb formatter nededs to be updated. Shafik and Louis will
coordinate to do so.
llvm-svn: 355417
Summary:
In https://reviews.llvm.org/D58201, we turned memory_order into an enum
class in C++20 mode. However, we were not casting memory_order to its
underlying type correctly for the GCC implementation, which broke the
build bots. I also fixed a test that was failing in C++17 mode on GCC 5.
Reviewers: EricWF, jfb, mclow.lists
Subscribers: zoecarver
Differential Revision: https://reviews.llvm.org/D58966
llvm-svn: 355409
Summary:
This patch fixes a lifetime bug when inserting a new container into the debug database. It is
diagnosed by UBSAN when debug mode is enabled. This patch corrects how nodes are constructed
during insertion.
The fix requires unconditionally breaking the debug mode ABI. Users should not expect ABI
stability from debug mode.
Reviewers: ldionne, serge-sans-paille, EricWF
Reviewed By: EricWF
Subscribers: mclow.lists, christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D58011
llvm-svn: 355367
Summary:
On Windows we currently provide two separate ABI configurations. One which defers to `vcruntime` to provide the C++ runtime and another which doesn't.
Using `vcruntime` allows interoperability which programs compiled against the MSVC STL, and should be preferred whenever possible.
When deferring to `vcruntime` much of the ABI we provide changes. Including the layout of `<stdexcept>` types, their vtables, and how the linkage of their members.
This patch introduces the `_LIBCPP_ABI_VCRUNTIME` macro to denote this configuration. It also cleans up the existing configuration for using `vcruntime`.
This cleanup lays the groundwork for fixing a number of ABI and interoperability bugs in `<stdexcept>`.
Reviewers: thomasanderson, ldionne, smeenai
Reviewed By: smeenai
Subscribers: jdoerfert, libcxx-commits, #libc
Differential Revision: https://reviews.llvm.org/D58942
llvm-svn: 355366
LLVM is dropping support for GCC 4.9. This patch adds
a GCC 5 installation to the buildbot image so we can upgrade
the 4.9 bot to GCC 5.
As a temporary workaround until zorg updates, we install GCC 5
as GCC 4.9.
llvm-svn: 355334
This patch introduces non-lockfree atomics that do not require using
an external libatomic. This work is done with the long-term goal of
allowing the use of <atomic> in freestanding environments.
Thanks to Olivier Giroux for the patch.
Differential Revision: https://reviews.llvm.org/D56913
llvm-svn: 355318
Do not assume that xalloc() starts at 0, which is not specified by the
Standard.
Thanks to Andrey Maksimov for the patch.
Differential Revision: https://reviews.llvm.org/D58299
llvm-svn: 355160
Those tests fail when linking against a new dylib but running against
macosx10.7. I believe this is caused by a duplicate definition of the
RTTI for exception classes in libc++.dylib and libc++abi.dylib, but
this matter still needs some investigation.
This issue was not caught previously because all the tests always linked
against the same dylib used for running (because LIT made it impossible
to do otherwise before r349171).
rdar://problem/46809586
llvm-svn: 354940
Summary:
For consistency, libc++ macros always start with _LIBCPP. This should
have no functionality change.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D58558
llvm-svn: 354848
Louis Dionne