This patch updates <type_traits> to use builtin type traits whenever
possible to improve compile times.
Differential Revision: https://reviews.llvm.org/D67900
The current implementation of binomial_distribution is not guaranteed to
converge for certain extreme configurations of the engine and distribution.
This is due to a mistake in the implementation of the algorithm from the
given reference paper. The algorithm in the paper is guaranteed to
terminate but has redundant statements. The current implementation
simplified away the redundancy into a while loop, but it excludes the
return condition of the case where a good sample cannot be returned for
the particular sample being used from the uniform distribution, which is
what causes the infinite loop. This change guarantees termination by
recognizing that a good sample cannot be returned and returning 0 after
breaking the loop. This is also in contrast to the paper because the
return value as specified in the paper violates basic checks in at least
a subset of the extreme cases where the current implementation fails to
terminate. This default return value of 0 is satisfactory for the
extreme case known so far.
Since this is only meant to affect extreme cases where the algorithm
does not terminate anyways, the behavior is expected to remain exactly
the same for all non-extreme cases that have been terminating so far.
Fixes https://llvm.org/PR44847
Differential Revision: https://reviews.llvm.org/D74997
Summary:
The former are like:
libcxx/include/typeinfo:322:11: warning: definition of implicit copy constructor for 'bad_cast' is deprecated because it has a user-declared destructor [-Wdeprecated-copy-dtor]
virtual ~bad_cast() _NOEXCEPT;
^
libcxx/include/typeinfo:344:11: note: in implicit copy constructor for 'std::bad_cast' first required here
throw bad_cast();
^
Fix these by adding an explicitly defaulted copy constructor.
The latter are like:
libcxx/include/codecvt:105:37: warning: dynamic exception specifications are deprecated [-Wdeprecated-dynamic-exception-spec]
virtual int do_encoding() const throw();
^~~~~~~
Fix these by using the _NOEXCEPT macro instead.
Reviewers: EricWF, mclow.lists, ldionne, #libc
Reviewed By: EricWF, #libc
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D76150
Summary: The return type modification has already been implemented in rL364840 and rL365290.
Reviewers: ldionne, mclow.lists, EricWF, #libc!
Reviewed By: ldionne
Subscribers: christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D70275
Due to Clang bug http://llvm.org/PR45151, deprecated attributes are not
picked up on partial specializations. This patch instead applies it to
the first declaration of std::function itself.
Summary:
This is a recommit of https://reviews.llvm.org/D73223 where the added function accidentally ended up inside an idef block.
This change splits the copy constructor up inlining short initialization, and explicitly outlining long initialization into __init_copy_ctor_external() which is the externally instantiated slow path.
For unstable ABI, this has the following changes:
remove basic_string(const basic_string&)
remove basic_string(const basic_string&, const Allocator&)
add __init_copy_ctor_external(const value_type*, size_type)
Quick local benchmark for Copy:
Master
```
---------------------------------------------------------------
Benchmark Time CPU Iterations
---------------------------------------------------------------
BM_StringCopy_Empty 3.50 ns 3.51 ns 199326720
BM_StringCopy_Small 3.50 ns 3.51 ns 199510016
BM_StringCopy_Large 15.7 ns 15.7 ns 45230080
BM_StringCopy_Huge 1503 ns 1503 ns 464896
```
With this change
```
---------------------------------------------------------------
Benchmark Time CPU Iterations
---------------------------------------------------------------
BM_StringCopy_Empty 1.99 ns 2.00 ns 356471808
BM_StringCopy_Small 3.29 ns 3.30 ns 203425792
BM_StringCopy_Large 13.3 ns 13.3 ns 52948992
BM_StringCopy_Huge 1472 ns 1472 ns 475136
```
Subscribers: libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75639
They need to appear before any member functions are ODR used, because
they change the visibility of many of these functions and otherwise
they could end up with hidden visibility in the DSO.
Summary: This review is a mostly trivial change to use an explicit ABI flag for the unstable external template list. This follows the practice for an ABI flag per feature, and provides a spot for the rational / motivation for the flag.
Reviewers: EricWF, ldionne
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75457
The markup wasn't quite right, and that broke compilation with availability
markup enabled. I'm disabling it until I have time to fix it properly to
get the CI mostly green again.
Summary:
This change checks for the case where people want to erase a string to the end, i.e., __n == npos, and inlines the call if so.
This also demonstrates keeping the ABI intact for V1, but inlining the erase() method for unstable.
Reviewers: EricWF, mclow.lists, ldionne
Reviewed By: EricWF, ldionne
Subscribers: smeenai, dexonsmith, christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D73743
Summary:
The definition of `__libcpp_timed_backoff_policy` and the declaration of
`__libcpp_thread_poll_with_backoff` must not be guarded by
#if !defined(_LIBCPP_HAS_THREAD_API_EXTERNAL)
because the definitions of `__libcpp_timed_backoff_policy::operator()`
and `__libcpp_thread_poll_with_backoff` aren't guarded by this macro
(and this is correct because these two functions are implemented in
terms of other libc++ functions and don't interact with the host
threading library).
Reviewers: ldionne, __simt__, EricWF, mclow.lists
Reviewed By: ldionne
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75191
Summary:
This change adds the macros _LIBCPP_COMPILER_HAS_BUILTIN_CONSTANT and _LIBCPP_BUILTIN_CONSTANT_P to detect compile time constants, and optimze the code accordingly.
A planned usage example:
The implementation of basic_string::assign() can short-cut a compile time known short string assignent into a fast and compact inlined assignment:
```
basic_string::assign(const value_type* __s) {
if (_LIBCPP_BUILTIN_CONSTANT_P(__s[0]) && length(__s) < __min_cap) {
copy(pointer(), _s, length(__s) + 1);
set_size(length(__s));
} else {
// delegate / tail call out of line implementation
}
}
```
Subscribers: christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D73732
std::shared_ptr::allocate_shared isn't in the standard. This commit removes it from libc++. It updates std::allocate_shared to use __create_with_cntrl_block.
Differential Revision: https://reviews.llvm.org/D66178
It turns out that <semaphore.h> is not well-behaved, as it transitively
includes <sys/param.h>, and that one defines several non-reserved macros
that clash with some downstream projects in modular builds. For the time
being, using <sys/semaphore.h> instead gives us the declarations we need
without the macros.
rdar://59744472
Move the implementation of __libcpp_thread_poll_with_backoff
and __libcpp_timed_backoff_policy::operator() out of the
_LIBCPP_HAS_THREAD_API_PTHREAD block. None of the code in these
methods is pthreads specific.
Also add "inline _LIBCPP_INLINE_VISIBILITY" to
__libcpp_timed_backoff_policy::operator(), to avoid errors due to
multiple definitions of the operator. Contrary to
__libcpp_thread_poll_with_backoff (which is a template function),
this is a normal non-templated method.
Differential Revision: https://reviews.llvm.org/D75102
Summary:
In libc++, we normally #ifdef out header content instead of #erroring
out when the Standard in use is insufficient for the requirements of
the header.
Reviewers: EricWF
Subscribers: jkorous, dexonsmith, libcxx-commits, teemperor
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75074
Depend on the compiler to provide a correct implementation of
max_align_t. If __STDCPP_NEW_ALIGNMENT__ is missing and C++03 mode has
been explicitly enabled, provide a minimal fallback in <new> as
alignment of the largest primitive types.
https://reviews.llvm.org/D68480 added those headers and made the std module
only usable with C++14 or later as the submodules were not marked as requiring
C++14 or later. This just adds the missing requires directives.
- Avoid using C++11-and-later features in <atomic>:
Historically, we've supported <atomic> in C++03, so we can't use C++11
features in that header. This is something we really need to change,
since our implementation of <atomic> is starting to accumulate technical
debt because of that.
- Mark a test as unsupported on single threaded systems
- Add missing symbols to the Linux ABI list
Summary: We want to eventually remove it.
Reviewers: EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D74719
- Add the new symbols to the ABI list on Darwin
- Add XFAIL markup to the tests that require dylib support on older platforms
- Add availability markup for back-deployment
This change splits the _LIBCPP_STRING_EXTERN_TEMPLATE_LIST up into a _LIBCPP_STRING_V1_EXTERN_TEMPLATE_LIST containing the stable ABI, and a _LIBCPP_STRING_UNSTABLE_EXTERN_TEMPLATE_LIST containing the unstable ABI.
The purpose is to explicitly define and maintain the two lists, where the unstable ABI allows for ABI breaking changes for purposes such as optimization while offering a strong guarantee that any change inside the unstable ABI does not affect the stable ABI.
As per the comment in the __string header, we do still allow etries to be added to the stable ABI list as the c++ versions and corresponding c++ std API changes.
This patch enables throwing exceptions for invalid backreferences
in the constructor when using the basic, extended, grep, or egrep grammar.
This fixes bug 34297.
Differential Revision: https://reviews.llvm.org/D62453
This patch qualifies calls to ref and cref inside ref(reference_wrapper<T>)
and cref(reference_wrapper<T>), respectively. These previously unqualified
calls could break in the presence of user functions called ref/cref inside
associated namespaces: https://gcc.godbolt.org/z/8VfprT
Fixes PR44398.
Differential Revision: https://reviews.llvm.org/D74287
Instead of including <ios> for ios_base::failbit, simply get failbit
member of the template argument. Print directly to a stream instead
of using intermediate ostringstream.
Parsing time: 874ms -> 164ms (-81%)
Thanks to Nikita Kniazev for the patch!
Differential Revision: https://reviews.llvm.org/D71214
The regex backreferences were not properly parsed and used when using
the extended grammar. This change parses them. The issue was found while
working on PR34297.
Thanks to Mark de Wever for the patch!
Differential Revision: https://reviews.llvm.org/D62451
The libc++ __bit_iterator type has weird ABI calling conventions as a
quirk
of the implementation. The const bit iterator is trivial, but the
non-const
bit iterator is not because it declares a user-defined copy constructor.
Changing this now is an ABI break, so this test ensures that each type
is trivial/non-trivial as expected.
The definition of 'non-trivial for the purposes of calls':
A type is considered non-trivial for the purposes of calls if:
* it has a non-trivial copy constructor, move constructor, or
destructor, or
* all of its copy and move constructors are deleted.
This reverts commit 82b47b2978.
This broke Clang and LLDB module builds without -fmodules-local-submodule-visbility.
I'll revert this for now until we have a fix and reland once Clang
can properly handle this code.
See also the discussion in https://reviews.llvm.org/rG82b47b2978405f802a33b00d046e6f18ef6a47be
libc++ is careful to not fracture overload sets. When one overload
is visible to a user, all of them should be. Anything less causes
subtle bugs and ODR violations.
Previously, in order to support ::abs and ::div being supplied by
both <cmath> and <cstdlib> we had to do awful things that make
<math.h> and <stdlib.h> have header cycles and be non-modular.
This really breaks with modules.
Specifically the problem was that in C++ ::abs introduces overloads
for floating point numbers, these overloads forward to ::fabs,
which are defined in math.h. Therefore ::abs needed to be in math.h
too. But this required stdlib.h to include math.h and math.h to
include stdlib.h.
To avoid these problems the definitions have been moved to stddef.h
(which math includes), and the floating point overloads of ::abs
have been changed to call __builtin_fabs, which both Clang and GCC
support.
The static asserts in span<T, N>::front() and span<T, N>::back() are
incorrect as they may be triggered from valid code due to evaluation
of a never taken branch:
span<int, 0> foo;
if (!foo.empty()) {
auto x = foo.front();
}
The problem is that the branch is always evaluated by the compiler,
creating invalid compile errors for span<T, 0>.
Thanks to Michael Schellenberger Costa for the patch.
Differential Revision: https://reviews.llvm.org/D71995
The calculation _Offset + _Count <= size() may overflow, so use
_Count <= size() - _Offset instead. Note that this is safe due to
the previous constraint that _Offset <= size().
Patch by Michael Schellenberger Costa.
Differential Revision: https://reviews.llvm.org/D71998
The extent of the returned span was always std::dynamic_extent, which
is incorrect.
Thanks to Michael Schellenberger Costa for the patch.
Differential Revision: https://reviews.llvm.org/D71997
size_t is always greater than 0, so remove the artifact from the old
index_type.
Patch by Michael Schellenberger Costa.
Differential Revision: https://reviews.llvm.org/D71996
Summary: This change reflows a comment line. This change serves as a no-op test commit
Reviewers: mclow.lists, ldionne, EricWF
Subscribers: dexonsmith, christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D73552
Summary:
This patch implements https://wg21.link/P0325.
Please mind that at it is my first contribution to libc++, so I may have forgotten to abide to some conventions.
Reviewers: EricWF, mclow.lists, ldionne, lichray
Reviewed By: ldionne, lichray
Subscribers: lichray, dexonsmith, zoecarver, christof, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D69882
Summary:
FreeBSD got `timespec_get` support somewhere in the 12.x timeframe, but
the C++ version check in its system headers was written incorrectly.
This has now been fixed for both FreeBSD 13 and 12.
Add checks for the corresponding `__FreeBSD_version` values, to define
`_LIBCPP_HAS_TIMESPEC_GET` when the function is supported.
Reviewers: emaste, EricWF, ldionne, mclow.lists
Reviewed By: ldionne
Subscribers: arichardson, krytarowski, christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D71522
This fixes using non-default locales, which currently can crash when
e.g. formatting numbers.
Within the localeconv_l function, the per-thread locale is temporarily
changed with __libcpp_locale_guard, then localeconv() is called,
returning an lconv * struct pointer.
When localeconv_l returns, the __libcpp_locale_guard dtor restores
the per-thread locale back to the original. This invalidates the
contents of the earlier returned lconv struct, and all C strings
that are pointed to within it are also invalidated.
Thus, to have an actually working localeconv_l function, the
function needs to allocate some sort of storage for the returned
contents, that stays valid for as long as the caller needs to use
the returned struct.
Extend the libcxx/win32 specific locale_t class with storage for
a deep copy of a lconv struct, and change localeconv_l to take
a reference to the locale_t, to allow it to store the returned
lconv struct there.
This works fine for libcxx itself, but wouldn't necessarily be right
for a caller that uses libcxx's localeconv_l function.
This fixes around 11 of libcxx's currently failing tests on windows.
Differential Revision: https://reviews.llvm.org/D69505
Summary:
The libcxx test suite auto-detects spaceship operator, but __config does not. This means that the libcxx test suite has been broken for over a month when using top-of-tree clang. This also really ought to be fixed before 10.0.
See: bc633a42dd
Reviewers: chandlerc, mclow.lists, EricWF, ldionne, CaseyCarter
Reviewed By: EricWF
Subscribers: broadwaylamb, hans, dexonsmith, tstellar, llvm-commits, libcxx-commits
Tags: #libc, #llvm
Differential Revision: https://reviews.llvm.org/D72980
Summary:
The compiler already treats them as scalar types, so the library should
too. Furthermore, this allows blocks to be used in more places, for
example in std::optional, which requires an object type.
rdar://problem/57892832
Reviewers: dexonsmith, EricWF, mclow.lists
Differential Revision: https://reviews.llvm.org/D72708
This reverts commit a8a9c8e0a1.
There are multiple reported failures caused by this change.
Each failure is really weird, but it makes sense to revert
while investigating.
We switched to C11 thread API on Fuchsia in ab9aefe, but further
testing showed that Fuchsia's C11 mutex implementation needs a few
improvements for this to be usable, so we temporarily switch back
to the pthread implementation until those issues are addressed.
Differential Revision: https://reviews.llvm.org/D72862
The C11 API specifies that to initialize a recursive mutex,
mtx_plain | mtx_recursive should be used with mtx_init.
Differential Revision: https://reviews.llvm.org/D72809
The GCC build failures have been addressed, and the LLDB failures were
fixed by LLDB.
I have also verified that the apple-clang 9.0 segfault no longer
occurs.
Original Message:
The external instantiation of std::string is a problem for libc++.
Additions and removals of inline functions in string can cause ABI
breakages, including introducing new symbols.
This patch aims to:
(1) Make clear which functions are explicitly instatiated.
(2) Prevent new functions from being accidentally instantiated.
(3) Allow a migration path for adding or removing functions from the
explicit instantiation over time.
Although this new formulation is uglier, it is preferable from a
maintainability and readability standpoint because it explicitly
enumerates the functions we've chosen to expose in our ABI. Changing
this list is non-trivial and requires thought and planning.
(3) is achieved by making it possible to control the extern template declaration
separately from it's definition. Meaning we could add a new definition to
the dylib, wait for it to roll out, then add the extern template
declaration to the header. Similarly, we could remove existing extern
template declarations while still keeping the definition to prevent ABI
breakages.
This patch is needed in order to work around a GCC bug that fails to
explicitly instantiate a non-template function of a class template when
there is another overload that's a function template.
(See https://godbolt.org/z/4bUQ_b)
This patch SFINAE's away the function templates when the argument is
a basic_string.
On Fuchsia, pthread API is emulated on top of C11 thread API. Using C11
thread API directly is more efficient.
While this implementation is only used by Fuchsia at the moment, it's
not Fuchsia specific, and could be used by other platforms that use C11
threads rather than pthreads in the future.
Differential Revision: https://reviews.llvm.org/D64378
This also makes this function consistent with the rest of the
libc++ provided fallbacks.
The locale support in msvcrt.dll is very limited anyway; it can
only be configured processwide, not per thread, and it only seems
to support the locales "C" and "" (the user set locale), so it's
hard to make any meaningful automatic test for it. But manually tested,
this change does make time formatting locale code in libc++ output
times in the user requested format, when using locale "".
Differential Revision: https://reviews.llvm.org/D69554
The external instantiation of std::string is a problem for libc++.
Additions and removals of inline functions in string can cause ABI
breakages, including introducing new symbols.
This patch aims to:
(1) Make clear which functions are explicitly instatiated.
(2) Prevent new functions from being accidentally instantiated.
(3) Allow a migration path for adding or removing functions from the
explicit instantiation over time.
Although this new formulation is uglier, it is preferable from a
maintainability and readability standpoint because it explicitly
enumerates the functions we've chosen to expose in our ABI. Changing
this list is non-trivial and requires thought and planning.
(3) is achieved by making it possible to control the extern template declaration
separately from it's definition. Meaning we could add a new definition to
the dylib, wait for it to roll out, then add the extern template
declaration to the header. Similarly, we could remove existing extern
template declarations while still keeping the definition to prevent ABI
breakages.
Summary:
`__has_attribute(fallthough)` -> `__has_attribute(fallthrough)`
This is a follow-up of https://reviews.llvm.org/D72287
Reviewers: EricWF, mclow.lists, Jim
Reviewed By: Jim
Subscribers: christof, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D72314
Add NetBSD to the same feature list as Fuchsia since it matches
in available features, effectively enabling aligned_alloc(),
timespec_get() and C11 features. Remove now-duplicate declaration
of quick_exit() support.
Differential Revision: https://reviews.llvm.org/D71511
This patch de-duplicates most compressed pair constructors
to use the same code in C++11 and C++03.
Part of doing that is deleting the "__second_tag()" and replacing
it with a "__value_init_tag()" which has the same effect, but
allows for the removal of the special "one-arg" first element
constructor.
This patch is intended to have no semantic change.
This change introduces the __default_init_tag to memory, and a corresponding
element constructor to allow for default initialization of either of the pair
values. This is useful for classes such as std::string where most (all)
constructors explicitly initialize the values in the constructor.
Patch by Martijn Vels (mvels@google.com)
Reviewed as https://reviews.llvm.org/D70617
Too many warnings are being disabled too quickly. Warnings are
important to keeping libc++ correct. This patch re-enables two
warnings: -Wconstant-evaluated and -Wdeprecated-copy.
In future, all warnings disabled for the test suite should require
an attached bug. The bug should state the plan for re-enabling that
warning, or a strong case why it should remain disabled.
Since C++11, [depr.impldec]:
The implicit definition of a copy constructor as defaulted is deprecated
if the class has a user-declared copy assignment operator or a
user-declared destructor.
At clang HEAD, -Wdeprecated-copy (included by -Wextra) will warn on such instances.
Reviewed By: EricWF
Differential Revision: https://reviews.llvm.org/D71096
Android API level 21 and above have all these functions available, so we
don't need to include our fallback definitions.
Differential Revision: https://reviews.llvm.org/D69983
Summary:
Android added quick_exit()/at_quick_exit() in API level 21,
aligned_alloc() in API level 28, and timespec_get() in API level 29,
but has the other C11 features at all API levels (since they're basically
just coming from clang directly).
_LIBCPP_HAS_QUICK_EXIT and _LIBCPP_HAS_TIMESPEC_GET already existed,
so we can reuse them. (And use _LIBCPP_HAS_TIMESPEC_GET in a few more
places where _LIBCPP_HAS_C11_FEATURES has been used as a proxy. This
isn't correct for Android.)
_LIBCPP_HAS_ALIGNED_ALLOC is added, to cover aligned_alloc() (obviously).
Add a missing std:: before aligned_alloc in a cstdlib test, and remove a
couple of !defined(_WIN32)s now that we're explicitly testing
TEST_HAS_ALIGNED_ALLOC rather than TEST_HAS_C11_FEATURES.
Reviewers: danalbert, EricWF, mclow.lists
Reviewed By: danalbert
Subscribers: srhines, christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D69929
With the upcoming introduction of iterator concepts in ranges,
the meaning of "__is_contiguous_iterator" changes drastically.
Currently we intend it to mean "does it have this iterator category",
but it could now also mean "does it meet the requirements of this
concept", and these can be different.
These traits are currently unused because we don't implement ranges.
However, their addition is part of ongoing work to allow libc++
to optimize on user-provided contiguous iterators.
This function has the same behavior as the now-standand std::to_address.
Re-using the name makes the behavior more clear, and in the future it
will allow us to correctly get the raw pointer for user provided pointer
types.
We effectively never want to export that function, which is an
implementation detail of libc++. This was previously tried in
603715c66b and then reverted in 8335dd314f because it caused
linker warnings. These linker warnings should go away now that we
use internal_linkage instead of always_inline to implement per-TU
insulation.
This change would have warned about the bug found in D62451.
No unit tests since the exception should never throw.
Differential Revision: https://reviews.llvm.org/D62452
Same idea as the current algorithm, that is, add (half of the difference between a and b) to a.
But we use a different technique for computing the difference: we compute b - a into a pair of integers that are named "sign_bit" and "diff". We have to use a pair because subtracting two 32-bit integers produces a 33-bit result.
Computing half of that is a simple matter of shifting diff right by 1, and adding sign_bit shifted left by 31. llvm knows how to do that with one instruction: shld.
The only tricky part is that if the difference is odd and negative, then shifting it by one isn't the same as dividing it by two - shifting a negative one produces a negative one, for example. So there's one more adjustment: if the sign bit and the low bit of diff are one, we add one.
For a demonstration of the codegen difference, see https://godbolt.org/z/7ar3K9 , which also has a built-in test.
Differential Revision: https://reviews.llvm.org/D69459
PR13592 was caused by a problem in how to compiler implemented the
__is_convertible_to intrinsic. That problem, reported as PR13591,
was fixed back in 2012. We don't support such old versions of Clang
anyway, so we don't need the library workaround that had been added
to solve PR13592 (while waiting for the compiler fix).
Summary: This patch removes `shared_ptr::make_shared` as it is not part of the standard. This patch also adds __create_with_cntrl_block, which is a help function that can be used in std::allocate_shared and std::make_shared. This is the third patch (out of 4) from D66178.
Reviewers: EricWF, mclow.lists, ldionne
Subscribers: christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68805
llvm-svn: 375504
Summary:
In D67316 we added `_LIBCPP_C_HAS_NO_GETS` to signal that the C library
does not provide `gets()`, and added a test for FreeBSD 13 or higher,
using the compiler-defined `__FreeBSD__` macro.
Unfortunately this did not work that well for FreeBSD's own CI process,
since the gcc compilers used for some architectures define `__FreeBSD__`
to match the build host, not the target.
Instead, we should use the `__FreeBSD_version` macro from the userland
header `<osreldate.h>`, which is more fine-grained. See also
<https://reviews.freebsd.org/D22034>.
Reviewers: EricWF, mclow.lists, emaste, ldionne
Reviewed By: emaste, ldionne
Subscribers: dexonsmith, bsdjhb, krytarowski, christof, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D69174
llvm-svn: 375340
Summary: The implementation of P1152R4 in Clang has resulted in some deprecation warnings appearing in the libc++ and libc++abi test suite. Fix or suppress these warnings.
Reviewers: mclow.lists, EricWF
Subscribers: christof, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68879
llvm-svn: 375307
Summary: In my last patch (D67675) I forgot a few variadics. This patch removes the remaining make_shared and allocate_shared C++03 variadics.
Reviewers: ldionne, EricWF, mclow.lists
Subscribers: christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68000
llvm-svn: 373971
Summary:
LWG 3158 marks the allocator_arg_t constructor of std::tuple as
conditionnally explicit based on whether the default constructors
of the tuple's members are explicitly default constructible.
This was previously committed as r372778 and reverted in r372832 due to
the commit breaking LLVM's build in C++14 mode. This issue has now been
addressed.
Reviewers: mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65232
llvm-svn: 373092
Summary:
LWG2510 makes tag types like allocator_arg_t explicitly default
constructible instead of implicitly default constructible. It also
makes the constructors for std::pair and std::tuple conditionally
explicit based on the explicit-ness of the default constructibility
for the pair/tuple's elements.
This was previously committed as r372777 and reverted in r372832 due to
the commit breaking LLVM's build in C++14 mode. This issue has now been
addressed.
Reviewers: mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65161
llvm-svn: 372983
Users should only get the assert() macros if they explicitly include
them.
Found after switching from the GNU C++ stdlib to the LLVM C++ stdlib.
llvm-svn: 372963
This declaration was previously missing despite appearing in the
synopsis. Users are still required to include <ostream> to get the
definition of the streaming operator.
llvm-svn: 372909
This also reverts:
- r372778: [libc++] Implement LWG 3158
- r372782: [libc++] Try fixing tests that fail on GCC 5 and older
- r372787: Purge mentions of GCC 4 from the test suite
Reason: the change breaks compilation of LLVM with libc++, for details see
http://lists.llvm.org/pipermail/libcxx-dev/2019-September/000599.html
llvm-svn: 372832
Summary: As suggested by @ldionne in D66178, this patch removes C++03 variadics //only//. Following patches will apply more updates.
Reviewers: ldionne, EricWF, mclow.lists
Subscribers: christof, dexonsmith, libcxx-commits, ldionne
Tags: #libc
Differential Revision: https://reviews.llvm.org/D67675
llvm-svn: 372780
Summary:
LWG 3158 marks the allocator_arg_t constructor of std::tuple as
conditionnally explicit based on whether the default constructors
of the tuple's members are explicitly default constructible.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65232
llvm-svn: 372778
Summary:
LWG2510 makes tag types like allocator_arg_t explicitly default
constructible instead of implicitly default constructible. It also
makes the constructors for std::pair and std::tuple conditionally
explicit based on the explicit-ness of the default constructibility
for the pair/tuple's elements.
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65161
llvm-svn: 372777
std::condition_variable is currently implemented via
pthread_cond_timedwait() on systems that use pthread. This is
problematic, since that function waits by default on CLOCK_REALTIME
and libc++ does not provide any mechanism to change from this
default.
Due to this, regardless of if condition_variable::wait_until() is
called with a chrono::system_clock or chrono::steady_clock parameter,
condition_variable::wait_until() will wait using CLOCK_REALTIME. This
is not accurate to the C++ standard as calling
condition_variable::wait_until() with a chrono::steady_clock parameter
should use CLOCK_MONOTONIC.
This is particularly problematic because CLOCK_REALTIME is a bad
choice as it is subject to discontinuous time adjustments, that may
cause condition_variable::wait_until() to immediately timeout or wait
indefinitely.
This change fixes this issue with a new POSIX function,
pthread_cond_clockwait() proposed on
http://austingroupbugs.net/view.php?id=1216. The new function is
similar to pthread_cond_timedwait() with the addition of a clock
parameter that allows it to wait using either CLOCK_REALTIME or
CLOCK_MONOTONIC, thus allowing condition_variable::wait_until() to
wait using CLOCK_REALTIME for chrono::system_clock and CLOCK_MONOTONIC
for chrono::steady_clock.
pthread_cond_clockwait() is implemented in glibc (2.30 and later) and
Android's bionic (Android API version 30 and later).
This change additionally makes wait_for() and wait_until() with clocks
other than chrono::system_clock use CLOCK_MONOTONIC.<Paste>
llvm-svn: 372016
exceptions are disabled.
The patch was reverted due to some confusion about non-movable types. ie
types
that explicitly delete their move constructors. However, such types do
not meet
the requirement for `MoveConstructible`, which is required by
`std::vector`:
Summary:
`std::vector<T>` is free choose between using copy or move operations
when it
needs to resize. The standard only candidates that the correct exception
safety
guarantees are provided. When exceptions are disabled these guarantees
are
trivially satisfied. Meaning vector is free to optimize it's
implementation by
moving instead of copying.
This patch makes `std::vector` unconditionally move elements when
exceptions are
disabled. This optimization is conforming according to the current
standard wording.
There are concerns that moving in `-fno-noexceptions`mode will be a
surprise to
users. For example, a user may be surprised to find their code is slower
with
exceptions enabled than it is disabled. I'm sympathetic to this
surprised, but
I don't think it should block this optimization.
Reviewers: mclow.lists, ldionne, rsmith
Reviewed By: ldionne
Subscribers: zoecarver, christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D62228
llvm-svn: 371867
Summary:
In https://svnweb.freebsd.org/changeset/base/351659 @emaste removed gets() from
FreeBSD 13's libc, and our copies of libc++ and libstdc++. In that change, the
declarations were simply deleted, but I would like to propose this conditional
test instead.
Reviewers: EricWF, mclow.lists, emaste
Reviewed By: mclow.lists
Subscribers: krytarowski, christof, ldionne, emaste, libcxx-commits
Differential Revision: https://reviews.llvm.org/D67316
llvm-svn: 371324
This reverts r370502, which broke the use case of a copy-only T (with a
deleted move constructor) when exceptions are disabled. Until we figure
out the right behavior, I'm reverting the commit.
llvm-svn: 371068
This is needed anytime we need to clamp an arbitrary floating point
value to an integer type.
Thanks to Eric Fiselier for the patch.
Differential Revision: https://reviews.llvm.org/D66836
llvm-svn: 370891
An upcoming change in Clang will flag _Atomic as being a C11 extension.
To avoid generating this warning in libc++, this commit marks the only
use of _Atomic with the __extension__ extension, which suppresses such
warnings.
llvm-svn: 370796
Summary:
`std::vector<T>` is free choose between using copy or move operations when it needs to resize. The standard only candidates that the correct exception safety guarantees are provided. When exceptions are disabled these guarantees are trivially satisfied. Meaning vector is free to optimize it's implementation by moving instead of copying.
This patch makes `std::vector` unconditionally move elements when exceptions are disabled.
This optimization is conforming according to the current standard wording.
There are concerns that moving in `-fno-noexceptions`mode will be a surprise to users. For example, a user may be surprised to find their code is slower with exceptions enabled than it is disabled. I'm sympathetic to this surprised, but I don't think it should block this optimization.
Reviewers: mclow.lists, ldionne, rsmith
Reviewed By: ldionne
Subscribers: zoecarver, christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D62228
llvm-svn: 370502
Since we build the library with -fvisibility=hidden, the shared object
wouldn't contain __vector_base_common<true>::__throw_length_error()
and __vector_base_common<true>::__throw_out_of_range(), leading to
link errors. This only happened on GCC for some reason.
https://llvm.org/PR43140
llvm-svn: 370240
_LIBCPP_HAS_THREAD_API_EXTERNAL is not defined.
When it is defined they will be declared by the
__external_threading header instead.
Differential revision: https://reviews.llvm.org/D66518
llvm-svn: 369537
Summary:
The resolution of LWG 3199 makes sure that input-streaming into an empty bitset
does not set the failbit on the input stream.
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65105
llvm-svn: 369422
A new clang warning introduced in r367497 was complaining about
the change in value.
Thanks to Brian Cain for the patch.
Differential Revision: https://reviews.llvm.org/D66422
llvm-svn: 369393
The commit being reverted caused segfaults when building
with libc++ and GCC (and possibly other configurations).
Differential Revision: https://reviews.llvm.org/D62868
llvm-svn: 369270
In r292833, we started defining _LIBCPP_CLANG_VER to 0 for Apple Clang.
The result is that AppleClang is detected as being a very old version
of LLVM Clang (version 0), which is obviously incorrect.
I believe this was added so that we don't have to check whether
_LIBCPP_CLANG_VER is defined prior to comparing it with a number
(which can trigger a warning). This commit also fixes the two
places that use the macro correspondingly.
llvm-svn: 368880
Summary:
This avoids symbols being accidentally exported from the dylib when they
shouldn't. The next step is to use a pragma to apply hidden visibility
to all declarations (unless otherwise specified), which will allow us
to drop the per-declaration hidden visibility attributes we currently
have.
This also has the nice side effect of making sure the dylib exports the
same symbols regardless of the optimization level.
PR38138
Reviewers: EricWF, mclow.lists
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D62868
llvm-svn: 368703
Summary:
D64914 added support for applying [[nodiscard]] to constructors. This
commit uses that capability to flag incorrect uses of std::lock_guard
where one forgets to actually create a variable for the lock_guard.
rdar://45790820
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits, Quuxplusone, lebedev.ri
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65900
llvm-svn: 368664
Summary:
We were using implicit deduction guides instead of explicit ones,
however the implicit ones don't do work anymore when changing the
constructors.
This commit adds the actual guides specified in the Standard to make
libc++ (1) closer to the Standard and (2) more resistent to changes
in std::tuple's constructors.
Reviewers: Quuxplusone
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65225
llvm-svn: 368599
This patch rewrites a few loops in deque and split_buffer to better
optimize the codegen. For constructors like
`deque<unsigned char> d(500000, 0);` this patch results in a 2x speedup.
The patch improves the codegen in roughly three ways:
1. Changes do { ... } while (...) loops into more typical for loops.
The optimizer can reason about normal looking loops better.
2. Split the iteration over a range into (A) iteration over the blocks,
then (B) iteration within the block. This nested structure helps LLVM
lower the inner loop to `memset`.
3. Do fewer things each iteration. Some of these loops were incrementing
or changing 4-5 variables every loop (in addition to the
construction). Previously most loops would increment the end pointer,
the size, and decrement the count of remaining items to construct.
Now we only increment a single pointer for most iterations.
llvm-svn: 368547
For the few (currently four) headers that make up the PSTL's interface
to other Standard Libraries, provide a stable uglified header file that
can be included by those Standard Libraries.
We can then more easily change the internal organization of the PSTL
without having to change the integration with Standard Libraries.
llvm-svn: 368088
Summary:
This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when
configuring libc++ in CMake. When that option is enabled, libc++ will
assume that the PSTL can be found somewhere on the CMake module path,
and it will provide the C++17 parallel algorithms based on the PSTL
(that is assumed to be available).
The commit also adds support for running the PSTL tests as part of
the libc++ test suite.
The first attempt to commit this failed because it exposed a bug in the
tests for modules. Now that this has been fixed, it should be safe to
commit this.
Reviewers: EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60480
llvm-svn: 367903
There are a handful of standard library types that are intended
to support CTAD but don't need any explicit deduction guides to
do so.
This patch adds a dummy deduction guide to those types to suppress
-Wctad-maybe-unsupported (which gets emitted in user code).
llvm-svn: 367770
This patch rewrites a number of old meta-function implementations
that assumed const/volatile could not be safely applied to all types.
This is no longer the case, though for some types (Ex function types),
the const qualifier can be ignored.
The largest improvement in this patch is the reduction of is_function.
Thanks to Matt Calabrese for the improved implementation.
llvm-svn: 367749
I have upcoming changes that modify how deque handles spare blocks.
This cleanup is intended to make those changes easier to review
and understand. This patch should have NFC.
llvm-svn: 367631
Previously these types rehashed to a table of 193 elements
upon construction. But this is non-ideal, first because default
constructors should not allocate unless necessary, and second
because 193 is big and can waste a bunch of memory.
This number had previously been chosen to match GCC's implementation.
llvm-svn: 367605
[cpp.predefined]p2:
__STDCPP_THREADS__
Defined, and has the value integer literal 1, if and only if a program
can have more than one thread of execution .
Also define it only if it's not defined already, since it's supposed
to be defined by the compiler.
Also move it from thread to __config (which requires setting it only
if _LIBCPP_HAS_NO_THREADS is not defined).
Part of PR33230. The intent is to eventually make the compiler define
this instead.
llvm-svn: 367316
The optimizer is petulant and temperamental. In this case LLVM failed to lower
the the "insert at end" loop used by`vector<unsigned char>` to a `memset` despite
`memset` being substantially faster over a range of bytes.
LLVM has the ability to lower loops to `memset` whet appropriate, but the
odd nature of libc++'s loops prevented the optimization from taking places.
This patch addresses the issue by rewriting the loops from the form
`do [ ... --__n; } while (__n > 0);` to instead use a for loop over a pointer
range (For example: `for (auto *__i = ...; __i < __e; ++__i)`).
This patch also rewrites the asan annotations to unposion all additional memory
at the start of the loop instead of once per iterations. This could potentially
permit false negatives where the constructor of element N attempts to access
element N + 1 during its construction.
The before and after results for the `BM_ConstructSize/vector_byte/5140480_mean`
benchmark (run 5 times) are:
--------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------------------------------------
Before
------
BM_ConstructSize/vector_byte/5140480_mean 12530140 ns 12469693 ns N/A
BM_ConstructSize/vector_byte/5140480_median 12512818 ns 12445571 ns N/A
BM_ConstructSize/vector_byte/5140480_stddev 106224 ns 107907 ns 5
-----
After
-----
BM_ConstructSize/vector_byte/5140480_mean 167285 ns 166500 ns N/A
BM_ConstructSize/vector_byte/5140480_median 166749 ns 166069 ns N/A
BM_ConstructSize/vector_byte/5140480_stddev 3242 ns 3184 ns 5
llvm-svn: 367183
The constructors for std::pair and std::tuple have been made conditionally
explicit, however the synopsis in the headers do not reflect that.
llvm-svn: 366735
This issue was detected by ASan in one of our tests. This test manually
invokes basic_filebuf::cloe(). fclose(__h.release() returned a non-zero
exit status, so __file_ wasn't set to 0. Later when basic_filebuf
destructor ran, we would enter the if (__file_) block again leading to
heap-use-after-free error.
The POSIX specification for fclose says that independently of the return
value, fclose closes the underlying file descriptor and any further
access (including another call to fclose()) to the stream results in
undefined behavior. This is exactly what happened in our test case.
To avoid this issue, we have to always set __file_ to 0 independently of
the fclose return value.
Differential Revision: https://reviews.llvm.org/D64979
llvm-svn: 366730
This reverts r366593, which caused unforeseen breakage on the build bots.
I'm reverting until the problems have been figured out and fixed.
llvm-svn: 366603
Summary:
This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when
configuring libc++ in CMake. When that option is enabled, libc++ will
assume that the PSTL can be found somewhere on the CMake module path,
and it will provide the C++17 parallel algorithms based on the PSTL
(that is assumed to be available).
The commit also adds support for running the PSTL tests as part of
the libc++ test suite.
Reviewers: rodgert, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60480
llvm-svn: 366593
Summary:
This is effectively a revert of r344616, which was a partial fix for
PR38964 (compilation of <string> with GCC in C++03 mode). However, that
configuration is explicitly not supported anymore and that partial fix
breaks compilation with Clang when per-TU insulation is provided.
PR42676
rdar://52899715
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D64941
llvm-svn: 366567
In particular, improve the compile time of the overload set builder
that variant uses to determine which alternative to construct.
Instead of having the __overload type construct itself recursively,
this patch uses a flat construction for the overload set.
llvm-svn: 366033
The standard disallows narrowing conversions when constructing a variant.
This is checked by attempting to perform braced initialization of the
destination type from the argument type. However, braced initialization
can force the compiler (mostly clang) to eagerly instantiate the
constructors of the destintation type -- which can lead to errors in
a non-immediate context.
However, as variant is currently specified, the narrowing checks only
observably apply when the destination type is arithmetic. Meaning we can
skip the check for class types. Hense avoiding the hard errors.
In order to cause fewer build breakages, this patch avoids the narrowing
check except when the destination type is arithmetic.
llvm-svn: 366022
Previously we implemented all one trillion tuple-like constructors using
a single generic overload. This worked fairly well, except that it
differed in behavior from the standard version because it didn't
consider both T&& and T const&. This was observable for certain
types.
This patch addresses that issue by splitting the generic constructor
in two. We now provide both T&& and T const& versions of the
tuple-like constructors (sort of).
llvm-svn: 365973
The paper P0608R3 - "A sane variant converting constructor" disallows
narrowing conversions in variant. It was meant to address this
surprising problem:
std::variant<std::string, bool> v = "abc";
assert(v.index() == 1); // constructs a bool.
However, it also disables every potentially narrowing conversion. For
example:
variant<unsigned> v = 0; // ill-formed
variant<string, double> v2 = 42; // ill-formed (int -> double narrows)
These latter changes break code. A lot of code. Within Google it broke
on the order of a hundred thousand target with thousands of root causes
responsible for the breakages.
Of the breakages related to the narrowing restrictions, none of them
exposed outstanding bugs. However, the breakages caused by boolean
conversions (~13 root causes), all but one of them were bugs.
For this reasons, I am adding a flag to disable the narrowing conversion
changes but not the boolean conversions one.
One purpose of this flag is to allow users to opt-out of breaking changes
in variant until the offending code can be cleaned up. For non-trivial
variant usages the amount of cleanup may be significant.
This flag is also required to support automated tooling, such as
clang-tidy, that can automatically fix code broken by this change.
In order for clang-tidy to know the correct alternative to construct,
it must know what alternative was being constructed previously, which
means running it over the old version of std::variant.
Because this change breaks so much code, I will be implementing the
aforementioned clang-tidy check in the very near future.
Additionally I'm plan present this new information to the committee so they can
re-consider if this is a breaking change we want to make.
I think libc++ should very seriously consider pulling this change
before the 9.0 release branch is cut. But that's a separate discussion
that I will start on the lists.
For now this is the minimal first step.
llvm-svn: 365960
When assigning an initializer list into set/map, libc++ would
leak memory if the initializer list contained equivalent keys
because we failed to check if the insertion was successful.
llvm-svn: 365840
The implementations of __libcpp_mutex_destroy and __libcpp_condvar_destroy
are already NOPs, so this optimization is safe to perform.
See r365273 and PR27658 for more information.
llvm-svn: 365281
Currently std::mutex has a constexpr constructor, but a non-trivial
destruction.
The constexpr constructor is required to ensure the construction of a
mutex with static storage duration happens at compile time, during
constant initialization, and not during dynamic initialization.
This means that static mutex's are always initialized and can be used
safely during dynamic initialization without the "static initialization
order fiasco".
A trivial destructor is important for similar reasons. If a mutex is
used during dynamic initialization it might also be used during program
termination. If a static mutex has a non-trivial destructor it will be
invoked during termination. This can introduce the "static
deinitialization order fiasco".
Additionally, function-local statics emit a guard variable around
non-trivially destructible types. This results in horrible codegen and
adds a runtime cost to every call to that function. non-local static's
also result in slightly worse codegen but it's not as big of a problem.
Example codegen can be found here: https://goo.gl/3CSzbM
Note: This optimization is not safe with every pthread implementation.
Some implementations allocate on the first call to pthread_mutex_lock
and free the allocation in pthread_mutex_destroy.
Also, changing the triviality of the destructor is not an ABI break.
At least to the best of my knowledge :-)
llvm-svn: 365273
types.
It seems some people like to write types that can explicitly convert
to anything, but cannot be used to explicitly construct anything.
This patch makes tuple tolerate such types, as is required
by the standard.
llvm-svn: 365074
Summary:
This fixes a clang-tidy warning when building something that uses
this file.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43226
llvm-svn: 364799
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
This is a fairly large patch that implements all of the filesystem NB comments
and the relative paths changes (ex. adding weakly_canonical). These issues
and papers are all interrelated so their implementation couldn't be split up
nicely.
This patch upgrades <experimental/filesystem> to match the C++17 spec and not
the published experimental TS spec. Some of the changes in this patch are both
API and ABI breaking, however libc++ makes no guarantee about stability for
experimental implementations.
The major changes in this patch are:
* Implement NB comments for filesystem (P0492R2), including:
* Implement `perm_options` enum as part of NB comments, and update the
`permissions` function to match.
* Implement changes to `remove_filename` and `replace_filename`
* Implement changes to `path::stem()` and `path::extension()` which support
splitting examples like `.profile`.
* Change path iteration to return an empty path instead of '.' for trailing
separators.
* Change `operator/=` to handle absolute paths on the RHS.
* Change `absolute` to no longer accept a current path argument.
* Implement relative paths according to NB comments (P0219r1)
* Combine `path.cpp` and `operations.cpp` since some path functions require
access to the operations internals, and some fs operations require access
to the path parser.
llvm-svn: 329028
This patch corrects num_get for unsigned types to support strings
with a leading `-` character. According to the standard the
number should be parsed as an unsigned integer and then
negated.
llvm-svn: 328751
The NB comments for filesystem changed permissions and added
a new enum `perm_options` which control how the permissions
are applied.
This implements than NB resolution
llvm-svn: 328476
This partially reverts commit r328261. The GCC bug has been fixed in
trunk and has never existed in a released version. Therefore the changes
to variant are unneeded.
However, the additional tests have been left in place.
llvm-svn: 328388
This patch works around variant test failures which are new to
GCC 8. GCC 8 either doesn't perform SFINAE in lexical order, or
it doesn't halt after encountering the first failure. This
causes hard error to occur instead of substitution failure.
See gcc.gnu.org/PR78489
llvm-svn: 328261
This patch fixes std::allocator, and more specifically, all users
of __libcpp_allocate and __libcpp_deallocate, to support over-aligned
types.
__libcpp_allocate/deallocate now take an alignment parameter, and when
the specified alignment is greater than that supported by malloc/new,
the aligned version of operator new is called (assuming it's available).
When aligned new isn't available, the old behavior has been kept, and the
alignment parameter is ignored.
This patch depends on recent changes to __builtin_operator_new/delete which
allow them to be used to call any regular new/delete operator. By using
__builtin_operator_new/delete when possible, the new/delete erasure optimization
is maintained.
llvm-svn: 328180
When the generated __config file is being used, it is currently only
copied during installation process. However, that means that the file
that gets copied into LLVM build directory is the vanilla __config file,
and any parts of the build that depend on the just built toolchain like
sanitizers will get that instead of the generated version. To avoid this
issue, we need to copy the generated header into the LLVM build
directory as well.
Differential Revision: https://reviews.llvm.org/D43797
llvm-svn: 327194
shrink_to_fit() ends up doing a lot work to get information that we
already know since we just called clear(). This change seems concise
enough to be worth the couple extra lines and my benchmarks show that it
is indeed a pretty decent win. It looks like the same thing is going on
twice in __copy_assign_alloc(), but I didn't want to go overboard since
this is my first contribution to llvm/libc++.
Patch by Timothy VanSlyke!
Differential Revision: https://reviews.llvm.org/D41976
llvm-svn: 327064
This commit indents each level by two space characters, e.g.
#if defined(CONDITION)
# define _LIBCPP_NAME VALUE
#else
# define _LIBCPP_NAME VALUE
#endif
The simple #ifndef, #define, and #endif sequences are not indented, e.g.
#ifndef _LIBCPP_NAME
#define _LIBCPP_NAME ...
#endif
llvm-svn: 326027
Summary:
Certain C libraries require configuration macros defined in __config
to provide the correct functionality for libc++. This patch ensures
that the C header math.h is always included after the __config
header. It also adds a Windows-specific #if guard for the case when
the C math.h file is included the second time, as suggested by
Marshall in https://reviews.llvm.org/rL323490.
Fixes PR36382.
Reviewers: mclow.lists, EricWF
Reviewed By: mclow.lists
Subscribers: cfe-commits, pcc, christof, rogfer01
Differential Revision: https://reviews.llvm.org/D43579
llvm-svn: 325760
Summary:
Currently std::asinh and std::acosh use std::pow to compute x^2. This
results in a significant error when computing e.g. asinh(i) or
acosh(-1).
This patch expresses x^2 directly via x.real() and x.imag(), like it
is done in libstdc++/glibc, and adds tests that checks the accuracy.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D41629
llvm-svn: 325510
Summary:
Compiling `<functional>` in C++17 or higher mode results in:
```
functional:2500:1: warning: attribute '__visibility__' is ignored, place it after "class" to apply attribute to type declaration [-Wignored-attributes]
_LIBCPP_TYPE_VIS
^
__config:701:46: note: expanded from macro '_LIBCPP_TYPE_VIS'
# define _LIBCPP_TYPE_VIS __attribute__ ((__visibility__("default")))
^
1 warning generated.
```
Fix it by putting the attribute after the `class` keyword.
Reviewers: EricWF, mclow.lists
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43209
llvm-svn: 325027
Patch from charlieio@outlook.com
Reviewed as https://reviews.llvm.org/D42354
When the following command is used:
> clang-cl -std:c++17 -Iinclude\c++\v1 hello.cc c++.lib
An error occurred:
In file included from hello.cc:1:
In file included from include\c++\v1\iostream:38:
In file included from include\c++\v1\ios:216:
In file included from include\c++\v1\__locale:15:
In file included from include\c++\v1\string:477:
In file included from include\c++\v1\string_view:176:
In file included from include\c++\v1\__string:56:
In file included from include\c++\v1\algorithm:643:
In file included from include\c++\v1\memory:656:
include\c++\v1\new(165,29): error: redefinition of 'align_val_t'
enum class _LIBCPP_ENUM_VIS align_val_t : size_t { };
^
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.12.25827\include\vcruntime_new.h(43,16): note:
previous definition is here
enum class align_val_t : size_t {};
^
1 error generated.
vcruntime_new.h has defined align_val_t, libcxx need hide align_val_t.
This patch fixes that error.
llvm-svn: 324853
Patch from ngolovliov@gmail.com
Reviewed as: https://reviews.llvm.org/D42344
As described in llvm.org/PR30959, the current
implementation of std::{map, key}::{count, equal_range} in libcxx is
non-conforming. Quoting the C++14 standard [associative.reqmts]p3
> The phrase “equivalence of keys” means the equivalence relation imposed by
> the comparison and not the operator== on keys. That is, two keys k1 and k2 are
> considered to be equivalent if for the comparison object comp,
> comp(k1, k2) == false && comp(k2, k1) == false.
In the same section, the requirements table states the following:
> a.equal_range(k) equivalent to make_pair(a.lower_bound(k), a.upper_bound(k))
> a.count(k) returns the number of elements with key equivalent to k
The behaviour of libstdc++ seems to conform to the standard here.
llvm-svn: 324799
Summary:
Currently libc++ implements some operations on valarray by using the
resize method. This method has a parameter with a default value.
Because of this, valarray may spuriously construct and destruct
objects of valarray's element type.
This patch fixes this issue and adds corresponding test cases.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: rogfer01, cfe-commits
Differential Revision: https://reviews.llvm.org/D41992
llvm-svn: 324596
An array T[1] isn't necessarily the same say when it's
a member of a struct. This patch addresses that problem and corrects
the tests to deal with it.
llvm-svn: 324545
Summary:
This patch fixes llvm.org/PR35491 and LWG2157 (https://cplusplus.github.io/LWG/issue2157)
The fix attempts to maintain ABI compatibility by replacing the array with a instance of `aligned_storage`.
Reviewers: mclow.lists, EricWF
Reviewed By: EricWF
Subscribers: lichray, cfe-commits
Differential Revision: https://reviews.llvm.org/D41223
llvm-svn: 324526
Revert "Fix initialization of array<const T, 0> with GCC."
Revert "Make array<const T, 0> non-CopyAssignable and make swap and fill ill-formed."
This reverts commit r324182, r324185, and r324194 which were causing issues with zero-length std::arrays.
llvm-svn: 324309
Previously, when handling zero-sized array of const objects we
used a const version of aligned_storage_t, which is not an array type.
However, GCC complains about initialization of the form: array<const T, 0> arr = {};
This patch fixes that bug by making the dummy object used to represent
the zero-sized array an array itself. This avoids GCC's complaints
about the uninitialized const member.
llvm-svn: 324194
This patch removes the noexcept declaration from filesystem
operations which require creating temporary paths or
creating a directory iterator. Either of these operations
can throw.
llvm-svn: 324192
Because path can be constructed from a ton of different types, including string
and wide strings, this caused it's streaming operators to suck up all sorts
of silly types via silly conversions. For example:
using namespace std::experimental::filesystem::v1;
std::wstring w(L"wide");
std::cout << w; // converts to path.
This patch tentatively adopts the resolution to LWG2989 and fixes the issue
by making the streaming operators friends of path.
llvm-svn: 324189
The standard isn't exactly clear how std::array should handle zero-sized arrays
with const element types. In particular W.R.T. copy assignment, swap, and fill.
This patch takes the position that those operations should be ill-formed,
and makes changes to libc++ to make it so.
This follows up on commit r324182.
llvm-svn: 324185
Summary:
This patch fixes llvm.org/PR35491 and LWG2157 (https://cplusplus.github.io/LWG/issue2157)
The fix attempts to maintain ABI compatibility by replacing the array with a instance of `aligned_storage`.
Reviewers: mclow.lists, EricWF
Reviewed By: EricWF
Subscribers: lichray, cfe-commits
Differential Revision: https://reviews.llvm.org/D41223
llvm-svn: 324182
According to [1], forms 2 and 4 of std::is_permutation should use the passed in
binary predicate to compare elements. operator== should only be used for forms
1 and 3 which do not take a binary predicate.
This CL fixes forms 2 and 4 which relied on operator== for some comparisons.
[1] http://en.cppreference.com/w/cpp/algorithm/is_permutation
Patch by Thomas Anderson!
Differential Revision: https://reviews.llvm.org/D42518
llvm-svn: 323563
We need to use the vcruntime declarations on Windows to avoid an
ODR violation involving rtti.obj, which provides the definition of
the runtime function implementing dynamic_cast and depends on the
vcruntime implementations of bad_cast and bad_typeid.
Differential Revision: https://reviews.llvm.org/D42220
llvm-svn: 323491
Code on Windows expects to be able to do:
#define _USE_MATH_DEFINES
#include <math.h>
and receive the definitions of mathematical constants, even if <math.h>
has previously been included. To support this scenario, re-include
<math.h> every time the wrapper header is included.
Differential Revision: https://reviews.llvm.org/D42403
llvm-svn: 323490
There was a bug in the implementation of splice where the container
sizes were updated before decrementing one of the iterators. Afterwards,
the result of decrementing the iterator was flagged as UB by the debug
implementation because the container was reported to be empty.
This patch fixes that bug by delaying the updating of the container
sizes until after the iterators have been correctly constructed.
llvm-svn: 323390
Summary:
See https://bugs.llvm.org/show_bug.cgi?id=20855
Libc++ goes out of it's way to diagnose `std::tuple` constructions which are UB due to lifetime bugs caused by reference creation. For example:
```
// The 'const std::string&' is created *inside* the tuple constructor, and its lifetime is over before the end of the constructor call.
std::tuple<int, const std::string&> t(std::make_tuple(42, "abc"));
```
However, we are over-aggressive and we incorrectly diagnose cases such as:
```
void foo(std::tuple<int const&, int const&> const&);
foo(std::make_tuple(42, 42));
```
This patch fixes the incorrectly diagnosed cases, as well as converting the diagnostic to use the newly added Clang trait `__reference_binds_to_temporary`. The new trait allows us to diagnose cases we previously couldn't such as:
```
std::tuple<int, const std::string&> t(42, "abc");
```
Reviewers: rsmith, mclow.lists
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41977
llvm-svn: 323380
Summary:
Currently when a regular expression contains an invalid character
class name std::regex constructors throw an std::regex_error with
std::regex_constants::error_brack code.
This patch changes the code to std::regex_constants::error_ctype and
adds a test.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42291
llvm-svn: 323322
Some users may have a custom build system which gives a different
name to the libc++ archive (or does not create an archive at all,
instead passing the object files directly to the linker). Give those
users a way to disable auto-linking.
Differential Revision: https://reviews.llvm.org/D42436
llvm-svn: 323300
The language standard does not define a function with this name,
so it is part of the user's namespace. This change fixes a duplicate
symbol error that occurs when a user attempts to define a function
with this name.
Differential Revision: https://reviews.llvm.org/D42405
llvm-svn: 323237
This is an MSVC standard library extension. It seems like a reasonable
enough extension to me because wchar_t* is the native format for
filenames on that platform.
Differential Revision: https://reviews.llvm.org/D42225
llvm-svn: 323170
This allows us to avoid polluting the namespace of users of <thread>
with the definitions in windows.h.
Differential Revision: https://reviews.llvm.org/D42214
llvm-svn: 323169
The specification of this function mandates a cast to uninitialized
T*, which is forbidden under CFI.
Differential Revision: https://reviews.llvm.org/D42146
llvm-svn: 322744
Inline the provided "fallback" definitions (which seem to always be
taken) that expand to __cdecl into users. The fallback definitions
for the *CRTIMP* macros were wrong in the case where the CRT is being
linked statically, so define our own macro as a replacement.
Differential Revision: https://reviews.llvm.org/D42158
llvm-svn: 322617
type 'result_type' to 'double'. The only thing that we ever do with
these numbers is to promote them to 'double' and use them in a division.
For small result_types, the values were getting truncated, skewing the
results. Thanks to James Nagurne for the suggestion.
llvm-svn: 322556
It covers the cases when the sentry object returns false and when an exception
was thrown. Corresponding standard paragraph is C++14 [istream.unformatted]p9:
[...] In any case, if n is greater than zero it then stores a null
character into the next successive location of the array.
rdar://problem/35566567
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40677
llvm-svn: 322326
An application may determine whether the C standard library is glibc
by testing whether __GLIBC_PREREQ is defined. This breaks if libc++
provides its own definition. Instead, define our own macro in our
namespace with the desired semantics.
Differential Revision: https://reviews.llvm.org/D41892
llvm-svn: 322201
Seems to have broken some tests since I first wrote this a while
back. Will reland after checking what went wrong with the tests.
This reverts commit 7023194c8d11a081fd01ed25308b3d60193c6a06.
llvm-svn: 322039
Summary:
After rL319736 for D28253 (which fixes PR28929), gcc cannot compile `<memory>` anymore in pre-C+11 modes, complaining:
```
In file included from /usr/include/c++/v1/memory:648:0,
from test.cpp:1:
/usr/include/c++/v1/memory: In static member function 'static std::__1::shared_ptr<_Tp> std::__1::shared_ptr<_Tp>::make_shared(_A0&, _A1&, _A2&)':
/usr/include/c++/v1/memory:4365:5: error: wrong number of template arguments (4, should be at least 1)
static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't construct object in make_shared" );
^
In file included from /usr/include/c++/v1/memory:649:0,
from test.cpp:1:
/usr/include/c++/v1/type_traits:3198:29: note: provided for 'template<class _Tp, class _A0, class _A1> struct std::__1::is_constructible'
struct _LIBCPP_TEMPLATE_VIS is_constructible
^~~~~~~~~~~~~~~~
In file included from /usr/include/c++/v1/memory:648:0,
from test.cpp:1:
/usr/include/c++/v1/memory:4365:5: error: template argument 1 is invalid
static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't construct object in make_shared" );
^
/usr/include/c++/v1/memory: In static member function 'static std::__1::shared_ptr<_Tp> std::__1::shared_ptr<_Tp>::allocate_shared(const _Alloc&, _A0&, _A1&, _A2&)':
/usr/include/c++/v1/memory:4444:5: error: wrong number of template arguments (4, should be at least 1)
static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't construct object in allocate_shared" );
^
In file included from /usr/include/c++/v1/memory:649:0,
from test.cpp:1:
/usr/include/c++/v1/type_traits:3198:29: note: provided for 'template<class _Tp, class _A0, class _A1> struct std::__1::is_constructible'
struct _LIBCPP_TEMPLATE_VIS is_constructible
^~~~~~~~~~~~~~~~
In file included from /usr/include/c++/v1/memory:648:0,
from test.cpp:1:
/usr/include/c++/v1/memory:4444:5: error: template argument 1 is invalid
static_assert((is_constructible<_Tp, _A0, _A1, _A2>::value), "Can't construct object in allocate_shared" );
^
```
This is also reported in https://bugs.freebsd.org/224946 (FreeBSD is apparently one of the very few projects that regularly builds programs against libc++ with gcc).
The reason is that the static assertions are invoking `is_constructible` with three arguments, while gcc does not have the built-in `is_constructible` feature, and the pre-C++11 `is_constructible` wrappers in `<type_traits>` only provide up to two arguments.
I have added additional wrappers for three arguments, modified the `is_constructible` entry point to take three arguments instead, and added a simple test to is_constructible.pass.cpp.
Reviewers: EricWF, mclow.lists
Reviewed By: EricWF
Subscribers: krytarowski, cfe-commits, emaste
Differential Revision: https://reviews.llvm.org/D41805
llvm-svn: 321963
This allows keeping libcxx using win32 threads even if a
version of pthread.h is installed.
This matches the existing cmake option LIBCXX_HAS_PTHREAD_API.
Also add missing documentation about the internal define
_LIBCPP_HAS_THREAD_API_WIN32.
Differential Revision: https://reviews.llvm.org/D41764
llvm-svn: 321896
As a result of this change, the basic_stringbuf constructor that
takes a mode ends up leaving __hm_ set to 0, causing the comparison
"__hm_ - __str_.data() < __noff" in seekoff() to succeed, which caused
the function to incorrectly return -1. The fix is to account for the
possibility of __hm_ being 0 when computing the distance from __hm_
to the start of the string.
Differential Revision: https://reviews.llvm.org/D41319
llvm-svn: 321124
It turns out that this is the only change required in libcxx
for it to compile with the new `wasm32-unknown-unknown-wasm`
target recently added to Clang.
Patch by Nicholas Wilson!
Differential Revision: https://reviews.llvm.org/D41073
llvm-svn: 320925
Summary:
[libcxx] Fix basic_stringbuf constructor
The C++ Standard [stringbuf.cons]p1 defines the effects of the basic_stringbuf
constructor that takes ios_base::openmode as follows:
Effects: Constructs an object of class basic_stringbuf, initializing the
base class with basic_streambuf(), and initializing mode with which.
Postconditions: str() == "".
The default constructor of basic_streambuf shall initialize all its
pointer member objects to null pointers [streambuf.cons]p1.
Currently libc++ calls "str(string_type());" in the aforementioned constructor
setting basic_streambuf's pointers to a non-null value.
This patch removes the call (note that the postcondition str() == ""
remains valid because __str_ is default-initialized) and adds a test checking
that the basic_streambuf's pointers are null after construction.
Thanks Mikhail Maltsev for the patch.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40707
llvm-svn: 320604
Summary:
Introduce a new form of `result_of` without function type encoding.
Rename and split `is_callable/is_nothrow_callable` into `is_invocable/is_nothrow_invocable/is_invocable_r/is_nothrow_invocable_r` (and associated types accordingly)
Change function type encoding of previous `is_callable/is_nothrow_callable` traits to conventional template type parameter lists.
Reviewers: EricWF, mclow.lists, bebuch
Reviewed By: EricWF, bebuch
Subscribers: lichray, bebuch, cfe-commits
Differential Revision: https://reviews.llvm.org/D38831
llvm-svn: 320509
Currently libc++ defines operator== and operator!= as friend functions in the
definition of the istream_iterator class template. Such definition has a subtle
difference from an out-of-line definition required by the C++ Standard: these
functions can only be found by argument-dependent lookup, but not by qualified
lookup.
This patch changes the definition, so that it conforms to the C++ Standard and
adds a check involving qualified lookup to the test suite.
Patch contributed by Mikhail Maltsev.
Differential Revision: https://reviews.llvm.org/D40415
llvm-svn: 320363
These buildbots are using the deprecated target name install-libcxx-headers
instead of the more up to date install-cxx-headers, so I need to add an
install-libcxx-headers-stripped target to satisfy them.
llvm-svn: 320201
LLVM is gaining install-*-stripped targets to perform stripped installs,
and in order for this to be useful for install-distribution, all
potential distribution components should have stripped installation
targets. LLVM has a function to create these install targets, but since
we can't use LLVM CMake functions in libc++, let's do it manually.
Differential Revision: https://reviews.llvm.org/D40680
llvm-svn: 319959
The MSVC driver and clang do not link against the C++ runtime
explicitly. Instead, they rely on the auto-linking via the pragma
(through `use_ansi.h`) to link against the correct version of the C++
runtime. Attempt to do something similar here so that linking real C++
code on Windows does not require the user to explicitly specify
`c++.lib` when using libc++ as a C++ runtime on windows.
llvm-svn: 319816
The parameter was previously renamed but MSVC path was not updated.
Patch by Andrey Khalyavin.
Differential Revision: https://reviews.llvm.org/D40774
llvm-svn: 319802
Use this source use on Fuchsia where this is the oficially way
to obtain randomness. This could be also used on other platforms
that already support getentropy such as *BSD or Linux.
Differential Revision: https://reviews.llvm.org/D40319
llvm-svn: 319523
Fix the problem PR31516 with setting locale on Windows by wrapping
_locale_t with a pointer-like class.
Reduces 74 test failures in std/localization test suite to 47 test
failures (on llvm clang, Visual Studio 2015). Number of test failures
doesn't depend on the platform (x86 or x64).
Patch by Andrey Khalyavin.
Differential Revision: https://reviews.llvm.org/D40181
llvm-svn: 318902
It covers the cases when the sentry object returns false and when an exception
was thrown. Corresponding standard paragraph is C++14 [istream.unformatted]p21:
In any case, if n is greater than zero, it then stores a null character
(using charT()) into the next successive location of the array.
Patch by Reimar Döffinger.
llvm-svn: 318862
One can't replace vsscanf(_l) with a sscanf(_l) that doesn't
take a va_list.
This has been untouched since it was added in SVN r140728, so
apparently it hasn't been used since. One reason for this mistake
originally might have been that there was no _vsscanf_l until MSVC
2015.
Since it's unused, just remove this define.
Differential Revision: https://reviews.llvm.org/D40323
llvm-svn: 318810
The non-const data() member of std::string is only exposed
in C++17 and beyond. However std::string is externally instantiated
and so the member function needs to be exposed to be externally instantiated.
On Linux and OS X this shouldn't cause a problem, because
_LIBCPP_INLINE_VISIBILITY ensures the symbol is always inlined.
However on Windows, the symbol gets marked dllimport, but
there is no definition to import, causing link errors.
llvm-svn: 318690
Summary:
Currently `std::variant` always uses an unsigned int to store the variant index. However this isn't nessesary and causes `std::variant` to be larger than it needs to be in most cases.
This patch changes the index type to be `unsigned char` when possible, and `unsigned short` or `unsigned int` otherwise, depending on the size (Although it's questionable if it's even possible to create a variant with 65535 elements.
Unfortunately this change is an ABI break, and as such is only enabled in ABI v2.
Reviewers: mpark
Reviewed By: mpark
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40210
llvm-svn: 318621
zoecarver