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
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
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
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
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
This patch removes the clear() member from <string_view>. The
modifier was removed from the TS before it ever landed in the standard.
There is no reason libc++ should be providing this method.
llvm-svn: 302869
Some MinGW configurations use WinPThread instead of the native
threading interfaces. When this happens libc++ doesn't build because
it tries to use the wrong threading API.
This patch attempts to correctly detect and enable pthreads; Selecting
them when __MINGW32__ is defined and __has_include(<pthread.h>) is true.
I'm not sure if this works correctly 100% of the time but it seemed
like the most correct approach available.
llvm-svn: 302734
This patch follows up on feedback received in the review for
D32988. Specifically that libc++ should not mess with the
__builtin namespace, and that libc++ should use __popcnt to implement
__pop_count under MSVC.
llvm-svn: 302731
Summary:
This patch refactors and tries to remove as much of the Windows support headers as possible. This is needed because they currently introduce super weird include cycles and dependencies between STL and libc headers.
The changes in this patch are:
* remove `support/win32/support.h` completely. The required parts have either been moved into `support/win32/msvc_support.h` (for `MSVC` only helpers not needed by Clang), or directly into their respective `foo.h` headers.
* Combine `locale_win32.h` and `locale_mgmt_win32.h` into a single headers, this header should only be included within `__locale` or `locale` to avoid include cycles.
* Remove the unneeded parts of `limits_win32.h` and re-name it to `limits_msvc_win32.h` since it's only needed by Clang.
I've tested this patch using Clang on Windows, but I suspect it might technically regress our non-existent support for MSVC. Is somebody able to double check?
This refactor is needed to support upcoming fixes to `<locale>` on Windows.
Reviewers: bcraig, rmaprath, compnerd, EricWF
Reviewed By: EricWF
Subscribers: majnemer, cfe-commits
Differential Revision: https://reviews.llvm.org/D32988
llvm-svn: 302727
Summary:
This patch fixes bugs.llvm.org/PR32979.
[util.smartptr.shared.const] says:
> In the constructor definitions below, enables shared_from_this with p, for a pointer p of type Y*, means
> that if Y has an unambiguous and accessible base class that is a specialization of enable_shared_from_-
> this.
This means that libc++ needs to respect the access specifier of the base class, and not attempt to construct
and enabled_shared_from_this base if it is private. However access specifiers don't affect overload resolution
so our current implementation will attempt to construct the private base.
This patch uses SFINAE to correctly detect if the shared_ptr input has an accessible enable_shared_from_this
base class.
Reviewers: mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33033
llvm-svn: 302709
This patch fixes the test failures and unexpected passes that occur
when testing against GCC 7. Specifically:
* don't mark __gcd as always inline because it's a recursive function. GCC diagnoses this.
* don't XFAIL the aligned allocation tests. GCC 7 supports them but not the -faligned-allocation option.
* Work around gcc.gnu.org/PR78489 in variants constructors.
llvm-svn: 302488
Previously <locale> used std::unique_ptr<remove_ptr<locale_t>, locale-mgmt-function>
as a scope guard for (A) creating new locales, and (B) setting the thread specific locale
in RAII safe manner.
However using unique_ptr has some problems, first it requires that locale_t is a pointer
type, which may not be the case (Windows will need a non-pointer locale_t type that emulates _locale_t).
The second problem is that users of the guards had to supply the locale management function to the custom
deleter at every call site. However these locale management functions don't exist natively Windows, making
a good Windows implementation of locale more difficult.
This patch creates distinct and simply RAII guards that replace unique_ptr. These guards handle calling
the correct locale management function so that callers don't have too. This simplification will
aid in upcoming Windows fixes.
llvm-svn: 302474
Summary:
This patch implements exception_ptr on Windows using the `__ExceptionPtrFoo` functions provided by MSVC.
The `__ExceptionPtrFoo` functions are defined inside the C++ standard library, `msvcprt`, which is unfortunate because it requires libc++ to link to the MSVC STL. However this doesn't seem to cause any immediate problems. However to be safe I kept all usages within the libc++ dylib so that user programs wouldn't have to link to MSVCPRT as well.
Note there are still 2 outstanding exception_ptr/nested_exception test failures.
* `current_exception.pass.cpp` needs to be rewritten for the Windows exception_ptr semantics which copy the exception every time.
* `rethrow_if_nested.pass.cpp` need investigation. It hits a stack overflow, likely from recursion.
This patch also gets most of the `<future>` tests passing as well.
Reviewers: mclow.lists, compnerd, bcraig, rmaprath, majnemer, BillyONeal, STL_MSFT
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D32927
llvm-svn: 302393
Summary:
In https://bugs.freebsd.org/207918, Daniel McRobb describes how using
std::showbase with ostreams can cause truncation of unsigned long long
when output format is octal. In fact, this can even happen with
unsigned int and unsigned long.
To ensure this does not happen, add one additional character to the
do_put buffers if std::showbase is on. Also add a test case.
Reviewers: EricWF, mclow.lists
Reviewed By: EricWF
Subscribers: cfe-commits, emaste
Differential Revision: https://reviews.llvm.org/D32670
llvm-svn: 302362
The ERROR_TIMEDOUT returned by the Windows API does not
have the same value as ETIMEDOUT. This caused condition_variable
to return timeouts as unknown errors.
llvm-svn: 302297
Libc++ is used as a system library on macOS and iOS (amongst others). In order
for users to be able to compile a binary that is intended to be deployed to an
older version of the platform, clang provides the
availability attribute <https://clang.llvm.org/docs/AttributeReference.html#availability>_
that can be placed on declarations to describe the lifecycle of a symbol in the
library.
See docs/DesignDocs/AvailabilityMarkup.rst for more information.
Differential Revision: https://reviews.llvm.org/D31739
llvm-svn: 302172
Summary: Seemed to have been overlooked in D24028.
This bug was found and brought to my attention by Paul Wankadia.
Reviewers: kubamracek, EricWF, dvyukov
Differential Revision: https://reviews.llvm.org/D32402
llvm-svn: 301132
For std::isinf, the standard requires effectively calling isinf as
double from Libc for integral types. But integral types are never
infinite; we don't need to call Libc to return false.
Also short-circuit other functions where Libc won't have interesting
answers: signbit, fpclassify, isfinite, isnan, and isnormal.
I added correctness tests for integral types since we're no longer
deferring to Libc.
In review it was pointed out that in future revisions of the C++
standard we may add more types to std::is_arithmetic (e.g.,
std::is_fixed_point). I'll leave it to a future commit to hack this to
allow using math functions on those. We'll need to change things like
__libcpp_fpclassify anyway, so I'm not sure anything here would really
be future-proof.
https://reviews.llvm.org/D31561
rdar://problem/31361223
llvm-svn: 301060
Previously the ATOMIC_<TYPE>_LOCK_FREE macros were implemented
using __GCC_ATOMIC_<TYPE>_LOCK_FREE but GCC specific macros
are defined when -fms-compatibility is specified.
To avoid this Libc++ now tries to use the newly added
__CLANG_ATOMIC_<TYPE>_LOCK_FREE macros instead, and only falls
back to the GCC versions when the Clang ones aren't available.
llvm-svn: 300920
This patch cleans up all usages of the following feature test macros inside
<vector> and its tests:
* _LIBCPP_HAS_NO_RVALUE_REFERENCES
* _LIBCPP_HAS_NO_VARIADICS
* _LIBCPP_HAS_NO_GENERALIZED_INITIALIZERS
Where needed the above guards were replaced with _LIBCPP_CXX03_LANG.
llvm-svn: 300410
This patch overhauls both specializations of unique_ptr while implementing
the following LWG issues:
* LWG 2801 - This issue constrains unique_ptr's constructors when the deleter type
is not default constructible. Additionally it adds SFINAE conditions
to unique_ptr<T[]>::unique_ptr(Up).
* LWG 2905 - This issue reworks the unique_ptr(pointer, /* see below */ deleter)
constructors so that they correctly SFINAE when the deleter argument cannot
be used to construct the stored deleter.
* LWG 2520 - This issue fixes initializing unique_ptr<T[]> from nullptr.
Libc++ had previously implemented this issue, but the suggested resolution
still broke initialization from NULL. This patch re-works the
unique_ptr<T[]>(Up, deleter) overloads so that they accept NULL as well
as nullptr.
llvm-svn: 300406
Fuchsia's libc was forked from musl, but has evolved sufficiently
since then so it no longer makes sense to pretend it's musl. This
change implements direct support for Fuchsia rather than
piggybacking on musl support.
Differential Revision: https://reviews.llvm.org/D31970
llvm-svn: 300261
When the libc++ extern template macros were added, the intent was for it
to be possible for consumers of the headers to disable extern templates
(via `-D_LIBCPP_EXTERN_TEMPLATE(...)=`). Unfortunately, support for
specifying function-like macros varies on the command line varies across
compilers (e.g. MSVC doesn't support it at all), and cmake doesn't allow
it for the same reason. Add a non-function macro for this purpose.
The intended use is for libraries which want to use the libc++ headers
without taking a dependency on the libc++ library itself. I can name the
macro something which reflects its intent rather than its behavior (e.g.
`_LIBCPP_HEADER_ONLY`) if desired.
Differential Revision: https://reviews.llvm.org/D31725
llvm-svn: 300246
path::iterator isn't a strictly conforming iterator. Specifically
it stashes the current element inside the iterator. This leads to
UB when used with reverse_iterator since it requires the element
to outlive the lifetime of the iterator.
This patch adds a static_assert inside reverse_iterator to disallow
"stashing iterator types", and it tags path::iterator as such a type.
Additionally this patch removes all uses of reverse_iterator<path::iterator>
within the tests.
llvm-svn: 300164
The __unordered_map_equal and __unordered_map_hash wrappers
attempt to swap const qualified predicates whenever the predicate
is empty, and is subject to the EBO.
Swapping const values seems blatently incorrect. This patch removes
the const qualifier so the values are swapped as non-const.
llvm-svn: 300154
r300140 introduced a bunch of failures by changing the internal
interface provided by __compressed_pair. This patch fixes all of
the failures caused by the new interface by changing the existing
code to use it.
In addition to those changes this patch also fixes two separate
issues causing test failures:
1) Fix the member swap definition for __map_value_compare. Previously
the swap was incorrectly configured to swap the comparator as const.
2) Fix an assertion failure in futures.task.members/ctor_func_alloc.pass.cpp
that incorrectly expected a move to take place when a single copy is sufficient.
There is one remaining failure regarding make_shared. I'll commit a fix for that
shortly.
llvm-svn: 300148
Summary:
__compressed_pair takes and passes it's constructor arguments by value. This causes arguments to be moved 3 times instead of once. This patch addresses that issue and fixes `constexpr` on the constructors.
I would rather have this fix than D27564, and I'm fairly confident it's not ABI breaking but I'm not 100% sure.
I prefer this solution because it removes a lot of code and makes the implementation *much* smaller.
Reviewers: mclow.lists, K-ballo
Reviewed By: K-ballo
Subscribers: K-ballo, cfe-commits
Differential Revision: https://reviews.llvm.org/D27565
llvm-svn: 300140
For reference deleter types the const qualifier on the return type
of get_deleter() should be ignored, and a non-const deleter should
be returned.
This patch fixes a bug where "const deleter_type&" is incorrectly
formed.
llvm-svn: 300121
The inline function definition ABI macro is gated on COFF dllexport
semantics, so it's more appropriate to mark it with the object file
format macro rather than the generic _WIN32 macro. We now have no uses
of _WIN32 apart from those used to define the other Windows macros :)
Clarify the ABI macro comment and make the object file format check
exhaustive while I'm here.
llvm-svn: 300097
LLVM dropped support for Visual Studio versions older than 2015 quite
some time ago, so I consider it safe to drop libc++'s support for older
CRTs. The CRT in Visual Studio 2015 provides a lot of previously missing
functions, so targeting it requires less special casing.
Differential Revision: https://reviews.llvm.org/D31798
llvm-svn: 299743
Method specializations don't get exported even if there's an exported
extern template instantiation on Windows. Explicitly mark the methods
for export. They're already exported on Linux and Darwin, so there's no
ABI change on those platforms.
llvm-svn: 299348
This is effectively a partial revert of r278356, which started inlining
basic_string::__init. Even if we want to help the compiler along with
an inlinehint, we shouldn't hamstring it by forcing it to inline all the
time.
Libc++ uses always_inline widely as a limit-the-ABI-hack, but since
__init is already on the dylib boundary, it makes no sense here and just
harms the debugging experience at -O0.
rdar://problem/31013102
llvm-svn: 299290
r145698 introduced _LIBCPP_HAS_NO_STRONG_ENUMS by copy-pasting the
__has_feature check from objc_arc_weak/_LIBCPP_HAS_OBJC_ARC_WEAK, and
accidentally started defining _LIBCPP_HAS_NO_STRONG_ENUMS whenever
__has_feature(objc_arc_weak). This is totally bogus, and means that
Libc++ thinks Objective-C++ compilations with -fobjc-arc don't have
strong enums.
Delete the accidental line.
I thought about adding a test, but it would be entirely duplicative of
the patch (if has-feature strong enums, check that has-no-strong-enums
is not defined).
llvm-svn: 299236
Summary:
bad_function_call is currently an empty class, so any object files using
that class will end up with their own copy of its typeinfo, typeinfo
name and vtable, leading to unnecessary duplication that has to be
resolved by the dynamic linker. Instead, give bad_function_call a key
function and put a definition for that key function in libc++ itself, to
centralize the typeinfo and vtable.
This is consistent with the behavior for other exception classes. The
key functions are defined in libc++ rather than libc++abi since the
class is defined in the libc++ versioning namespace, so ABI
compatibility with libstdc++ is not a concern.
Guard this change behind an ABI macro, since it isn't backwards
compatible (i.e., clients built against the new libc++ headers wouldn't
be able to run against an older libc++ library).
Reviewers: mclow.lists, EricWF
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D27387
llvm-svn: 298937
Summary:
By manipulating a local variable in the loop, when the loop can
be optimized away (due to no non-trivial destructors), this lets
it be fully optimized away and we modify the __end_ separately.
This results in a substantial improvement in the generated code.
Prior to this change, this would be generated (on x86_64):
movq (%rdi), %rdx
movq 8(%rdi), %rcx
cmpq %rdx, %rcx
je LBB2_2
leaq -12(%rcx), %rax
subq %rdx, %rax
movabsq $-6148914691236517205, %rdx ## imm = 0xAAAAAAAAAAAAAAAB
mulq %rdx
shrq $3, %rdx
notq %rdx
leaq (%rdx,%rdx,2), %rax
leaq (%rcx,%rax,4), %rax
movq %rax, 8(%rdi)
And after:
movq (%rdi), %rax
movq %rax, 8(%rdi)
This brings this in line with what other implementations do.
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25241
llvm-svn: 298601
basic_string::replace() has the below line
__sz += __n2 - __n1;
which fails overflow checks if __n1 > __n2, as the negative result
from the subtraction then overflows the original __sz when added to
it.
This behavior is valid as unsigned integer overflow is defined to wrap
around the maximum value and that produces the correct final value for
__sz. Therefore, we disable this check on this function.
llvm-svn: 297355
Put proper guards around _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS.
No functional change on non-Windows. Avoids incorrect macro redefinition
on Windows.
llvm-svn: 297330
r296565 attempted to add better diagnostics when an unordered container
is instantiated with a hash that doesn't meet the Hash requirements.
However I mistakenly checked the wrong set of requirements. Specifically
it checked if the hash met the requirements for specializations of
std::hash. However these requirements are stricter than the generic
Hash requirements.
This patch fixes the assertions to only check the Hash requirements.
llvm-svn: 296919
Summary:
Most classes annotated with _LIBCPP_TYPE_VIS need to have at least some
of their members exported, otherwise we have a lot of link errors when
linking against a libc++ built with hidden visibility. This also makes
_LIBCPP_TYPE_VIS be consistent across platforms, since on Windows it
already exports members.
With this change made, any template methods of a class marked
_LIBCPP_TYPE_VIS will also get default visibility when instantiatied,
which is not desirable for clients of libc++ headers who wish to control
their visibility; this is the same issue as PR30642. Annotate all
problematic methods with an explicit visibility specifier to avoid this.
The problematic methods were found by running bad-visibility-finder [1]
against the libc++ headers after making the _LIBCPP_TYPE_VIS change. The
small methods were marked for inlining; the larger ones hidden.
[1] https://github.com/smeenai/bad-visibility-finder
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25208
llvm-svn: 296732
When building libc++ with hidden visibility, we want explicit template
instantiations to export members. This is consistent with existing
Windows behavior, and is necessary for clients to be able to link
against a hidden visibility built libc++ without running into lots of
missing symbols.
An unfortunate side effect, however, is that any template methods of a
class with an explicit instantiation will get default visibility when
instantiated, unless the methods are explicitly marked inline or hidden
visibility. This is not desirable for clients of libc++ headers who wish
to control their visibility, and led to PR30642.
Annotate all problematic methods with an explicit visibility specifier
to avoid this. The problematic methods were found by running
https://github.com/smeenai/bad-visibility-finder against the libc++
headers after making the _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS change. The
methods were marked with the new _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS
macro, which was created for this purpose.
It should be noted that _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS was originally
intended to expand to default visibility, and was changed to expanding
to default type visibility to fix PR30642. The visibility macro
documentation was not updated accordingly, however, so this change makes
the macro consistent with its documentation again, while explicitly
fixing the methods which resulted in that PR.
Differential Revision: https://reviews.llvm.org/D29157
llvm-svn: 296731
D29157 will make explicit template instantiations expand to default
visibility, at which point these method templates will need to be
explicitly marked hidden visibility to avoid leaking into other DSOs.
Unfortunately, because of clang PR32114, they must be marked inline (in
conjunction with `-fvisibility-inlines-hidden`) to actually hide them,
since clang doesn't respect the hidden visibility annotation.
Since this involves an ABI change, mark these methods inline in a
separate change, so that the ABI changes can be reviewed separately and
verified to be safe.
Differential Revision: https://reviews.llvm.org/D30523
llvm-svn: 296729
This patch adds a static assertion that the specified hash meets
the requirements of an enabled hash, and it ensures that the static
assertion is evaluated before __compressed_pair is instantiated.
That way the static assertion diagnostic is emitted first.
llvm-svn: 296565
This patch fixes llvm.org/PR32097 by using the __is_abstract
builtin type-trait instead of the previous library-only implementation.
All supported compilers provide this trait. I've tested as far
back as Clang 3.2, GCC 4.6 and MSVC trunk.
llvm-svn: 296561
This reverts SVN r295329. Although `__libcpp_thread_sleep_for` should
be alertable, the implementation causes a large regression in the test
suite. Add a FIXME item there for now to get the test suite in a better
state before attempting to fix that behaviour.
llvm-svn: 295561
When building with MSVCRT, we need to manually provide the type
promoting overloads to allow the correct type deduced invocation for
signbit(Int) and fpclassify(int).
llvm-svn: 295559
GCC 7.0.1 started warning that __attribute__((__strong__)) is depricated.
This patch switches to using inline namespace with GCC instead. I believe
this wasn't done originally in order to support older GCC versions w/o
support for inline namespaces, or because earlier versions of GCC warned
users that the STL was using an inline namespace (even though it shouldn't affect users).
However I believe all of the above problems are gone for GCC 4.9 and greater.
Therefore switching to using inline namespaces instead of using __strong__
is the most correct behavior.
llvm-svn: 295428
Summary:
This patch implements [P0003R5](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0003r5.html) which removes exception specifications from C++17.
The only changes to the library are removing `set_unexpected`, `get_unexpected`, `unexpected`, and `unexpected_handler`. These functions can be re-enabled in C++17 using `_LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS`.
@mclow.lists what do you think about removing stuff is this way?
Reviewers: mclow.lists
Reviewed By: mclow.lists
Subscribers: mclow.lists, cfe-commits
Differential Revision: https://reviews.llvm.org/D28172
llvm-svn: 295406
Summary:
This patch fixes http://llvm.org/PR31938. The description below is copy/pasted from the bug:
The standard says:
template<class charT, class traits = char_traits<charT>,
class Allocator = allocator<charT>>
class basic_string {
using value_type = typename traits::char_type;
// ...
basic_string(const charT* s, const Allocator& a = Allocator());
};
libc++ actually chooses to declare the constructor as
basic_string(const value_type* s, const Allocator& a = Allocator());
The implicit deduction guides from class template argument deduction make what was previously an implementation detail visible:
std::basic_string s = "foo"; // error, can't deduce charT.
The constructor in question is in the libc++ DSO, but fortunately it looks like fixing this will not result in an ABI break.
@rsmith How does this look? I did more than just the constructors mentioned in the PR, but IDK how far to take it.
Reviewers: mclow.lists, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits, rsmith
Differential Revision: https://reviews.llvm.org/D29863
llvm-svn: 295393
On Windows, we were using `Sleep` which is not alertable. This means
that if the thread was used for a user APC or WinProc handling and
thread::sleep was used, we could potentially dead lock. Use `SleepEx`
with an alertable sleep, resuming until the time has expired if we are
awoken early.
llvm-svn: 295329
clang cannot properly handle __declspec and __attribute__ on classes
right now. This prevents the shared_mutex tests from working. Disable
the use of the annotation on COFF targets.
llvm-svn: 294958
Pull in the math functions from ucrt 14+ after auditing the library. It
seems that they are now complete for C99 math. Fixes more windows
tests!
llvm-svn: 294918
The newer versions of ucrt have the math routines. Use the CRT version
to determine if we should include the math routines. Fixes two tests
for Windows.
llvm-svn: 294899
This recommits r294707 with additional fixes. The main difference is
libc++ now correctly builds without any ABI library.
exception.cpp is a bloody mess. It's full of confusing #ifdef branches for
each different ABI library we support, and it's getting unmaintainable.
This patch breaks down exception.cpp into multiple different header files,
roughly one per implementation. Additionally it moves the definitions of
exceptions in new.cpp into the correct implementation header.
This patch also removes an unmaintained libc++abi configuration.
This configuration may still be used by Apple internally but there
are no other possible users. If it turns out that Apple still uses
this configuration internally I will re-add it in a later commit.
See http://llvm.org/PR31904.
llvm-svn: 294730
exception.cpp is a bloody mess. It's full of confusing #ifdef branches for
each different ABI library we support, and it's getting unmaintainable.
This patch breaks down exception.cpp into multiple different header files,
roughly one per implementation. Additionally it moves the definitions of
exceptions in new.cpp into the correct implementation header.
This patch also removes an unmaintained libc++abi configuration.
This configuration may still be used by Apple internally but there
are no other possible users. If it turns out that Apple still uses
this configuration internally I will re-add it in a later commit.
See http://llvm.org/PR31904.
llvm-svn: 294707
Summary:
Libcxx will define its own max_align_t when it is not available. However, the
availability checks today only check for Clang's definition and GCC's
definition. In particular, it does not check for musl's definition, which is the
same as GCC's but guarded with a different macro.
Reviewers: mclow.lists, EricWF
Reviewed By: EricWF
Subscribers: chandlerc, cfe-commits
Differential Revision: https://reviews.llvm.org/D28478
llvm-svn: 294683
A static assertion was misfiring since it checked
is_callable<Visitor, decltype(__variant_alt<T>.value)>. However
the decltype expression doesn't capture the value category as
required. This patch applies extra braces to decltype to fix
that.
llvm-svn: 294612
Different platforms implement the wait/sleep functions in difrerent ways.
It makes sense to externalize this into the threading API.
Differential revision: https://reviews.llvm.org/D29630
Reviewers: EricWF, joerg
llvm-svn: 294573
In addition to the PR for LWG 2773 this patch also ensures
that each of std::ignores constructors or assignment operators
are constexpr.
llvm-svn: 294165
It is my opinion that libc++ should never use `<cassert>`, including in the `dylib`.
This patch remove all uses of `assert` from within libc++ and replaces most of them with `_LIBCPP_ASSERT` instead.
Additionally this patch turn `LIBCXX_ENABLE_ASSERTIONS` off by default,
because the standard library should not be aborting user programs unless explicitly asked to.
llvm-svn: 294107
Visible definitions for basic_string::assign are sometimes emitted in
the dylib depending on the version of LLVM used to compile libc++.
This can cause the check-cxx-abilist target to fail.
This patch attempts marks the basic_string::assign templates as inline
to prevent this. That way the export list is consistent across LLVM
versions.
llvm-svn: 294100
While this change didn't really hurt, it does lead to spurious
warnings about not being able to override weak symbols if you end up
linking objects built with this change to ones built without it.
Furthermore, since __call_once_proxy is called indirectly anyway it
doesn't actually inline ever.
Longer term, it would probably make sense to give this symbol internal
visibility instead.
This reverts r291497
llvm-svn: 293581
These member functions were decorated with `_LIBCPP_FUNC_VIS` when the
class is also decorated with external visibility. This breaks down when
building for PE/COFF, where the member function cannot be decorated if
it is within a decorated class. The class attribute will propagate to
the member. Remove the extraneous decoration.
llvm-svn: 293454
Microsoft's SAL has a `__deref` macro which results in a compilation
failure when building the filesystem module on Windows. Rename the
member function internally to avoid the conflict.
llvm-svn: 293449
This causes unnecessary warnings when building with `cl`. Newer
versions of the C standard permit the redefinition of the macro to the
same value (which is the case here), unfortunately, `cl` does not yet
implement this. Add a check to prevent the redefinition.
llvm-svn: 293439
Many thread-related libc++ test cases fail on FreeBSD, due to the
following -Werror warnings:
In file included from test/std/thread/thread.threads/thread.thread.this/sleep_until.pass.cpp:17:
In file included from include/thread:97:
In file included from include/__mutex_base:17:
include/__threading_support:222:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:221:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:231:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:242:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:241:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:251:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:272:10: error: calling function 'pthread_cond_wait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_wait(__cv, __m);
^
include/__threading_support:278:10: error: calling function 'pthread_cond_timedwait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_timedwait(__cv, __m, __ts);
^
6 errors generated.
This is because on FreeBSD, the pthread functions have lock annotations.
Since the functions in __thread_support are internal to libc++ only, add
no_thread_safety_analysis attributes to suppress these warnings.
Reviewers: mclow.lists, EricWF, delesley, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: ed, aaron.ballman, joerg, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D28520
llvm-svn: 293197
This reverts commit r292883. Unfortunately <string_view> uses
_LIBCPP_ASSERT in a way which is not compatible with the C++11 dylib
build. I'll investigate more tomorrow.
llvm-svn: 292923
Summary:
It is my opinion that libc++ should never use `<cassert>`, including in the `dylib`. This patch remove all uses of `assert` from within libc++ and replaces most of them with `_LIBCPP_ASSERT` instead.
Additionally this patch turn `LIBCXX_ENABLE_ASSERTIONS` off by default, because the standard library should not be aborting user programs unless explicitly asked to.
Reviewers: mclow.lists, compnerd, smeenai
Reviewed By: mclow.lists
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D29063
llvm-svn: 292883
<string> uses `decltype` in a way incompatible with `__typeof__`.
This is problematic when compiling <string> with Clang 3.4 because
even though it provides `__decltype` libc++ still used `__typeof__`
because clang 3.4 doesn't provide __is_identifier which libc++
uses to detect __decltype.
This patch manually detects Clang 3.4 and properly configures
for it.
llvm-svn: 292833
Eric Fiselier