Once upon a time, extern templates used to be a Microsoft extension, so
cl would warn about their usage, and libc++ suppressed that warning.
They've long since been standardized, so the warning is defunct. (libc++
also doesn't currently support building with cl anyway.)
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@307997 91177308-0d34-0410-b5e6-96231b3b80d8
It has an extern template instantiation declaration in the headers and a
corresponding instantiation definition in the library, so we must mark
it with _LIBCPP_FUNC_VIS to make it available outside the library.
This doesn't cause any ABI changes as-is since we don't build libc++
with hidden visibility (so the function is exported anyway). It's needed
for building libc++ with hidden visibility, however.
Clarify the Windows behavior for extern function templates while I'm
here, since this exercises that behavior.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@307966 91177308-0d34-0410-b5e6-96231b3b80d8
When using LIBCXX_ABI_UNSTABLE=YES, clang-cl gave the following warning:
P:\llvm_master\src\llvm\projects\libcxx\include\string(683,51):
warning: enumerator value is not representable in the underlying type
'int' [-Wmicrosoft-enum-value]
Fixed by switching from enums to static const size_type.
https://reviews.llvm.org/D35174
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@307751 91177308-0d34-0410-b5e6-96231b3b80d8
The libc++ <__refstring> headers has no real reason why it should
be a public header that libc++ ships. The only reason it was in the include
directory was because libc++abi needed it to build the library.
However keeping <__refstring> a header had other problems, like requiring its
dependancies to also be in the headers. For that reason this patch
moves it into the source directory.
To work around libc++abi's need for this header a duplicated copy was added
to libc++abi in r307748. While duplicating the code is an unfortunate solution
it's the best solution that's currently possible.
In the future I would like to start a discussion on the mailing lists about
making libc++abi build as a sub-project of libc++, requiring the libc++ sources
always be present.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@307749 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@307357 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@306859 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@306632 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@306310 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@305668 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@305649 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@305539 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@305536 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@305427 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@305394 91177308-0d34-0410-b5e6-96231b3b80d8
Richard decided to fix these cases in Clang, even though they are
representative of a larger problem for more complex
cases.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@304966 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@304955 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@304942 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@304891 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@304357 91177308-0d34-0410-b5e6-96231b3b80d8
