| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Wrap __sync_* builtins with __libcpp_ functions to facility future customizations as atomic operations are unavailable on some targets.
Reviewers: danalbert, EricWF, jroelofs
Subscribers: joerg, llvm-commits
Differential Revision: https://reviews.llvm.org/D34918
llvm-svn: 307591
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D32385
llvm-svn: 307505
|
|
|
|
|
|
|
|
|
|
|
| |
r283051 added some functions to cmath (in namespace std) that have the
same name as functions in math.h (in the global namespace). Clang's
limited support for `-fdelayed-template-parsing` chokes on this. Rename
the ones in `cmath` and their uses in `complex` and the test.
rdar://problem/32848355
llvm-svn: 307357
|
|
|
|
|
|
| |
forever. Reported as http://llvm.org/PR33681. Thanks to Karen Arutyunov for the report.
llvm-svn: 307171
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r306310.
r306310 causes clang to reject a call to an aligned allocation or
deallocation function if it is not implemented in the standard library
of the deployment target. This is not the desired behavior when users
have defined their own aligned functions.
rdar://problem/32664169
llvm-svn: 306859
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The string literal operators have implicit instantiations of
basic_string<char> and basic_string<wchar>, which prevent the dllimport
on the subsequent explicit instantiation declarations from having an
effect. Hoisting the explicit instantiations above the implicit ones
fixes the issue.
I think it's pretty unfortunate that the ordering has such an effect,
and I'd fixed the same issue for dllexport in r288682. dllimport is more
complicated from a codegen perspective, however, and clang's behavior of
ignoring the dllimport when there's a previous implicit instantiation is
consistent with cl, so changing the order is our only recourse.
llvm-svn: 306632
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
attribute.
This is needed because older versions of libc++ do not have these
operators. If users target an older deployment target and try to compile
programs in which these operators are explicitly called, the compiler
will complain.
The following is the list of minimum deployment targets for the four
OSes:
macosx: 10.13
ios: 11.0
tvos: 11.0
watchos: 4.0
rdar://problem/32664169
Differential Revision: https://reviews.llvm.org/D34556
llvm-svn: 306310
|
|
|
|
| |
llvm-svn: 306083
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remarks: This function shall not participate in overload resolution unless
`is_same_v<decay_t<T>, variant>` is false, unless `decay_t<T>` is
neither a specialization of `in_place_type_t` nor a specialization of
`in_place_index_t`, unless `is_constructible_v<Tj, T>` is true, and
unless the expression `FUN(std::forward<T>(t))` (with `FUN` being the
above-mentioned set of imaginary functions) is well formed.
Depends on D34111.
Reviewers: EricWF, K-ballo
Reviewed By: EricWF
Subscribers: fhahn
Differential Revision: https://reviews.llvm.org/D34112
llvm-svn: 305668
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix an off-by-one in r302172, which triggered building local versions of
the iostreams when deploying to `<= macOS 10.9`, when it should have
been `< macOS 10.9`. 10.9 had the dylib support.
This defines `_LIBCPP_AVAILABILITY_NO_STREAMS_EXTERN_TEMPLATE` less
often, reducing code size for users with deployment targets of exactly
macOS 10.9 or iOS 7.0.
rdar://problem/32233981
llvm-svn: 305649
|
|
|
|
|
|
|
|
| |
As a follow up to r302172, add missing availability for bad_any_cast.
rdar://problem/32161524
llvm-svn: 305647
|
|
|
|
|
|
|
|
|
|
| |
C99 at least. C89 still fails due to the use of block comments.
NOTE: Having libc++ on the include path when compiling C is not
recommended or ever really supported. However it happens often
enough that this change is warrented.
llvm-svn: 305539
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the promise_type
It seems conceivable that a user would need to get a coroutine handle
having only a const reference to the promise_type, for example from
within a const member function of the promise.
This patch allows that use case. A coroutine_handle<const T> can be used
in essentially the same way a coroutine_handle<T>, ie to start and destroy
the coroutine. The constness of the promise doesn't/shouldn't propagate
to the handle.
llvm-svn: 305536
|
|
|
|
|
|
| |
https://bugs.llvm.org/show_bug.cgi?id=33370
llvm-svn: 305469
|
|
|
|
| |
llvm-svn: 305451
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The function num_get<_CharT>::stage2_int_prep makes unnecessary copy of src
into atoms when char_type is char. This can be avoided by creating
a switch on type and just returning __src when char_type is char.
Added the test case to demonstrate performance improvement.
In order to avoid ABI incompatibilities, the changes are guarded
with a macro _LIBCPP_ABI_OPTIMIZED_LOCALE_NUM_GET
Differential Revision: https://reviews.llvm.org/D30268
Reviewed by: EricWF
llvm-svn: 305427
|
|
|
|
| |
llvm-svn: 305417
|
|
|
|
|
|
| |
constness. No functional change, but now they're explicit
llvm-svn: 305410
|
|
|
|
|
|
| |
casting a 'const T*' to a 'void *' - implicitly casting away the const. Add const_cast to make that explicit. No functional change.
llvm-svn: 305397
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Newlib 2.5 added the locale management functions, so it should not
include __nop_local_mgmt.h. This change adds proper guard around that
include statement.
For newlib 2.4, some releases contain these functions and some don't,
and they all have the same version numbers. This patch will work
properly with the initial "2.4.0" release which does not include these
functions and require __nop_local_mgmt.h.
This has been tested against newlib 2.2 and 2.5, and also sanity
checks against other different version numbers.
Patch by Martin J. O'Riordan and Walter Lee
Differential Revision: https://reviews.llvm.org/D32146
llvm-svn: 305394
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This is used to constrain `variant`'s converting constructor correctly.
Reviewers: EricWF, mclow.lists
Reviewed By: EricWF, mclow.lists
Differential Revision: https://reviews.llvm.org/D34111
llvm-svn: 305370
|
|
|
|
| |
llvm-svn: 305365
|
|
|
|
| |
llvm-svn: 305292
|
|
|
|
|
|
| |
add a message to variant_alternative<> in the similar case (it already asserted). Add tests for this
llvm-svn: 305196
|
|
|
|
|
|
| |
ill-formed if N >= M. We didn't do that. Add a static_assert to cause a failure, and a test that checks that we failed
llvm-svn: 305191
|
|
|
|
|
|
| |
transform_exclusive_scan. Reviewed as https://reviews.llvm.org/D34038.
llvm-svn: 305136
|
|
|
|
| |
llvm-svn: 304967
|
|
|
|
|
|
|
|
| |
Richard decided to fix these cases in Clang, even though they are
representative of a larger problem for more complex
cases.
llvm-svn: 304966
|
|
|
|
|
|
|
|
|
| |
r304862 changed how CTD handles deducing a non-primary class template
using a non-dependent constructor of the primary template. This change
requires libc++ to provide explicit deduction guides to make scoped_lock
work again.
llvm-svn: 304955
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Bionic PTHREAD_MUTEX_INITIALIZER contains the expression "<enum-type> & <integer-type>",
which causes ADL to perform name lookup for operator&. During this lookup Clang decides
that it requires the default member initializer for std::mutex while defining the DMI
for std::mutex::__m_.
If I'm not mistaken this is caused by the explicit noexcept declaration on the defaulted
constructor.
This patch removes the explicit noexcept and instead allows the compiler to declare
the default constructor implicitly noexcept. It also adds a static_assert to ensure
that happens.
Unfortunatly because it's not easy to change the value of _LIBCPP_MUTEX_INITIALIZER
for a single test there is no good way to test this patch.
The Clang behavior causing the trouble here was introduced in r287713, which first
appears in the 4.0 release.
llvm-svn: 304942
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Removed the move-constructibe requirement from copy-assignable.
- Updated `__assign_alt` such that we direct initialize if
`_Tp` can be `nothrow`-constructible from `_Arg`, or `_Tp`'s
move construction can throw. Otherwise, construct a temporary and move it.
- Updated the tests to remove the pre-LWG2904 path.
Depends on D32671.
Reviewers: EricWF, CaseyCarter
Reviewed By: EricWF
Differential Revision: https://reviews.llvm.org/D33965
llvm-svn: 304891
|
|
|
|
|
|
|
|
| |
[Credit to cpplearner]
Differential Revision: https://reviews.llvm.org/D27850
llvm-svn: 304813
|
|
|
|
|
|
| |
and the patch. Reviewed as https://reviews.llvm.org/D33588.
llvm-svn: 304617
|
|
|
|
| |
llvm-svn: 304383
|
|
|
|
| |
llvm-svn: 304382
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patch corrects the build errors I encountered when building on MinGW64.
Reviewers: mati865, rnk, compnerd, smeenai, bcraig
Reviewed By: mati865, smeenai
Subscribers: martell, chapuni, cfe-commits
Differential Revision: https://reviews.llvm.org/D33082
llvm-svn: 304360
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch improves how libc++ handles min/max macros within the headers. Previously libc++ would undef them and emit a warning.
This patch changes libc++ to use `#pragma push_macro` to save the macro before undefining it, and `#pragma pop_macro` to restore the macros and the end of the header.
Reviewers: mclow.lists, bcraig, compnerd, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits, krytarowski
Differential Revision: https://reviews.llvm.org/D33080
llvm-svn: 304357
|
|
|
|
| |
llvm-svn: 304348
|
|
|
|
| |
llvm-svn: 304180
|
|
|
|
| |
llvm-svn: 304173
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
everything but void*.
from_address requires that the provided pointer refer to the suspended coroutine,
which doesn't have a type, or at least not one knowable by the user. Therefore
every use of `from_address` with a typed pointer is almost certainly a bug.
This behavior is a part of the TS specification, but hopefully it will be
in the future.
llvm-svn: 304172
|
|
|
|
|
|
|
|
| |
More tests to come. I think that from_address overload should be deleted
or ill-formed, except for the 'void*' one; The user cannot possibly
have a typed pointer to the coroutine state.
llvm-svn: 304131
|
|
|
|
| |
llvm-svn: 304124
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang supports coroutines in all dialects; Therefore libc++ should too,
otherwise the Clang extension is unusable.
I'm not convinced extending support to C++03 is a feasible long term
plan, since as the library grows to offer things like generators it
will be come increasingly difficult to limit the implementation to C++03.
However for the time being supporting C++03 isn't a big deal.
llvm-svn: 303963
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang started providing -fcoroutines and defining __cpp_coroutines
way before it implemented the __builtin_coro_foo functions. This
means that simply checking if __cpp_coroutines is not a sufficient
way of detecting the actual feature.
This patch implements _LIBCPP_HAS_NO_COROUTINES which implements
a slightly more complex feature check. Specifically it requires
__cpp_coroutines >= 201703L, which only holds for Clang 5.0 built
after 2017/05/24.
llvm-svn: 303956
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original issues were caused because <experimental/coroutine>
didn't correctly #ifdef out enough of the header, which caused incomplete
types to be used.
This patch fixes the `#if defined(__cpp_coroutines)` guard and re-adds
the headers to the module map.
It also uglifies some incorrectly non-reserved names.
llvm-svn: 303936
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D33388
llvm-svn: 303928
|
|
|
|
|
|
|
| |
Thanks to Casey Carter for pointing out the out-of-date tests and
implementation.
llvm-svn: 303900
|
|
|
|
|
|
|
|
|
|
|
| |
This patch updates the promise() member to match the current spec.
Specifically it removes the non-const overload and make the return
type of the const overload non-const.
This patch also makes the ASSERT_NOT_NOEXCEPT tests libc++ specific,
since other implementations may be free to strengthen the specification.
llvm-svn: 303895
|
|
|
|
|
|
|
|
| |
Fixes PR27566.
Differential revision: https://reviews.llvm.org/D30837
llvm-svn: 303874
|