Summary:
The type timespec is unconditionally used in __threading_support.
Since the C library is only required to provide it in C11, this might
cause problems for platforms with external thread porting layer (i.e.
when _LIBCPP_HAS_THREAD_API_EXTERNAL is defined) with pre-C11
C libraries.
In our downstream port of libc++ we used to provide a definition of
timespec in __external_threading, but this solution is not ideal
because timespec is not a reserved name.
This patch renames timespec into __libcpp_timespec_t in the
thread-related parts of libc++. For all cases except external
threading this type is an alias for ::timespec (and no functional
changes are intended).
In case of external threading it is expected that the
__external_threading header will either provide a similar typedef (if
timespec is available in the vendor's C library) or provide a
definition of __libcpp_timespec_t compatible with POSIX timespec.
Reviewers: ldionne, mclow.lists, EricWF
Reviewed By: ldionne
Subscribers: dexonsmith, libcxx-commits, christof, carwil
Tags: #libc
Differential Revision: https://reviews.llvm.org/D63328
llvm-svn: 364012
This is a re-application of r362986 (which was reverted in r363688) with fixes
for the issue that caused it to be reverted.
Thanks to Arthur O'Dwyer for the patch.
Differential Revision: https://reviews.llvm.org/D58587
llvm-svn: 363968
Summary:
AIX system headers need stdint.h and inttypes.h to be re-enterable when macro _STD_TYPES_T is defined so that limit macro definitions such as UINT32_MAX can be found. This patch attempts to allow that on AIX.
Reviewers: hubert.reinterpretcast, jasonliu, mclow.lists, EricWF
Reviewed by: hubert.reinterpretcast, mclow.lists
Subscribers: jfb, jsji, christof, cfe-commits, libcxx-commits, llvm-commits
Tags: #LLVM, #clang, #libc++
Differential Revision: https://reviews.llvm.org/D59253
llvm-svn: 363939
This was found to be broken on Clang trunk. This is a revert of the
following commits (the subsequent commits added XFAILs to the tests
that were missing from the original submission):
r362986: Implement deduction guides for map/multimap.
r363014: Add some XFAILs
r363097: Add more XFAILs
r363197: Add even more XFAILs
llvm-svn: 363688
Summary:
The class ctype_base in the header <__locale> contains masks for
character classification functions, which are kept in sync with
platform's C library, hence it contains many special cases.
The value of the bit mask __regex_word in the header <regex> must not
clash with those bit masks.
Currently the default case (i.e. unknown platform/C library) is
handled incorrectly: the __regex_word clashes with ctype_base::punct.
To avoid replicating the whole list of platforms in <regex> this patch
defines __regex_word in <__locale>, so that it is always kept in sync
with other masks.
Reviewers: ldionne, mclow.lists, EricWF
Reviewed By: ldionne
Subscribers: krytarowski, christof, dexonsmith, pbarrio, simon_tatham, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D63284
llvm-svn: 363363
Summary:
This patch make G++03 explicitly unsupported with libc++, as discussed on the mailing lists.
Below is the rational for this decision.
----------------------------------------------------------------------------------------------------
libc++ claims to support GCC with C++03 ("G++03"), and this is a problem for our users.
Our C++03 users are all using Clang. They must be. Less than 9% of the C++03 tests pass with GCC [1][2]. No non-trivial C++ program could work.
Attempting to support G++03 impacts our QoI considerably. Unlike Clang, G++03 offers almost no C++11 extensions. If we could remove all the fallbacks for G++03, it would mean libc++ could::
* Improve Correctness:
Every `#ifdef _LIBCPP_HAS_NO_<C++11-feature>` is a bug manifest. It exists to admit for deviant semantics.
* Achieve ABI stability between C++03 and C++11
Differences between our C++03 and C++Rest branches contain ABI bugs. For example `std::nullptr_t` and `std::function::operator()(...)` are currently incompatible between C++11 and C++03, but could be fixed.
* Decrease Compile Times and Memory Usage:
Writing efficient SFINAE requires C++11. Using alias templates, libc++ could reduce the number of instantiations it produces substantially.
* Decrease Binary Size
Similar to the last point, G++03 forces metaprogramming techniques that emit more debug information [3] [4]. Compared to libstdc++, debug information size increases of +10% are not uncommon.
Reviewers: ldionne, mclow.lists, EricWF
Reviewed By: ldionne, EricWF
Subscribers: zoecarver, aprantl, dexonsmith, arphaman, libcxx-commits, #libc
Differential Revision: https://reviews.llvm.org/D63154
llvm-svn: 363219
When applied to a typedef or alias template, the [[nodebug]] attribute
makes the typedef transparent to the debugger, so instead of seeing
`std::__function::__alloc_func<remove_reference<void(&)()>::type,
allocator<remove_reference<void(&)()>, void()>::_Target` you see
`void(&)()` as the type of the variable in your debugger.
Removing all this SFINAE noise from debug info has huge binary size
wins, in addition to improving the readability.
For now this change is on by default. Users can override it by
specifying -D_LIBCPP_NODEBUG_TYPE=
llvm-svn: 363117
Summary:
This is not mandated by the Standard, but it's nonetheless a nice
property to have, especially since it's so easy to implement. It
also shrinks our bug list!
PR41714
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D62618
llvm-svn: 363075
Summary:
Following the discussion on the libcxx-dev mailing list
(http://lists.llvm.org/pipermail/libcxx-dev/2019-May/000358.html),
this implements the new policy for handling experimental features and
their deprecation. We basically add a deprecation warning for
std::experimental::filesystem, and we remove a bunch of <experimental/*>
headers that were now empty.
Reviewers: mclow.lists, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, arphaman, libcxx-commits, jfb
Tags: #libc
Differential Revision: https://reviews.llvm.org/D62428
llvm-svn: 363072
std::function uses a standard allocator to manage its memory, however
standard allocators are templates and using them correctly requires
a stupid amount of instantiations. This leads to a substantial increase
in debug info and object sizes.
This patch addresses the issue by dropping the allocator when possible
and using raw new and delete to get memory.
This change decreases the object file size for the test func.wrap.func.con/F.pass.cpp by 33% and the final binary by 29% (when compiled with -g -ggnu-pubnames -gpubnames).
It also roughly halfs the number of entries in the pubnames and pubtype
sections.
llvm-svn: 362865
merged type info names.
Previously std::type_info always expected type info string to be unique.
But this isn't always the case. Like when -Bsymbolic is passed to the
linker or due to llvm.org/PR37398.
This patch adds the LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT CMake
option which, when specified, overrides the default configuration for
the library.
The current defaults still assume unique names even though this isn't
strictly correct for ELF binaries. We should consider changing the
default in a follow up commit.
llvm-svn: 361913
Summary:
This provides the `std::destroying_delete_t` declaration in C++2a and after. (Even when the compiler doesn't support the language feature).
However, the feature test macro `__cpp_lib_destroying_delete` is only defined when we have both language support and C++2a.
Reviewers: ldionne, ckennelly, serge-sans-paille, EricWF
Reviewed By: EricWF
Subscribers: dexonsmith, riccibruno, christof, jwakely, jdoerfert, mclow.lists, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D55840
llvm-svn: 361572
Summary: On some platforms C++ headers are packaged with the compiler not the sysroot. If you don't copy C++ headers into the build include directory during configuraiton of the outer build the C++ check during the runtime configuration may get inaccurate results.
Reviewers: phosek, compnerd, smeenai, EricWF
Reviewed By: compnerd
Subscribers: EricWF, christof, libcxx-commits, mgorny, llvm-commits
Tags: #llvm, #libc
Differential Revision: https://reviews.llvm.org/D62155
llvm-svn: 361513
The `using namespace std;` opens us up to ambiguity
when any of the std:: names are also present in the global namespace.
Instead we should properly qualify names we use from std::.
llvm-svn: 361074
This adds explicit support for the WASI platform to libcxx.
WASI libc uses some components from musl, however it's not fully compatible
with musl, so we're planning to stop using _LIBCPP_HAS_MUSL_LIBC and
customize for WASI libc specifically.
Differential Revision: https://reviews.llvm.org/D61336
Reviewers: sbc100, ldionne
llvm-svn: 359703
Summary:
The current implementation of aligned storage was written before we had `alignas`, so it used a list of builtin types to force the alignment. But this doesn't work overaligned requests.
This patch adds a fallback case supporting over-alignment. It only affects case that were previously ill-formed.
Reviewers: rsmith, ldionne, dlj, mclow.lists
Reviewed By: mclow.lists
Subscribers: mclow.lists, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D61301
llvm-svn: 359596
When the arguments to tuple cat were const, the const was incorrectly
propagated into the type of the resulting tuple. For example:
const std::tuple<int> t(42);
auto r = std::tuple_cat(t, t);
// Incorrect! should be std::tuple<int, int>.
static_assert(is_same_v<decltype(r), std::tuple<const int, const int>>);
llvm-svn: 359255
libc++ ABI v1 provides three valarray symbols as part of the shared library:
valarray<size_t>::valarray(size_t)
valarray<size_t>::~valarray()
valarray<size_t>::resize(size_t, size_t)
The first two of these are intended to be removed in V2 of the ABI: they're
attributed _LIBCPP_HIDE_FROM_ABI_AFTER_V1, and it appears that the intention
is that these symbols from the library are not used even when building using
the V1 ABI. However, there are explicit instantiation declarations for all
three symbols in the header, which are not correct as we do not intend to find
an instantiation of these functions that is provided elsewhere.
(A recent change to clang to properly diagnose explicit instantiation
declarations of internal linkage functions -- required by [temp.explicit]p13 --
had to be rolled back because it diagnosed these explicit instantiations.)
Remove the explicit instantiation declarations, and remove the explicit
instantiation definitions for V2 of the libc++ ABI onwards.
llvm-svn: 359243
std::mutex was not actually is_nothrow_default_constructible in C++98/C++03,
because the variable declaration
std::mutex M;
... could throw an exception from the mutex destructor. Fix it by marking the
destructor as non-throwing. This has no effect in C++11 onwards, because
destructors are non-throwing by default in those language modes.
llvm-svn: 359229
Contrary to MSVC, MinGW compilers wants the dllexport attribute on
the declaration of an explicit template instantiation, not on the
definition.
Differential Revision: https://reviews.llvm.org/D61123
llvm-svn: 359227
Teach libcxx to stop using various deprecated __has_* type traits, in favor of
the ("modern", C++11 era) __is_* type traits.
This is mostly just a simplification, but fixes at least one bug: _Atomic T
should be considered trivially-destructible, but is not considered to be POD by
Clang, and __has_trivial_destructor is specified in the GCC documentation as
returning false for non-POD non-class types.
Differential Revision: https://reviews.llvm.org/D48292
llvm-svn: 359159
Summary:
All overloads of `::abs` and `std::abs` must be present in both `<cmath>` and `<cstdlib>`. This is problematic to implement because C defines `fabs` in `math.h` and `labs` in `stdlib.h`. This introduces a circular dependency between the two headers.
This patch implements that requirement by moving `abs` into `math.h` and making `stdlib.h` include `math.h`. In order to get the underlying C declarations from the "real" `stdlib.h` inside our `math.h` we need some trickery. Specifically we need to make `stdlib.h` include next itself.
Suggestions for a cleaner implementation are welcome.
Reviewers: mclow.lists, ldionne
Reviewed By: ldionne
Subscribers: krytarowski, fedor.sergeev, dexonsmith, jdoerfert, jsji, libcxx-commits
Differential Revision: https://reviews.llvm.org/D60097
llvm-svn: 359020
This is a followup to [1] which added a new `__debug_less::operator()` overload.
[2] added `_LIBCPP_CONSTEXPR_AFTER_CXX17` to the original
`__debug_less::operator()` between the time of writing [1] and landing it. This
change adds `_LIBCPP_CONSTEXPR_AFTER_CXX17` to the new overload too.
[1] https://reviews.llvm.org/rL358423
[2] https://reviews.llvm.org/rL358252
Differential Revision: https://reviews.llvm.org/D60724
llvm-svn: 358725
This used to be guarded on whether the deployment target was greater
than macosx10.8, however testing against the dylibs for 10.8 and earlier
with the function enabled works too. The revision that introduced
__pad_and_output is r164241 and it does not mention a reason for the
guard.
llvm-svn: 358677
Summary:
Otherwise, we can run into problems when the program has static variables
that need to use the debug database during their deinitialization, if
the debug DB has already been deinitialized.
Reviewers: EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60830
llvm-svn: 358602
There are many STL algorithms (such as lexicographical_compare) that compare
values pointed to by iterators like so:
__comp(*it1, *it2);
When building with `_LIBCPP_DEBUG=0`, comparators are wrapped in `__debug_less`
which does some additional validation. But `__debug_less::operator()` takes
non-const references, so if the type of `*it1` is int, not int&, then the build
will fail.
This change adds a `const&` overload for `operator()` to fix the build.
Differential Revision: https://reviews.llvm.org/D60592
llvm-svn: 358423
Instead of having an `#if` block in every algorithm using a debug
comparator, this patch introduces the __comp_ref_type trait that
selects __debug_less in debug mode and _Comp& otherwise.
This patch should have no observable functionality change.
llvm-svn: 358252
Summary:
In r348529, I improved the library-defined diagnostic for using containers
with a non-const comparator/hasher. However, the check is now performed
too early, which leads to the diagnostic being emitted in cases where it
shouldn't. See PR41360 for details.
This patch moves the diagnostic to the destructor of the containers, which
means that the diagnostic will only be emitted when the container is instantiated
at a point where the comparator and the key/value are required to be complete.
We still retain better diagnostics than before r348529, because the diagnostics
are performed in the containers themselves instead of __tree and __hash_table.
As a drive-by fix, I improved the diagnostic to mention that we can't find
a _viable_ const call operator, as suggested by EricWF in PR41360.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits, zoecarver
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60540
llvm-svn: 358189
Summary:
This is a re-application of r357533 and r357531. They had been reverted
because we thought the commits broke the LLDB data formatters, but it
turns out this was because only r357531 had been included in the CI
run.
Before this patch, we would only ever throw an exception if the badbit
was set on the stream. The Standard is currently very unclear on how
exceptions should be propagated and what error flags should be set by
the input stream operations. This commit changes libc++ to behave under
a different (but valid) interpretation of the Standard. This interpretation
of the Standard matches what other implementations are doing.
This effectively implements the wording in p1264r0. It hasn't been voted
into the Standard yet, however there is wide agreement that the fix is
correct and it's just a matter of time before the fix is standardized.
PR21586
PR15949
rdar://problem/15347558
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D49863
llvm-svn: 357775
This builds on the work done in r342808 and adds _LIBCPP_NODISCARD_EXT
to 37 more functions, namely:
adjacent_find, all_of, any_of, binary_search, clamp, count_if, count,
equal_range, equal, find_end, find_first_not_of, find_first_of, find_if,
find, includes, is_heap_until, is_heap, is_partitioned, is_permutation,
is_sorted_until, is_sorted, lexicographical_compare, lower_bound,
max_element, max, min_element, min, minmax_element, minmax, mismatch,
none_of, remove_if, remove, search_n, search, unique, upper_bound
The motivation here is that we noticed that find_if is nodiscard with
Visual Studio's standard library, and we deemed that useful
(https://crbug.com/948122).
https://devblogs.microsoft.com/cppblog/c17-progress-in-vs-2017-15-5-and-15-6/
says "Our criteria for emitting the warning are: discarding the return
value is a guaranteed leak [...], discarding the return value is
near-guaranteed to be incorrect (e.g. remove()/remove_if()/unique()), or
the function is essentially a pure observer (e.g. vector::empty() and
std::is_sorted())." so I went through algorithm and tried to apply these
criteria.
Some of these, like vector::empty() are already nodiscard per C++
standard and didn't need changing.
I didn't (yet?) go over std::string::find* methods which should probably
have _LIBCPP_NODISCARD_EXT too (but not as part of this change).
Differential Revision: https://reviews.llvm.org/D60145
llvm-svn: 357619
Summary:
Otherwise, std::is_pointer<id __strong> works, but std::is_pointer<id __weak>
(and others) don't work as expected.
The previous patch (r357517) had to be reverted in r357569 because it
broke the Chromium build. This patch shouldn't have the same problem.
rdar://problem/49126333
Reviewers: ahatanak, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D60087
llvm-svn: 357586
This reverts commits r357533 and r357531, which broke the LLDB
data formatters. I'll hold off until we know how to fix the data
formatters accordingly.
llvm-svn: 357536
Summary:
Before this patch, we would only ever throw an exception if the badbit
was set on the stream. The Standard is currently very unclear on how
exceptions should be propagated and what error flags should be set by
the input stream operations. This commit changes libc++ to behave under
a different (but valid) interpretation of the Standard. This interpretation
of the Standard matches what other implementations are doing.
I will submit a paper in San Diego to clarify the Standard such that the
interpretation used in this commit (and other implementations) is the only
possible one.
PR21586
PR15949
rdar://problem/15347558
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D49863
llvm-svn: 357531
The current definitions were entirely broken. They didn't call any
existing constructor and the forgot to friend the expression types they
were trying to construct.
llvm-svn: 357453
Summary:
Currently the C++03 implementation of common_type has much different behavior than the C++11 one. This causes bugs, including inside `<chrono>`.
This patch unifies the two implementations as best it can. The more code they share, the less their behavior can diverge.
Reviewers: mclow.lists, ldionne, sbenza
Reviewed By: mclow.lists, ldionne
Subscribers: libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D59678
llvm-svn: 357370
The old implementation assumed the POSIX `setlocale()` API where the old
locale is returned. On Windows, the _new_ locale is returned. This meant
that `__libcpp_locale_guard` wasn't resetting the locale on destruction.
The new implementation fixes the above issue and takes advantage of
`setlocale(LC_ALL)` to reduce the number of calls, and also avoids setting
the locale at all if it's not necessary.
Differential Revision: https://reviews.llvm.org/D59572
llvm-svn: 357104
Summary:
Adds the coroutine `std::experimental::task<T>` type described in proposal P1056R0.
See https://wg21.link/P1056R0.
This implementation allows customization of the allocator used to allocate the
coroutine frame by passing std::allocator_arg as the first argument, followed by
the allocator to use.
This supports co_awaiting the same task multiple times. The second and
subsequent times it returns a reference to the already-computed value.
This diff also adds some implementations of other utilities that have potential for
standardization as helpers within the test/... area:
- `sync_wait(awaitable)` - See P1171R0
- `manual_reset_event`
Move the definition of the __aligned_allocation_size helper function
from <experimental/memory_resource> to <experimental/__memory>
so it can be more widely used without pulling in memory_resource.
Outstanding work:
- Use C++14 keywords directly rather than macro versions
eg. use `noexcept` instead of `_NOEXCEPT`).
- Add support for overaligned coroutine frames.
This may need wording in the Coroutines TS to support passing the extra `std::align_val_t`.
- Eliminate use of `if constexpr` if we want it to compile under C++14.
Patch by @lewissbaker (Lewis Baker).
llvm-svn: 357010
_LIBCPP_TYPE_VIS is only really needed on types with a vtable.
And on Windows it doesn't work with types that have only inline methods.
This patch removes the unneeded attributes.
llvm-svn: 356637
`unsigned long` is 32-bit on 32-bit systems and 64-bit on 64-bit systems
on LP64 systems -- which most Unix systems are, but Windows isn't.
Windows is LLP64, which means unsigned long is 32-bit even on 64-bit
systems.
pplwin.h contains
static_assert(alignof(void *) == alignof(::std::once_flag), ...)
which fails due to this problem.
Instead of unsigned long, use uintptr_t, which consistently is 32-bit
on 32-bit systems and 64-bit on 64-bit systems.
No functional change except on 64-bit Windows.
Differential Revision: https://reviews.llvm.org/D59607
llvm-svn: 356624
Summary:
Also add the corresponding XFAILs to tests that require filesystem.
The approach taken to mark <filesystem> as unavailable in this patch
is to mark all the header as unavailable using #pragma clang attribute.
Marking each declaration using the attribute is more intrusive and
does not provide a lot of value right now because pretty much everything
in <filesystem> requires dylib support, often transitively.
This is an alternative to https://reviews.llvm.org/D59093.
A similar (but partial) patch was already applied in r356558.
Reviewers: mclow.lists, EricWF, serge-sans-paille
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59224
llvm-svn: 356616
This fixes CI for back-deployment testers on platforms that don't have
<filesystem> support in the dylib.
This is effectively half of https://reviews.llvm.org/D59224. The other
half requires fixes in Clang.
llvm-svn: 356558
Summary:
Otherwise, implicit instantiations of templates with these types can
cause the dylib to start exporting the vtable/RTTI of the instantiation.
Giving hidden visibility to those types causes the compiler to understand
that they are not used outside the dylib, and as a result implicitly
instantiated vtables/RTTI of templates with those internal types will
get hidden visibility.
Reviewers: EricWF
Subscribers: christof, jkorous, dexonsmith, jdoerfert, libcxx-commits
Differential Revision: https://reviews.llvm.org/D59550
llvm-svn: 356488
Summary:
The reason libc++ implemented a throwing debug mode handler was for ease of testing. Specifically,
I thought that if a debug violation aborted, we could only test one violation per file. This made
it impossible to test debug mode. Which throwing behavior we could test more!
However, the throwing approach didn't work either, since there are debug violations underneath noexcept
functions. This lead to the introduction of `_NOEXCEPT_DEBUG`, which was only noexcept when debug
mode was off.
Having thought more and having grown wiser, `_NOEXCEPT_DEBUG` was a horrible decision. It was
viral, it didn't cover all the cases it needed to, and it was observable to the user -- at worst
changing the behavior of their program.
This patch removes the throwing debug handler, and rewrites the debug tests using 'fork-ing' style
death tests.
Reviewers: mclow.lists, ldionne, thomasanderson
Reviewed By: ldionne
Subscribers: christof, arphaman, libcxx-commits, #libc
Differential Revision: https://reviews.llvm.org/D59166
llvm-svn: 356417
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
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
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
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
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
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
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
Summary:
gcc warns that `__throw_runtime_error` is declared both in `<__locale>`
and `<stdexcept>`, if `-Wredundant-decls` is passed on the command
line; this is the case with FreeBSD when ${WARNS} == 6.
Since `<__locale>` gets its first declaration via a transitive include
of `<stdexcept>`, and the second declaration is after the first
invocation of `__throw_runtime_error`, delete that second declaration.
Signed-off-by: Enji Cooper <yaneurabeya@gmail.com>
Reviewers: kristina, MaskRay, EricWF, ldionne, ngie
Reviewed By: EricWF
Subscribers: krytarowski, brooks, emaste, dim, christof, jdoerfert, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D58425
llvm-svn: 354515
Summary:
A few places in the library seem to behave unexpectedly when the library
is compiled or used with exceptions disabled. For example, not throwing
an exception when a pointer is NULL can lead us to dereference the pointer
later on, which is UB. This patch fixes such occurences.
It's hard to tell whether there are other places where the no-exceptions
mode misbehaves like this, because the replacement for throwing an
exception does not always seem to be abort()ing, but at least this
patch will improve the situation somewhat.
See http://lists.llvm.org/pipermail/libcxx-dev/2019-January/000172.html
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D57761
llvm-svn: 353850
Summary:
Some implementations of fenv.h use macros to define the functions they provide. This can cause problems when `std::fegetround()` is spelled in source.
This patch adds a `fenv.h` header to libc++ for the sole purpose of turning those macros into real functions.
Reviewers: rsmith, mclow.lists, ldionne
Reviewed By: rsmith
Subscribers: mgorny, christof, libcxx-commits
Differential Revision: https://reviews.llvm.org/D57729
llvm-svn: 353767
Summary:
We currently have effectively 3 implementations of type_info: one for
the Microsoft ABI, one that does not assume that there's a unique copy
of each RTTI in a progran, and one that assumes a unique copy.
Those 3 implementations are entangled into the same class with nested
ifdefs, which makes it very difficult to understand. Furthermore, the
benefit of doing this is rather small since the code that is duplicated
across implementations is just a couple of trivial lines.
This patch stamps out the 3 versions of type_info explicitly to increase
readability. It also explains what's going on with short comments, because
it's far from obvious.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith
Differential Revision: https://reviews.llvm.org/D57606
llvm-svn: 352905
On my Windows system, __allocator is defined to nothing. This change fixes build errors of the below form:
In file included from algorithm:644:
functional(1492,31): error: expected member name or ';' after declaration specifiers
const _Alloc& __allocator() const { return __f_.second(); }
Differential Revision: https://reviews.llvm.org/D57355
llvm-svn: 352561
_LIBCPP_FUNC_VIS is redundant since the class is already annotated with
_LIBCPP_EXCEPTION_ABI.
Fixes this build error:
In file included from fstream:188:
filesystem(1350,3): error: attribute 'dllimport' cannot be applied to member of 'dllimport' class
_LIBCPP_FUNC_VIS
__config(674,37): note: expanded from macro '_LIBCPP_FUNC_VIS'
#define _LIBCPP_FUNC_VIS _LIBCPP_DLL_VIS
__config(666,38): note: expanded from macro '_LIBCPP_DLL_VIS'
# define _LIBCPP_DLL_VIS __declspec(dllimport)
filesystem(1313,7): note: previous attribute is here
class _LIBCPP_EXCEPTION_ABI filesystem_error : public system_error {
__config(675,37): note: expanded from macro '_LIBCPP_EXCEPTION_ABI'
#define _LIBCPP_EXCEPTION_ABI _LIBCPP_DLL_VIS
__config(666,38): note: expanded from macro '_LIBCPP_DLL_VIS'
# define _LIBCPP_DLL_VIS __declspec(dllimport)
Differential Revision: https://reviews.llvm.org/D57354
llvm-svn: 352525
The meta-programming that attempted to form the invoke call expression
was not in a SFINAE context. This made it a hard error to provide
non-referencable types like 'void' or 'void (...) const'.
This patch fixes the error by checking the validity of the call
expression within a SFINAE context.
llvm-svn: 352522
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Summary:
FreeBSD ships a very old and deprecated ABI for std::pair where the copy and move constructors are not allowed to be trivial. D25389 change how this was implemented by introducing a non-trivial base class. This patch, introduced in October 2016, introduced an ABI bug that caused nested `std::pair` instantiations to have padding. For example:
```
using PairT = std::pair< std::pair<char, char>, char >;
static_assert(offsetof(PairT, first) == 0, "First member should exist at offset zero"); // Fails on FreeBSD!
```
The bug occurs because the base class for the first element (the nested pair) cannot be put at offset zero because the top-level pair already has the same base class laid out there.
This patch fixes that ABI bug by templating the dummy base class on the same parameters as the pair.
Technically this fix is an ABI break for users who depend on the "broken" ABI introduced in 2016. I'm putting this up for review so that the FreeBSD maintainers can sign off on fixing the ABI by breaking the ABI.
Another option, since we have to "break" the ABI to fix it, would be to move FreeBSD off the deprecated non-trivial pair ABI instead.
Also see:
* https://llvm.org/PR40230
* https://reviews.llvm.org/D21329
Reviewers: rsmith, dim, emaste
Reviewed By: rsmith
Subscribers: mclow.lists, krytarowski, christof, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D56357
llvm-svn: 351290
Summary:
Starting in Clang 8.0 and GCC 8.0, `alignof` and `__alignof` return different values in same cases. Specifically `alignof` and `_Alignof` return the minimum alignment for a type, where as `__alignof` returns the preferred alignment. libc++ currently uses `__alignof` but means to use `alignof`. See llvm.org/PR39713
This patch introduces the macro `_LIBCPP_ALIGNOF` so we can control which spelling gets used.
This patch does not introduce any ABI guard to provide the old behavior with newer compilers. However, if we decide that is needed, this patch makes it trivial to implement.
I think we should commit this change immediately, and decide what we want to do about the ABI afterwards.
Reviewers: ldionne, EricWF
Reviewed By: ldionne, EricWF
Subscribers: jyknight, christof, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54814
llvm-svn: 351289
Summary:
This patch implements all the feature test macros libc++ currently supports, as specified by the standard or cppreference prior to C++2a.
The tests and `<version>` header are generated using a script. The script contains a table of each feature test macro, the headers it should be accessible from, and its values of each dialect of C++.
When a new feature test macro is added or needed, the table should be updated and the script re-run.
Reviewers: mclow.lists, jfb, serge-sans-paille
Reviewed By: mclow.lists
Subscribers: arphaman, jfb, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D56750
llvm-svn: 351286
When catopen is missing, do_open, do_get and do_close end up being
no-op, and as such their parameters will be unused which triggers a
warning/error when building with -Wunused-parameter.
Differential Revision: https://reviews.llvm.org/D56023
llvm-svn: 351027
Mikhail Maltsev