when _LIBCPP_ABI_UNSTABLE is defined.
User defined _LIBCPP_ABI_NAMESPACE will still be respected,
but the default version namespace in unstable mode will be the libc++ version
(Currently '__9000').
Previously `_LIBCPP_ABI_VERSION` and `_LIBCPP_ABI_NAMESPACE` were
`1` and `__1` respectively, whuch conflicted with the stable ABI
llvm-svn: 364354
The new meta-programming primitives are lower cost than the old versions. This patch removes those old versions and switches libc++ to use the new ones.
llvm-svn: 364160
Clang provides __is_same that doesn't produce any instantiations
and just returns a bool. It's a lot faster than using std::is_same
I'll follow up with a patch to actually start using it.
llvm-svn: 364148
The CMake CheckLibcxxAtomic module was always failing to compile
the example, even when libatomic wasn't needed. This was caused
because the check doesn't link a C++ runtime library to provide
std::terminate, which is required for exception support.
The check is still really broken, but <atomic> is better!
llvm-svn: 364146
Using class templates instead of alias templates causes a lot of
instantiations. As part of the move away from C++03, we want to
improve the efficiency of our meta-programming.
This patch lays the groundwork by introducing new _If, _EnableIf,
_And, _Or, and _IsValidExpansion (detect member). Future patches
will replace the existing implementations after verifying there
compile time differences.
llvm-svn: 364114
These functions are key to allowing the use of rvalues and variadics
in C++03 mode. Everything works the same as in C++11, except for one
tangentially related case:
struct T {
T(T &&) = default;
};
In C++11, T has a deleted copy constructor. But in C++03 Clang gives
it both a move and a copy constructor. This seems reasonable enough
given the extensions it's using.
The other changes in this patch were the minimal set required
to keep the tests passing after the move/forward change. Most notably
the removal of the `__rv<unique_ptr>` hack that was present
in an attempt to make unique_ptr move only without language support.
llvm-svn: 364063
All the compilers we support provide these builtins. We don't
need to do a configuration dance anymore.
This patch also cleans up some dead or almost dead
C++11 feature detection macros.
llvm-svn: 364047
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
This patch aims to help clang with better information so it can inline
__bit_reference count function usage for both std::biset. Current clang
inliner can not infer that the passed typed will be used only to select
the optimized variant, it evaluates the type argument and type check as
a load plus compare (although later optimization phases correctly
optimized this out).
It is mainly to help llvm inliner to generate better code for std::bitset
count for aarch64. It helps on both runtime and code size, since if inline
decides that _VSTD::count should not be inlined the vectorization will
create both aligned and unaligned variants (which add both code size and
runtime costs)
llvm-svn: 350936
Summary:
P0602R4 makes the special member functions of optional and variant
conditionally trivial based on the types in the optional/variant.
We already implemented that, but the tests were organized as if this
were a non-standard extension. This patch reorganizes the tests in a
way that makes more sense since this is not an extension anymore.
Reviewers: EricWF, mpark, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54772
llvm-svn: 350884
We already have a specialization that will use memcpy for construction
of trivial types from an iterator range like
std::vector<int>(int *, int *);
But if we have const-ness mismatch like
std::vector<int>(const int *, const int *);
we would use a slow path that copies each element individually. This change
enables the optimal specialization for const-ness mismatch. Fixes PR37574.
Contributions to the patch are made by Arthur O'Dwyer, Louis Dionne.
rdar://problem/40485845
Reviewers: mclow.lists, EricWF, ldionne, scanon
Reviewed By: ldionne
Subscribers: christof, ldionne, howard.hinnant, cfe-commits
Differential Revision: https://reviews.llvm.org/D48342
llvm-svn: 350583
This patch changes <experimental/foo> to use #warning instead of
is harmful to common feature detection idioms.
We should also consider only emitting the warning when __DEPRECATED is
defined, like we do in the <ext/foo> headers. Users may want to specify
"-Werror=-W#warnings" while still ignoring the libc++ warnings.
llvm-svn: 350485
Summary:
We already have the negation of that as _LIBCPP_HAS_NONUNIQUE_TYPEINFO.
Having both defined is confusing, since only one of them is used.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54537
llvm-svn: 349947
Makes libc++ behavior consistent between C++03 and C++11.
Can use `decltype` in C++03 because `include/__config` defines a macro when
`decltype` is not available.
Reviewers: mclow.lists, EricWF, erik.pilkington, ldionne
Reviewed By: ldionne
Subscribers: dexonsmith, cfe-commits, howard.hinnant, ldionne, christof, jkorous, Quuxplusone
Differential Revision: https://reviews.llvm.org/D48753
llvm-svn: 349676
This is a re-application of r345525, which had been reverted by fear of
a regression.
Reviewed as https://reviews.llvm.org/D53994.
Thanks to Denis Yaroshevskiy for the patch.
llvm-svn: 349358
NetBSD defines character classes up to 0x2000. Use 0x8000 as a safe
__regex_word that hopefully will not collide with other values
in the foreseeable future.
Differential Revision: https://reviews.llvm.org/D55657
llvm-svn: 349293
Fixes a bug where functions would get exported when building with
-fvisibility=hidden and defining _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS. No
visibility annotations should be added in this case.
The new logic for _LIBCPP_EXPORTED_FROM_ABI matches that of the other visibility
annotations around it.
Differential Revision: https://reviews.llvm.org/D55664
llvm-svn: 349080
Also, add tests making sure that vector and deque both catch the problem
when assertions are enabled. Otherwise, deque would segfault and vector
would never terminate.
llvm-svn: 348994
Summary:
std::tuple marks its constructors as noexcept when the corresponding
memberwise constructors are noexcept too -- this commit improves std::pair
so that it behaves the same.
This is a re-application of r348824, which broke the build in C++03 mode
because a test was marked as supported in C++03 when it shouldn't be.
Note:
I did not add support in the explicit and non-explicit `pair(_Tuple&& __p)`
constructors because those are non-standard extensions, and supporting them
properly is tedious (we have to copy the rvalue-referenceness of the deduced
_Tuple&& onto the result of tuple_element).
<rdar://problem/29537079>
Reviewers: mclow.lists, EricWF
Subscribers: christof, llvm-commits
Differential Revision: https://reviews.llvm.org/D48669
llvm-svn: 348847
Summary:
std::tuple marks its constructors as noexcept when the corresponding
memberwise constructors are noexcept too -- this commit improves std::pair
so that it behaves the same.
Note:
I did not add support in the explicit and non-explicit `pair(_Tuple&& __p)`
constructors because those are non-standard extensions, and supporting them
properly is tedious (we have to copy the rvalue-referenceness of the deduced
_Tuple&& onto the result of tuple_element).
<rdar://problem/29537079>
Reviewers: mclow.lists, EricWF
Subscribers: christof, llvm-commits
Differential Revision: https://reviews.llvm.org/D48669
llvm-svn: 348824
Patch from Jordan Soyke (jsoyke@google.com)
Reviewed as D55520
This change adds a new internal class, called __value_func, that adds
a minimal subset of value-type semantics to the internal __func interface.
The change is NFC, and is cleanup for the upcoming ABI v2 function implementation (D55045).
llvm-svn: 348778
Summary:
When providing a non-const-callable comparator in a map or set, the
warning diagnostic does not include the point of instantiation of
the container that triggered the warning, which makes it difficult
to track down the problem. This commit improves the diagnostic by
placing it directly in the body of the associative container.
The same change is applied to unordered associative containers, which
had a similar problem.
Finally, this commit cleans up the forward declarations of several
map and unordered_map helpers, which are not needed anymore.
<rdar://problem/41370747>
Reviewers: EricWF, mclow.lists
Subscribers: christof, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D48955
llvm-svn: 348529
Whether an explicit instantiation declaration should be provided is not
a matter of availability markup.
This problem is exemplified by the fact that some tests were incorrectly
marked as XFAIL when they should instead have been using the definition
of streams from the headers, and hence passing, and that, regardless of
whether visibility annotations are enabled.
llvm-svn: 348436
Summary:
This was voted into C++20 in San Diego. Note that there was a revision
D0318R2 which did include unwrap_reference_t, but we mistakingly voted
P0318R1 into the C++20 Working Draft (which does not include
unwrap_reference_t). This patch implements D0318R2, which is what
we'll end up with in the Working Draft once this mistake has been
fixed.
Reviewers: EricWF, mclow.lists
Subscribers: christof, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54485
llvm-svn: 348138
Summary:
std::bad_array_length was added by n3467, but this never made it into C++.
This commit removes the definition of std::bad_array_length from the headers
AND from the shared library. See the comments in the ABI changelog for details
about the ABI implications of this change.
Reviewers: mclow.lists, dexonsmith, howard.hinnant, EricWF
Subscribers: christof, jkorous, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54804
llvm-svn: 347903
This reverts commit 087f065cb0c7463f521a62599884493aaee2ea12.
The tests were failing on 32 bit builds, and I don't have time
to clean them up right now. I'll recommit tomorrow with fixed tests.
llvm-svn: 347816
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: EricWF
Subscribers: christof, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54814
llvm-svn: 347787
Summary:
std::dynarray had been proposed for C++14, but it was pulled out from C++14
and there are no plans to standardize it anymore.
Reviewers: mclow.lists, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, arphaman, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54801
llvm-svn: 347783
This attribute should appear only on the first declaration. This
patch cleans up <string> by removing the attribute on redeclarations.
llvm-svn: 347608
This patch adds an implementation of __resize_default_init as
described in P1072R2. Additionally, it uses it in filesystem to
demonstrate its intended utility.
Once P1072 lands, or if it changes it's interface, I will adjust
the internal libc++ implementation to match.
llvm-svn: 347589
We don't support mac OS 10.6 and older anymore, so this macro can never
be defined. This bit of code had been added in D28931 as a fix for
PR31448, but it doesn't seem necessary anymore.
llvm-svn: 347427
r347395 changed the ABI list on Linux, but two of those symbols are still
being exported from the shared object:
_ZSt18make_exception_ptrINSt3__112future_errorEESt13exception_ptrT_
_ZNSt3__1plIcNS_11char_traitsIcEENS_9allocatorIcEEEENS_12basic_stringIT_T0_T1_EERKS9_PKS6_
This commit makes sure those symbols are not exported, as they should be.
llvm-svn: 347399
Summary:
This commit marks a few functions as hidden and removes them from the ABI list
on Linux such that libc++ can be built with -fvisibility=hidden. The functions
marked as hidden by this patch were exported from the shared object only
because they were implicitly instantiated function templates. It is safe
to stop exporting those symbols from the shared object because nobody could
actually depend on them: implicit instantiations are not taken from shared
objects.
The symbols removed in this commit are basically the same that had been
removed in https://reviews.llvm.org/D53868, but that patch had to be reverted
because it broke the build (because the functions were not marked as hidden
like this patch does).
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54639
llvm-svn: 347395
Summary:
P1006 adds support for constexpr in the specialization of pointer_traits
for raw pointers. This is necessary in order to use pointer_traits in
the upcoming constexpr containers. We expect P1006 to be voted into the
working draft for C++20 at the San Diego meeting.
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D53867
llvm-svn: 346764
shared_mutex was introduced in C++17 but its implementation currently
doesn't use Clang's thread annotations like regular mutex. This change
adds those.
Differential Revision: https://reviews.llvm.org/D54290
llvm-svn: 346567
This reverts r345525. I'm reverting because that patch apparently caused
a regression on certain platforms (see https://reviews.llvm.org/D53994).
Since we don't fully understand the reasons for the regression, I'm
reverting until we can provide a fix we understand.
llvm-svn: 345893
Summary:
This silences the two -Wimplicit-fallthrough warnings clang finds in
ItaniumDemangle.h in libc++abi.
Clang does not have a GNU attribute spelling for this attribute, so this
is necessary.
I will commit the same change to the LLVM demangler soon.
Reviewers: EricWF, ldionne
Subscribers: christof, erik.pilkington, cfe-commits
Differential Revision: https://reviews.llvm.org/D53985
llvm-svn: 345870
This commit adds a merge member function to all the map and set containers,
which splices nodes from the source container. This completes support for
P0083r3.
Differential revision: https://reviews.llvm.org/D48896
llvm-svn: 345744
Summary:
This patch makes the versioning namespace libc++ uses customizable by the user using `-DLIBCXX_ABI_NAMESPACE=__foo`.
This allows users to build custom versions of libc++ which can be linked into binaries with other libc++ versions without causing symbol conflicts or ODR issues.
Reviewers: mclow.lists, ldionne
Reviewed By: ldionne
Subscribers: kristina, smeenai, mgorny, phosek, libcxx-commits
Differential Revision: https://reviews.llvm.org/D53879
llvm-svn: 345657
Summary:
This commit adopts the exclude_from_explicit_instantiation attribute discussed
at [1] and reviewed in [2] in libc++ to supplant the use of __always_inline__
for visibility purposes.
This change means that users wanting to link together translation units built
with different versions of libc++'s headers into the same final linked image
MUST define the _LIBCPP_HIDE_FROM_ABI_PER_TU macro to 1 when building those
TUs. Doing otherwise will lead to ODR violations and ABI issues.
[1]: http://lists.llvm.org/pipermail/cfe-dev/2018-August/059024.html
[2]: https://reviews.llvm.org/D51789
Reviewers: rsmith, EricWF
Subscribers: dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D52405
llvm-svn: 345516
The types/comparators passed to std::upper_bound and std::lower_bound
are not required to provided to provide an operator</comp(...) which
accepts the arguments in reverse order. Nor are the ranges required
to have a strict weak ordering.
However, in debug mode we attempted to check the result of a comparison
with the arguments reversed, which may not compiler.
This patch removes the use of the debug comparator for upper_bound
and lower_bound.
equal_range et al still use debug comparators when they call
__upper_bound and __lower_bound.
See llvm.org/PR39458
llvm-svn: 345434
Summary:
C++14 sized deallocation is disabled by default due to ABI concerns. However, when a user manually enables it then libc++ should take advantage of it since sized deallocation can provide a significant performance win depending on the underlying malloc implementation. (Note that libc++'s definitions of sized delete don't do anything special yet, but users are free to provide their own).
This patch updates __libcpp_deallocate to selectively call sized operator delete when it's available. `__libcpp_deallocate_unsized` should be used when the size of the allocation is unknown.
On Apple this patch makes no attempt to determine if the sized operator delete is unavailable, only that the language feature is enabled. This could cause a compile error when using `std::allocator`, but the same compile error would occur whenever the user calls `new`, so I don't think it's a problem.
Reviewers: ldionne, mclow.lists
Reviewed By: ldionne
Subscribers: rsmith, ckennelly, libcxx-commits, christof
Differential Revision: https://reviews.llvm.org/D53120
llvm-svn: 345281
Summary:
When building with -fvisibility=hidden, some symbols do not get exported from
libc++.dylib. This means that some entities are not explicitly given default
visibility in the source code, and that we rely on the fact -fvisibility=default
is the default. This commit explicitly gives default visibility to those
symbols to avoid being dependent on the command line flags used.
The commit also remove symbols from the dylib -- those symbols do not
actually need to be exported from the dylib and this should not be an
ABI break.
Finally, in the future, we may want to mark the whole std:: namespace as
having hidden visibility (to switch from opt-out to opt-in), in which
case the changes done in this commit will be required.
Reviewers: EricWF
Subscribers: mgorny, christof, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D52662
llvm-svn: 345260
Summary:
C++14 sized deallocation is disabled by default due to ABI concerns. However, when a user manually enables it then libc++ should take advantage of it since sized deallocation can provide a significant performance win depending on the underlying malloc implementation. (Note that libc++'s definitions of sized delete don't do anything special yet, but users are free to provide their own).
This patch updates __libcpp_deallocate to selectively call sized operator delete when it's available. `__libcpp_deallocate_unsized` should be used when the size of the allocation is unknown.
On Apple this patch makes no attempt to determine if the sized operator delete is unavailable, only that the language feature is enabled. This could cause a compile error when using `std::allocator`, but the same compile error would occur whenever the user calls `new`, so I don't think it's a problem.
Reviewers: ldionne, mclow.lists
Reviewed By: ldionne
Subscribers: rsmith, ckennelly, libcxx-commits, christof
Differential Revision: https://reviews.llvm.org/D53120
llvm-svn: 345214
This reverts commits r333103 and r333108. _Float16 and __fp16 are C11
extensions and compilers other than Clang don't define these for C++.
Differential Revision: https://reviews.llvm.org/D53670
llvm-svn: 345199
That macro has been defined to _LIBCPP_HIDE_FROM_ABI_AFTER_V1 for many
weeks now, so we're actually replacing uses of it for uses of
_LIBCPP_HIDE_FROM_ABI_AFTER_V1 directly.
This should not change or break anything since the two macros are
100% equivalent, unless somebody is (incorrectly!) relying on
_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY being defined.
llvm-svn: 344641
Revert r344535 "Wrap up the new chrono literals in an #ifdef..."
Revert r344546 "Mark a couple of test cases as 'C++17-only'..."
Some of the buildbot failures were masked by another error,
and this one was probably missed.
llvm-svn: 344580
There are two cases:
1. The library has all it needs to provide align_val_t and the
new/delete overloads needed to support aligned allocation.
2. The compiler has actually turned the language feature on.
There are times where libc++ needs to distinguish between the two.
This patch adds the additional macro
_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION which denotes when case (1)
does not hold. _LIBCPP_HAS_NO_ALIGNED_ALLOCATION is defined whenever
_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION is defined, or when the
compiler has not enabled the language feature.
Additionally this patch cleans up a number of other macros related
to detection of aligned allocation machinery.
llvm-svn: 344207
Summary:
Scoped capabilities need to be annotated as such, otherwise the thread
safety analysis won't work as intended.
Fixes PR39234.
Reviewers: ldionne
Reviewed By: ldionne
Subscribers: christof, libcxx-commits
Differential Revision: https://reviews.llvm.org/D53049
llvm-svn: 344096
Summary:
Add error messages to a couple of static_asserts in span to match the
style used in the rest of the file. Also fix an extra paren typo in a
assert error message.
Committed on behalf of Jason Lovett.
Reviewers: ldionne
Subscribers: libcxx-commits
Differential Revision: https://reviews.llvm.org/D52841
llvm-svn: 343725
When we're using clang-cl and Microsoft's runtime implementation,
we don't provide align_val_t or aligned new/delete ourselves.
This patch updates the _LIBCPP_HAS_NO_ALIGNED_ALLOCATION macro
to reflect this.
llvm-svn: 343441
Summary:
The ABI version used by libc++ is a configuration option just like any other
configuration option. It is a knob that can be used by vendors to customize
the libc++ that they ship. As such, we should not be hardcoding vendor-specific
configuration choices in libc++.
When building libc++ for Fuchsia, Fuchsia's build scripts should simply define
the libc++ ABI version to 2 -- this will result in the _LIBCPP_ABI_VERSION
macro being defined in the __config header that is generated when libc++ is
built and installed, which is the correct way to customize libc++'s behavior
for specific vendors.
Reviewers: phosek, EricWF
Subscribers: mgorny, christof, dexonsmith, cfe-commits, libcxx-commits
Differential Revision: https://reviews.llvm.org/D52397
llvm-svn: 343079
Summary:
These deprecation warnings are opt-in: they are only enabled when the
_LIBCXX_DEPRECATION_WARNINGS macro is defined, which is not the case
by default. Note that this is a first step in the right direction, but
I wasn't able to get an exhaustive list of all deprecated components
per standard, so there's certainly stuff that's missing. The list of
components this commit marks as deprecated is:
in C++11:
- auto_ptr, auto_ptr_ref
- binder1st, binder2nd, bind1st(), bind2nd()
- pointer_to_unary_function, pointer_to_binary_function, ptr_fun()
- mem_fun_t, mem_fun1_t, const_mem_fun_t, const_mem_fun1_t, mem_fun()
- mem_fun_ref_t, mem_fun1_ref_t, const_mem_fun_ref_t, const_mem_fun1_ref_t, mem_fun_ref()
in C++14:
- random_shuffle()
in C++17:
- unary_negate, binary_negate, not1(), not2()
<rdar://problem/18168350>
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D48912
llvm-svn: 342843
Summary:
The `[[nodiscard]]` attribute is intended to help users find bugs where
function return values are ignored when they shouldn't be. After C++17 the
C++ standard has started to declared such library functions as `[[nodiscard]]`.
However, this application is limited and applies only to dialects after C++17.
Users who want help diagnosing misuses of STL functions may desire a more
liberal application of `[[nodiscard]]`.
For this reason libc++ provides an extension that does just that! The
extension must be enabled by defining `_LIBCPP_ENABLE_NODISCARD`. The extended
applications of `[[nodiscard]]` takes two forms:
1. Backporting `[[nodiscard]]` to entities declared as such by the
standard in newer dialects, but not in the present one.
2. Extended applications of `[[nodiscard]]`, at the libraries discretion,
applied to entities never declared as such by the standard.
Users may also opt-out of additional applications `[[nodiscard]]` using
additional macros.
Applications of the first form, which backport `[[nodiscard]]` from a newer
dialect may be disabled using macros specific to the dialect it was added. For
example `_LIBCPP_DISABLE_NODISCARD_AFTER_CXX17`.
Applications of the second form, which are pure extensions, may be disabled
by defining `_LIBCPP_DISABLE_NODISCARD_EXT`.
This patch was originally written by me (Roman Lebedev),
then but then reworked by Eric Fiselier.
Reviewers: mclow.lists, thakis, EricWF
Reviewed By: thakis, EricWF
Subscribers: llvm-commits, mclow.lists, lebedev.ri, EricWF, rjmccall, Quuxplusone, cfe-commits, christof
Differential Revision: https://reviews.llvm.org/D45179
llvm-svn: 342808
This reverts r342566 as it causes on bots linker errors like
> Undefined symbols for architecture i386:
> "std::__1::basic_ostream<char, std::__1::char_traits<char> >::operator<<(std::nullptr_t)", referenced from:
llvm-svn: 342599
type.
Libc++ correctly asserts that a set of visitors for a variant all
return the same type. However, we use the visitation machinary to
perform relational operations. This causes a static assertion when
some of the alternatives relops return a UDT which is implicitly
convertible to bool instead of 'bool' exactly.
llvm-svn: 342560
Summary:
This commit fixes a regression introduced in r316095, where we don't match
inverted character classes when there's no negated characrers in the []'s.
rdar://problem/43060054
Reviewers: mclow.lists, timshen, EricWF
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D50534
llvm-svn: 340609
Summary:
The state associated to the future was set in one thread (with synchronization)
but read in another thread without synchronization, which led to a data race.
https://bugs.llvm.org/show_bug.cgi?id=38181
rdar://problem/42548261
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D51170
llvm-svn: 340608
These algorithms require a ForwardIterator or better. Ensure
we diagnose the contract violation at compile time instead of
of silently doing the wrong thing.
Further algorithms will be audited in upcoming patches.
llvm-svn: 340426
Summary:
The NetBSD headers ship with max_align_t, that is not
compatible with the fallback version in libc++.
There is no defined a compiler specific symbol in the headers like:
- __CLANG_MAX_ALIGN_T_DEFINED
- _GCC_MAX_ALIGN_T
- __DEFINED_max_align_t
Sponsored by <The NetBSD Foundation>
Reviewers: chandlerc, dlj, EricWF, joerg
Reviewed By: joerg
Subscribers: bsdjhb, llvm-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D47814
llvm-svn: 340224
Summary:
When a seed sequence would lead to having no non-zero significant bits
in the initial state of a `mersenne_twister_engine`, the fallback is to
flip the most significant bit of the first value that appears in the
textual representation of the initial state.
rand.eng.mers describes this as setting the value to be 2 to the power
of one less than w; the previous value encoded in the implementation,
namely one less than "2 to the power of w", is replaced by the correct
value in this patch.
Reviewers: mclow.lists, EricWF, jasonliu
Reviewed By: mclow.lists
Subscribers: mclow.lists, jasonliu, EricWF, christof, ldionne, cfe-commits
Differential Revision: https://reviews.llvm.org/D50736
llvm-svn: 339969
Summary:
https://reviews.llvm.org/D49240 led to symbol size problems in Chromium, and
we expect this may be the case in other projects built in debug mode too.
Instead, unless users explicitly ask for internal_linkage, we use always_inline
like we used to.
In the future, when we have a solution that allows us to drop always_inline
without falling back on internal_linkage, we can replace always_inline by
that.
Note that this commit introduces a change in contract for existing libc++
users: by default, libc++ used to guarantee that TUs built with different
versions of libc++ could be linked together. With the introduction of the
_LIBCPP_HIDE_FROM_ABI_PER_TU macro, the default behavior is that TUs built
with different libc++ versions are not guaranteed to link. This is a change
in contract but not a change in behavior, since the current implementation
still allows linking TUs built with different libc++ versions together.
Reviewers: EricWF, mclow.lists, dexonsmith, hans, rnk
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D50652
llvm-svn: 339874
This constructor needs to cast a pointer to uninitialized
memory to a pointer to object type in order to call
allocator_traits::construct(). This cast is not allowed when CFI cast
checks are enabled.
I did this instead of marking __addr() as _LIBCPP_NO_CFI so that we
don't lose CFI checks on get() or the dtor.
Differential Revision: https://reviews.llvm.org/D50743
llvm-svn: 339797
Summary:
The macros were inside `#if defined(_LIBCPP_COMPILER_CLANG)`, which means
we would never detect C11 features on non-Clang compilers. According to
Marshall Clow, this is not the intended behavior.
Reviewers: mclow.lists, EricWF
Subscribers: krytarowski, christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D50748
llvm-svn: 339741
Summary:
The current code enables aligned allocation functions when compiling in C++17
and later. This is a problem because aligned allocation functions might not
be supported on the target platform, which leads to an error at link time.
Since r338934, Clang knows not to define __cpp_aligned_new when it's not
available on the target platform -- this commit takes advantage of that to
only use aligned allocation functions when they are available.
Reviewers: vsapsai, EricWF
Subscribers: christof, dexonsmith, cfe-commits, EricWF, mclow.lists
Differential Revision: https://reviews.llvm.org/D50344
llvm-svn: 339431
Summary:
This macro allows hiding symbols from the ABI when the library is built
with an ABI version after ABI v1, which is currently the only stable ABI.
This commit defines `_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY` to be
`_LIBCPP_HIDE_FROM_ABI_AFTER_V1`, meaning that symbols that were only
exported by the library for historical reasons are not exported anymore
in the unstable ABI.
Because of that, this commit is an ABI break for ABI v2. This ABI version
is not stable, however, so this should not be a problem.
Reviewers: EricWF, mclow.lists
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D49914
llvm-svn: 339012
The warning happens when LIBCXX_ENABLE_EXCEPTIONS cmake option is not set,
and it fires every time __config is included, 33 in total.
Patch by Jason Lovett
Reviewed as https://reviews.llvm.org/D49997
llvm-svn: 338531
Summary:
Major QoI considerations:
- The facility is backported to C++14, same as libstdc++.
- Efforts have been made to minimize the header dependencies.
- The design is friendly to the uses of MSVC intrinsics (`__emulu`, `_umul128`, `_BitScanForward`, `_BitScanForward64`) but not implemented; future contributions are welcome.
Thanks to Milo Yip for contributing the implementation of `__u64toa` and `__u32toa`.
References:
https://wg21.link/p0067r5https://wg21.link/p0682r1
Reviewers: mclow.lists, EricWF
Reviewed By: mclow.lists
Subscribers: ldionne, Quuxplusone, christof, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D41458
llvm-svn: 338479
This commit adds a node handle type, (located in __node_handle), and adds
extract() and insert() members to all map and set types, as well as their
implementations in __tree and __hash_table.
The second half of this feature is adding merge() members, which splice nodes
in bulk from one container into another. This will be committed in a follow-up.
Differential revision: https://reviews.llvm.org/D46845
llvm-svn: 338472
Summary:
This patch adds a new macro _LIBCPP_HAS_NO_VECTOR_EXTENSION for detecting
whether a vector extension (\_\_attribute\_\_((vector_size(num_bytes)))) is
available.
On the top of that, this patch implements the following API:
* all constructors
* operator[]
* copy_from
* copy_to
It also defines simd_abi::native to use vector extension, if available.
In GCC and Clang, certain values with vector extension are passed by registers,
instead of memory.
Based on D41148.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits, MaskRay, lichray, sanjoy
Differential Revision: https://reviews.llvm.org/D41376
llvm-svn: 338309
Summary:
This commit introduces a new macro, _LIBCPP_HIDE_FROM_ABI, whose goal is to
mark functions that shouldn't be part of libc++'s ABI. It marks the functions
as being hidden for dylib visibility purposes, and as having internal linkage
using Clang's __attribute__((internal_linkage)) when available, and
__always_inline__ otherwise.
It replaces _LIBCPP_INLINE_VISIBILITY, which was always using __always_inline__
to achieve similar goals, but suffered from debuggability and code size problems.
The full proposal, along with more background information, can be found here:
http://lists.llvm.org/pipermail/cfe-dev/2018-July/058419.html
This commit does not rename uses of _LIBCPP_INLINE_VISIBILITY to
_LIBCPP_HIDE_FROM_ABI: this wide reaching but mechanical change can
be done later when we've confirmed we're happy with the new macro.
In the future, it would be nice if we could optionally allow dropping
any internal_linkage or __always_inline__ attribute, which could result
in code size improvements. However, this is currently impossible for
reasons explained here: http://lists.llvm.org/pipermail/cfe-dev/2018-July/058450.html
Reviewers: EricWF, dexonsmith, mclow.lists
Subscribers: christof, dexonsmith, llvm-commits, mclow.lists
Differential Revision: https://reviews.llvm.org/D49240
llvm-svn: 338122
The bots were failing to build the cxx_filesystem target, so the
tests were failing. Though this does lead me to wonder how it
was ever working with c++experimental.
llvm-svn: 338095
This patch implements the <filesystem> header and uses that
to provide <experimental/filesystem>.
Unlike other standard headers, the symbols needed for <filesystem>
have not yet been placed in libc++.so. Instead they live in the
new libc++fs.a library. Users of filesystem are required to link this
library. (Also note that libc++experimental no longer contains the
definition of <experimental/filesystem>, which now requires linking libc++fs).
The reason for keeping <filesystem> out of the dylib for now is that
it's still somewhat experimental, and the possibility of requiring an
ABI breaking change is very real. In the future the symbols will likely
be moved into the dylib, or the dylib will be made to link libc++fs automagically).
Note that moving the symbols out of libc++experimental may break user builds
until they update to -lc++fs. This should be OK, because the experimental
library provides no stability guarantees. However, I plan on looking into
ways we can force libc++experimental to automagically link libc++fs.
In order to use a single implementation and set of tests for <filesystem>, it
has been placed in a special `__fs` namespace. This namespace is inline in
C++17 onward, but not before that. As such implementation is available
in C++11 onward, but no filesystem namespace is present "directly", and
as such name conflicts shouldn't occur in C++11 or C++14.
llvm-svn: 338093
This is a refinement on r337833. Previously we were installing two
copies of c++abi headers in libc++ build directory, one in
include/c++build and another one in include/c++/v1. However, the
second copy is unnecessary when building libc++ standalone.
Differential Revision: https://reviews.llvm.org/D49752
llvm-svn: 337979
Summary:
The ``file_time_type`` time point is used to represent the write times for files.
Its job is to act as part of a C++ wrapper for less ideal system interfaces. The
underlying filesystem uses the ``timespec`` struct for the same purpose.
However, the initial implementation of ``file_time_type`` could not represent
either the range or resolution of ``timespec``, making it unsuitable. Fixing
this requires an implementation which uses more than 64 bits to store the
time point.
I primarily considered two solutions: Using ``__int128_t`` and using a
arithmetic emulation of ``timespec``. Each has its pros and cons, and both
come with more than one complication.
However, after a lot of consideration, I decided on using `__int128_t`. This patch implements that change.
Please see the [FileTimeType Design Document](http://libcxx.llvm.org/docs/DesignDocs/FileTimeType.html) for more information.
Reviewers: mclow.lists, ldionne, joerg, arthur.j.odwyer, EricWF
Reviewed By: EricWF
Subscribers: christof, K-ballo, cfe-commits, BillyONeal
Differential Revision: https://reviews.llvm.org/D49774
llvm-svn: 337960
Summary:
The exact same code was replicated 11 times for implementing the basic_istream
input operators (those that don't use numeric_limits). The same code was also
duplicated twice for implementing the basic_istream input operators that take
numeric_limits into account.
This commit factors the common code into function templates to avoid
the duplication.
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D49808
llvm-svn: 337955
Previously the <experimental/filesystem> didn't guard its
contents in any dialect. However, the implementation implicitly
requires at least C++11, and the tests have always been marked
unsupported in C++03. This patch puts a header guard around the
contents to avoid exposing them before C++11.
Additionally, it replaces all of the usages of _NOEXCEPT or
_LIBCPP_CONSTEXPR with the keyword directly, since we can
expect the compiler to implement those by now.
llvm-svn: 337884
To avoid exposing implementation details, path::iterator and PathParser
both implicitly used the same set of values to represent the state,
but they were defined twice. This could have lead to a mismatch
occuring.
This patch moves all of the parser state values into the filesystem
header and changes PathParser to use those value to avoid this.
llvm-svn: 337883
Summary:
This is not guaranteed to work since the characters after '__has_include('
have special lexing rules that can't possibly be applied when
__has_include is generated by a macro. It also breaks the crash reproducers
generated by -frewrite-includes (see https://llvm.org/pr37990).
Reviewers: EricWF, rsmith, mclow.lists
Reviewed By: mclow.lists
Differential Revision: https://reviews.llvm.org/D49067
llvm-svn: 337824
The initial patch didn't correctly handle systems when the dirent struct
didn't provide the d_type member. Specifically it set the cache to the incorrect state,
and claimed it was partially populated.
The updated version of this change correctly handles setting up the
cache when the file type is not known (aka file_type::none).
llvm-svn: 337765
This patch implements the `what()` for filesystem errors. The message
includes the 'what_arg', any paths that were specified, and the
error code message.
Additionally this patch refactors how errors are created, making it easier
to report them correctly.
llvm-svn: 337664
This patch improves both the performance, and the safety of the
copy_file implementation.
The performance improvements are achieved by using sendfile on
Linux and copyfile on OS X when available.
The TOCTOU hardening is achieved by opening the source and
destination files and then using fstat to check their attributes to
see if we can copy them.
Unfortunately for the destination file, there is no way to open
it without accidentally creating it, so we first have to use
stat to determine if it exists, and if we should copy to it.
Then, once we're sure we should try to copy, we open the dest
file and ensure it names the same entity we previously stat'ed.
llvm-svn: 337649
First, <experimental/filesystem> didn't correctly guard
against min/max macros. This adds the proper push/pop macro guards.
Second, an internal time helper had been renamed but the test for
it hadn't been updated. This patch updates those tests.
llvm-svn: 337520
Summary:
This patch implements directory_entry caching *almost* as specified in P0317r1. However, I explicitly chose to deviate from the standard as I'll explain below.
The approach I decided to take is a fully caching one. When `refresh()` is called, the cache is populated by calls to `stat` and `lstat` as needed.
During directory iteration the cache is only populated with the `file_type` as reported by `readdir`.
The cache can be in the following states:
* `_Empty`: There is nothing in the cache (likely due to an error)
* `_IterSymlink`: Created by directory iteration when we walk onto a symlink only the symlink file type is known.
* `_IterNonSymlink`: Created by directory iteration when we walk onto a non-symlink. Both the regular file type and symlink file type are known.
* `_RefreshSymlink` and `_RefreshNonSymlink`: A full cache created by `refresh()`. This case includes dead symlinks.
* `_RefreshSymlinkUnresolved`: A partial cache created by refresh when we fail to resolve the file pointed to by a symlink (likely due to permissions). Symlink attributes are cached, but attributes about the linked entity are not.
As mentioned, this implementation purposefully deviates from the standard. According to some readings of the specification, and the Windows filesystem implementation, the constructors and modifiers which don't pass an `error_code` must throw when the `directory_entry` points to a entity which doesn't exist. or when attribute resolution fails for another reason.
@BillyONeal has proposed a more reasonable set of requirements, where modifiers other than refresh ignore errors. This is the behavior libc++ currently implements, with the expectation some form of the new language will be accepted into the standard.
Some additional semantics which differ from the Windows implementation:
1. `refresh` will not throw when the entry doesn't exist. In this case we can still meet the functions specification, so we don't treat it as an error.
2. We don't clear the path name when a constructor fails via refresh (this will hopefully be changed in the standard as well).
It should be noted that libstdc++'s current implementation has the same behavior as libc++, except for point (2).
If the changes to the specification don't get accepted, we'll be able to make the changes later.
[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0317r1.html
Reviewers: mclow.lists, gromer, ldionne, aaron.ballman
Subscribers: BillyONeal, christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D49530
llvm-svn: 337516
When an always_inline function is used prior to the functions definition,
the compiler may not be able to inline it as requested by the attribute.
GCC flags the `basic_string(CharT const*)` function as one such example.
This patch supresses the warning, and the problem, by moving the
definition of the string constructor to the inline declaration.
This ensures the body is available when it is first ODR used.
llvm-svn: 337235
This variable is already set in CMakeLists.txt but it wasn't used
which means that the headers get installed into a wrong location
when the per target runtime directory option is being used.
Differential Revision: https://reviews.llvm.org/D49345
llvm-svn: 337118
Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.
This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.
Note that this commit had originally been applied in r336369 and then
reverted in r336382 because of unforeseen problems. Both of these problems
have now been fixed.
Reviewers: EricWF, mclow.lists
Subscribers: christof, dexonsmith, erikvanderpoel
Differential Revision: https://reviews.llvm.org/D48892
llvm-svn: 336866
Summary:
It was defined with the right visibility, but declared without any visibility.
This function was left out of a prior revision that did the same to several
functions in <compare> (r336665) because the compiler I used didn't support
coroutines. This reinforces the need for automated checks -- there might
still be several cases of this throughout the library.
Reviewers: EricWF
Subscribers: modocache, christof, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D49145
llvm-svn: 336709
Summary:
Many operators in <compare> were _defined_ with the proper visibility attribute,
but they were _declared_ without any. This is not a problem until we change the
definition of _LIBCPP_INLINE_VISIBILITY to something that requires the
declaration to be decorated.
I also marked `strong_equality::operator weak_equality()` as
`_LIBCPP_INLINE_VISIBILITY`, since it seems like it had been forgotten.
This came up while trying to get rid of `__attribute__((__always_inline__))`
in favor of `__attribute__((internal_linkage))`.
Reviewers: EricWF, mclow.lists
Subscribers: christof, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D49104
llvm-svn: 336665
This reverts commit r336369. The commit had two problems:
1. __pbump was marked as _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY instead of
_LIBCPP_INLINE_VISIBILITY, which lead to two symbols being added in the
dylib and the check-cxx-abilist failing.
2. The LLDB tests started failing because they undefine
`_LIBCPP_INLINE_VISIBILITY`. I need to figure out why they do that and
fix the tests before we can go forward with this change.
llvm-svn: 336382
Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.
This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.
Reviewers: EricWF
Subscribers: christof, llvm-commits, dexonsmith, erikvanderpoel, mclow.lists
Differential Revision: https://reviews.llvm.org/D48892
llvm-svn: 336369
Summary:
It is part of the synopsis in the Standard and <utility> does include it,
but it was left out of the synopsis comment.
Reviewers: EricWF, mclow.lists
Subscribers: christof, llvm-commits
Differential Revision: https://reviews.llvm.org/D48611
llvm-svn: 336368
Summary: This is needed to implement `<charconv>`, otherwise `<charconv>` would need to include `<system_error>`, which pulls in `<string>` -- a header which the `<charconv>` proposal intends to keep away from.
Reviewers: mclow.lists, EricWF
Reviewed By: mclow.lists
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D41347
llvm-svn: 336164
Summary:
_is_chartype_l (needed for isxdigit_l) in MinGW compares locale_t and NULL.
NULL is 'long long' for 64-bit, and this results in ambiguous overloads when
compiled with Clang. Define a concrete overload for the operators to fix the
ambiguity.
Reviewers: mstorsjo, EricWF, srhines, danalbert
Subscribers: christof, cfe-commits, ldionne
Differential Revision: https://reviews.llvm.org/D48749
llvm-svn: 336141
r334477 renamed the cxx-headers target to cxx_headers, but various
pieces sort-of expect the target names to match the component (e.g.,
LLVM_DISTRIBUTION_COMPONENTS in the various bootstrap caches, which, via
some magic foreign to me, seems to expect cxx-headers,
install-cxx-headers, and install-cxx-headers-stripped to exist.)
Revert back to cxx-headers.
Differential Revision: https://reviews.llvm.org/D48701
llvm-svn: 335899
This change adds a support for multiarch style runtimes layout, so in
addition to the existing layout where runtimes get installed to:
lib/clang/$version/lib/$os
Clang now allows runtimes to be installed to:
lib/clang/$version/$target/lib
This also includes libc++, libc++abi and libunwind; today those are
assumed to be in Clang library directory built for host, with the
new layout it is possible to install libc++, libc++abi and libunwind
into the runtime directory built for different targets.
The use of new layout is enabled by setting the
LLVM_ENABLE_RUNTIME_TARGET_DIR CMake variable and is supported by both
projects and runtimes layouts. The runtimes CMake build has been further
modified to use the new layout when building runtimes for multiple
targets.
Differential Revision: https://reviews.llvm.org/D45604
llvm-svn: 335809
Using file(COPY FILE...) has several downsides. Since the file command
is only executed at configuration time, any changes to headers made
after the initial CMake execution are ignored. This can lead to subtle
errors since the just built Clang will be using stale libc++ headers.
Furthermore, since the headers are copied prior to executing the build
system, this may hide missing dependencies on libc++ from other LLVM
components.
This changes replaces the use of file(COPY FILE...) command with a
custom command and target which addresses all aforementioned issues and
matches the implementation already used by other LLVM components that
also install headers like Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D44773
llvm-svn: 334468
Patch from Arthur O'Dwyer.
`__user_alloc_construct_impl` is used by <experimental/memory_resource>, but
this `__user_alloc_construct` is never used.
Also, `<experimental/memory_resource>` doesn't need a full definition of
`std::tuple`; just the forward declaration in `<__tuple>` will suffice.
Reviewed as https://reviews.llvm.org/D46806
llvm-svn: 334069
C++2a[container.requirements.general]p8 states that when move constructing
a container, the allocator is move constructed. Vector previously copy
constructed these allocators. This patch fixes that bug.
Additionally it cleans up some unnecessary allocator conversions
when copy constructing containers. Libc++ uses
__internal_allocator_traits::select_on_copy_construction to select
the correct allocator during copy construction, but it unnecessarily
converted the resulting allocator to the user specified allocator
type and back. After this patch list and forward_list no longer
do that.
Technically we're supposed to be using allocator_traits<allocator_type>::select_on_copy_construction,
but that should seemingly be addressed as a separate patch, if at all.
llvm-svn: 334053
These containers type-punned between pair<K, V> and pair<const K, V> as an
optimization. This commit instead provides access to the pair via a pair of
references that assign through to the underlying object. It's still undefined to
mutate a const object, but clang doesn't optimize on this for data members, so
this should be safe.
Differential revision: https://reviews.llvm.org/D47607
llvm-svn: 333948
Summary:
C++11 onwards specs the non-member functions atomic_load and atomic_load_explicit as taking the atomic<T> by const (potentially volatile) pointer. C11, in its infinite wisdom, decided to drop the const, and C17 will fix this with DR459 (the current draft forgot to fix B.16, but that’s not the normative part).
This patch fixes the libc++ version of the __c11_atomic_load builtins defined for GCC's compatibility sake.
D47618 takes care of the clang side.
Discussion: http://lists.llvm.org/pipermail/cfe-dev/2018-May/058129.html
<rdar://problem/27426936>
Reviewers: EricWF, mclow.lists
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D47613
llvm-svn: 333776
Patch from Arthur O'Dwyer.
In the TS, `uses_allocator` construction for `pair` tried to use an allocator
type of `memory_resource*`, which is incorrect because `memory_resource*` is
not an allocator type. LWG 2969 fixed it to use `polymorphic_allocator` as the
allocator type instead.
https://wg21.link/lwg2969
(D47090 included this in `<memory_resource>`; at Eric's request, I've split
this out into its own patch applied to the existing
`<experimental/memory_resource>` instead.)
Reviewed as https://reviews.llvm.org/D47109
llvm-svn: 333384
That's r333325, as well as follow-up "Fix GCC handling of ATOMIC_VAR_INIT"
r333327.
Marshall asked to revert:
Let's have a discussion about how to implement this so that it is more friendly
to people with installed code bases. We've had *extremely* loud responses to
unilaterally adding warnings - especially ones that can't be easily disabled -
to the libc++ code base in the past.
llvm-svn: 333351
Summary:
The atomic non-member functions accept pointers to std::atomic / std::atomic_flag as well as to the non-atomic value. These are all dereferenced unconditionally when lowered, and therefore will fault if null. It's a tiny gotcha for new users, especially when they pass in NULL as expected value (instead of passing a pointer to a NULL value). We can therefore use the nonnull attribute to denote that:
- A warning should be generated if the argument is null
- It is undefined behavior if the argument is null (because a dereference will segfault)
This patch adds support for this attribute for clang and GCC, and sticks to the subset of the syntax both supports. In particular, work around this GCC oddity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60625
The attributes are documented:
- https://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/Function-Attributes.html
- https://clang.llvm.org/docs/AttributeReference.html#nullability-attributes
I'm authoring a companion clang patch for the __c11_* and __atomic_* builtins, which currently only warn on a subset of the pointer parameters.
In all cases the check needs to be explicit and not use the empty nonnull list, because some of the overloads are for atomic<T*> and the values themselves are allowed to be null.
<rdar://problem/18473124>
Reviewers: arphaman, EricWF
Subscribers: aheejin, christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D47225
llvm-svn: 333325
Some *_l functions were not available in some versions of Bionic. This CL
checks that the NDK version supports the functions, and if not, falls back
on the corresponding functions that don't take a locale.
Patch by Tom Anderson!
Differential Revision: https://reviews.llvm.org/D46558
llvm-svn: 332543
C11 defines `kill_dependency` as a macro in <stdatomic.h>. When you
include <atomic> after <stdatomic.h>, the macro clashes with
`std::kill_dependency` and causes multiple errors. Explicit error should
help in diagnosing those errors.
No change for working code that includes <atomic> before <stdatomic.h>.
rdar://problem/27435938
Reviewers: rsmith, EricWF, mclow.lists, jfb
Reviewed By: jfb
Subscribers: jfb, jkorous-apple, christof, bumblebritches57, JonChesterfield, smeenai, cfe-commits
Differential Revision: https://reviews.llvm.org/D45470
llvm-svn: 332413
Checking for complete types is really rather tricky when you consider
the amount of specializations required to check a function type. This
specifically caused PR37407 where we incorrectly diagnosed
noexcept function types as incomplete (but there were plenty of other
cases that would cause this).
This patch removes the complete type checking for now. I'm going
to look into adding a clang builtin to correctly do this for us.
llvm-svn: 332040
Atomics in C and C++ are incompatible at the moment and mixing the
headers can result in confusing error messages.
Emit an error explicitly telling about the incompatibility. Introduce
the macro `__ALLOW_STDC_ATOMICS_IN_CXX__` that allows to choose in C++
between C atomics and C++ atomics.
rdar://problem/27435938
Reviewers: rsmith, EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: jkorous-apple, christof, bumblebritches57, JonChesterfield, smeenai, cfe-commits
Differential Revision: https://reviews.llvm.org/D45470
llvm-svn: 331379
When using an old version of glibc, a ::isinf(double) and ::isnan(double)
function is provided, rather than just the macro required by C and C++.
Displace this function using _LIBCPP_PREFERRED_OVERLOAD where possible.
The only remaining case where we should get the wrong return type is now
glibc + libc++ + a non-clang compiler.
llvm-svn: 331241
Be defensive against a reentrant std::function::operator=(nullptr_t), in case
the held function object has a non-trivial destructor. Destroying the function
object in-place can lead to the destructor being called twice.
Patch by Duncan P. N. Exon Smith. C++03 support by Volodymyr Sapsai.
rdar://problem/32836603
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits, arphaman
Differential Revision: https://reviews.llvm.org/D34331
llvm-svn: 330885
There are 3 changes:
* Renamed genertor.pass.cpp to generator.pass.cpp
* Removed nothing_to_do.pass.cpp
* Mark GCC 4.9 as UNSUPPORTED for the test files that have negative
narrowing conversion SFINAE test (see GCC PR63723).
llvm-svn: 330655
Summary:
The patch includes all declarations, and also implements the following features:
* ABI.
* narrowing-conversion related SFIANE, including simd<> ctors and (static_)simd_cast.
Reviewers: mclow.lists, EricWF
Subscribers: lichray, sanjoy, MaskRay, cfe-commits
Differential Revision: https://reviews.llvm.org/D41148
llvm-svn: 330627
Summary:
It is immediately preceded by this check:
#if _MSC_VER < 1900
#error "MSVC versions prior to Visual Studio 2015 are not supported"
#endif
Reviewers: EricWF
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D45829
llvm-svn: 330360
The strto* family was introduced in android O (API Level 26). However,
the support headers were adjusted to indicate that all locale aware
functions were added in L. Provide stubs for the locale aware strto*
family until O.
llvm-svn: 330045
This avoids the need for a custom generated config file which is desired
because the custom config files differs per-target which means we cannot
reuse headers across different targets.
Differential Revision: https://reviews.llvm.org/D45304
llvm-svn: 329770
Using file(COPY FILE...) has several downsides. Since the file command
is only executed at configuration time, any changes to headers made
after the initial CMake execution are ignored. This can lead to subtle
errors since the just built Clang will be using stale libc++ headers.
Furthermore, since the headers are copied prior to executing the build
system, this may hide missing dependencies on libc++ from other LLVM
components.
This changes replaces the use of file(COPY FILE...) command with a
custom command and target which addresses all aforementioned issues and
matches the implementation already used by other LLVM components that
also install headers like Clang builtin headers.
Differential Revision: https://reviews.llvm.org/D44773
llvm-svn: 329544
this patch adds the <compare> header and implements all of it
except for [comp.alg].
As I understand it, the header is needed by the compiler in
when implementing the semantics of operator<=>. For that reason
I feel it's important to land this header early, despite
all compilers lacking support.
llvm-svn: 329460
This patch does some housekeeping for the new <version> header.
It adds it to the module.modulemap, and the double_include.sh.cpp test.
Additionally it corrects the // UNSUPPORTED options for the libc++
specific test. The header needs to compile under C++03 to support
modules, and it should compile under all available compilers.
llvm-svn: 329144
This patch implements P0430R2, who's largest change is adding the path::format
enumeration for supporting path format conversions in path constructors.
However, since libc++'s filesystem only really supports POSIX like systems,
there are no real changes needed. This patch simply adds the format enum
and then ignores it when it's passed to constructors.
llvm-svn: 329031
Marshall Clow