Summary:
This patch fixes a number of problems with the visibility macros across GCC (on Unix) and Windows (DLL import/export semantics). All of the visibility macros are now documented under `DesignDocs/VisibilityMacros.rst`. Now I'll no longer forget the subtleties of each!
This patch adds two new visibility macros:
* `_LIBCPP_ENUM_VIS` for controlling the typeinfo of enum types. Only Clang supports this.
* `_LIBCPP_EXTERN_TEMPLATE_TYPE_VIS` for redefining visibility on explicit instantiation declarations. Clang and Windows require this.
After applying this patch GCC only emits one -Wattribute warning opposed to 30+.
Reviewers: mclow.lists, EricWF
Subscribers: beanz, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D24602
llvm-svn: 281673
When `_LIBCPP_NO_EXCEPTIONS` is defined, we end up with compile errors
when targeting MSVCRT:
* Code includes `<new>`
* `<new>` includes `<cstdlib>` in order to get `abort`
* `<cstdlib>` includes `<stdlib.h>`, _before_ the `using ::abort`
* `<stdlib.h>` includes `locale_win32.h`
* `locale_win32.h` includes `<memory>`
* `<memory>` includes `<stdexcept>`
* `<stdexcept>` includes `<cstdlib` for `abort`, but that inclusion gets
(correctly) ignored because of header guards
* `<stdexcept>` references `_VSTD::abort`, which isn't declared
The easiest solution is to make `locale_win32.h` not include `<memory>`,
by removing the use of `unique_ptr` and manually restoring the locale
instead.
Differential Revision: https://reviews.llvm.org/D24374
llvm-svn: 281641
This patch causes a couple of issues:
1) It triggers http://llvm.org/PR30341. Although the bug is not truly a libc++
bug it breaks the LLVM build using libc++. Reverting this patch is only
a temporary workaround until Clang is fixed.
2) It adds yet another ABI incompatibility when libc++.so is compiled with GCC.
Specifically GCC doesn't ignore the _LIBCPP_INLINE_VISIBILITY on the out-of-line
definition when compiling the dylib. This causes the externally instantiated
~basic_string symbol to have hidden visibility.
This patch should be recommitted after addressing (1) and (2). (2) can be fixed
by adding _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY which is defined as
__attribute__((visibility("default"), always_inline)) as opposed to
_LIBCPP_INLINE_VISIBILITY which makes the symbol hidden.
llvm-svn: 281562
An enum class has associated type info. In the Microsoft ABI, type info
is emitted in the COMDAT section and isn't exported, so clang rightfully
complains about __declspec(dllexport) being unused for an enum class.
On other platforms, we still want to export the type info.
Differential Revision: https://reviews.llvm.org/D24065
llvm-svn: 281264
This patch further decouples libc++ from pthread, allowing libc++ to be built
against other threading systems. There are two main use cases:
- Building libc++ against a thread library other than pthreads.
- Building libc++ with an "external" thread API, allowing a separate library to
provide the implementation of that API.
The two use cases are quite similar, the second one being sligtly more
de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API
enables both kinds of builds. One needs to place an <__external_threading>
header file containing an implementation of the "libc++ thread API" declared
in the <__threading_support> header.
For the second use case, the implementation of the libc++ thread API can
delegate to a custom "external" thread API where the implementation of this
external API is provided in a seperate library. This mechanism allows toolchain
vendors to distribute a build of libc++ with a custom thread-porting-layer API
(which is the "external" API above), platform vendors (recipients of the
toolchain/libc++) are then required to provide their implementation of this API
to be linked with (end-user) C++ programs.
Note that the second use case still requires establishing the basic types that
get passed between the external thread library and the libc++ library
(e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources
won't compile otherwise). It should also be noted that the second use case can
have a slight performance penalty; as all the thread constructs need to cross a
library boundary through an additional function call.
When the header <__external_threading> is omitted, libc++ is built with the
"libc++ thread API" (declared in <__threading_support>) as the "external" thread
API (basic types are pthread based). An implementation (pthread based) of this
API is provided in test/support/external_threads.cpp, which is built into a
separate DSO and linked in when running the libc++ test suite. A test run
therefore demonstrates the second use case (less the intermediate custom API).
Differential revision: https://reviews.llvm.org/D21968
Reviewers: bcraig, compnerd, EricWF, mclow.lists
llvm-svn: 281179
Visual Studio 2013 (CRT version 12) added support for many C99 long long and
long double functions. Visual Studio 2015 (CRT version 14) increased C99 and C11
compliance further. Since we don't support Visual Studio versions older than
2013, we can considerably clean up the support header.
Patch by Shoaib Meenai!
llvm-svn: 280988
Author: laxmansole
Reviewers: howard.hinnant
mclow.lists
Subscribers: EricWF, flyingforyou, evandro
Differential Revision: https://reviews.llvm.org/D22834
Currently basic_string's destructor is not getting inlined. So adding 'inline' attribute to ~basic_string().
Worked in collaboration with Aditya Kumar.
llvm-svn: 280944
This patch fixes PR30260 by using a (void*) cast on the placement argument
to placement new to casts away the const. See also http://llvm.org/PR30260.
As a drive by change this patch also changes the header guard for
<experimental/optional> to _LIBCPP_EXPERIMENTAL_OPTIONAL from _LIBCPP_OPTIONAL.
llvm-svn: 280775
This patch removes the `<cstdlib>` include from exception where it is no longer
needed. Unlike my previous attempt this patch also adds <cstdlib> where needed
in other headers like <new> and <typeinfo>.
This won't fix the Firefox build issues discussed on IRC but it is more correct
for libc++.
llvm-svn: 280754
Apparently I missed a number of additional include which need to be added.
Reverting so I can recommit as a single patch with all of the required includes.
llvm-svn: 280752
call_once is using relaxed atomic load to perform double-checked locking, which contains a data race. The fast-path load has to be an acquire atomic load.
Differential Revision: https://reviews.llvm.org/D24028
llvm-svn: 280621
Summary:
This patch allows threads not created using `std::thread` to use `std::notify_all_at_thread_exit` by ensuring the TL state has been initialized within `std::notify_all_at_thread_exit`.
Additionally this patch "fixes" a potential oddity in `__thread_local_pointer::reset(pointer)`, which would previously delete the old thread local data. However there should *never* be old thread local data because pthread *should* null it out on thread exit. Unfortunately it's possible that pthread failed to do this according to the spec:
>
> Upon key creation, the value NULL shall be associated with the new key in all active threads. Upon thread creation, the value NULL shall be associated with all defined keys in the new thread.
>
> An optional destructor function may be associated with each key value. At thread exit, if a key value has a non-NULL destructor pointer, and the thread has a non-NULL value associated with that key, the value of the key is set to NULL, and then the function pointed to is called with the previously associated value as its sole argument. The order of destructor calls is unspecified if more than one destructor exists for a thread when it exits.
>
> If, after all the destructors have been called for all non-NULL values with associated destructors, there are still some non-NULL values with associated destructors, then the process is repeated. If, after at least {PTHREAD_DESTRUCTOR_ITERATIONS} iterations of destructor calls for outstanding non-NULL values, there are still some non-NULL values with associated destructors, implementations may stop calling destructors, or they may continue calling destructors until no non-NULL values with associated destructors exist, even though this might result in an infinite loop.
However if pthread fails to delete the value it is probably incorrect for us to do it. Destroying the value performs all of the "at thread exit" actions registered with it but we are way past "at thread exit".
Reviewers: mclow.lists, bcraig, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24159
llvm-svn: 280588
When <bitset> is compiled with warnings enabled, on a platform where
size_t is 4 bytes, it results in errors similar to:
bitset:265:16: error: non-constant-expression cannot be narrowed
from type 'unsigned long long' to '__storage_type' (aka 'unsigned
int') in initializer list [-Wc++11-narrowing]
: __first_{__v, __v >> __bits_per_word}
^~~
bitset:676:52: note: in instantiation of member function
'std::__1::__bitset<2, 53>::__bitset' requested here
bitset(unsigned long long __v) _NOEXCEPT : base(__v) {}
^
Fix these by casting the initializer list elements to __storage_type.
Reviewers: mclow.lists, EricWF
Differential Revision: https://reviews.llvm.org/D23960
llvm-svn: 280543
Microsoft removed gets from the CRT in Visual Studio 2015 onwards [1].
Attempting to reference it when targeting CRT versions 14 and above will cause
compile errors.
[1] https://msdn.microsoft.com/en-us/library/2029ea5f.aspx
Patch by Shoaib Meenai!
llvm-svn: 280417
In r280108 I tried to make the headers copy relative to LLVM_BINARY_DIR, and the intent was that it would only happen on in-tree builds or runtimes directory builds. It didn't actually work that way.
This patch adds a check for CMAKE_SOURCE_DIR being equal to CMAKE_CURRENT_SOURCE_DIR. In this case we set a variable LIBCXX_USING_INSTLLED_LLVM. This doesn't necessarily mean the LLVM is installed (it could be a build directory), but it means we need to treat the LLVM directory as read-only.
llvm-svn: 280400
Summary: This copy phase is only needed for in-tree builds, so we should be copying to the LLVM build directory's include dir instead of the sub-project include dir.
Reviewers: bogner, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24015
llvm-svn: 280108
Summary:
Currently a number of GCC warnings are emitted when building libc++. This patch fixes or ignores all of them. The primary changes are:
* Work around strict aliasing issues in `typeinfo::hash_code()` by using __attribute__((may_alias)). However I think a non-aliasing `hash_code()` implementation is possible. Further investigation needed.
* Add `_LIBCPP_UNREACHABLE()` to switch in `strstream.cpp` to avoid -Wpotentially-uninitialized.
* Fix -Wunused-value warning in `__all` by adding a void cast.
* Ignore -Wattributes for now. There are a number of real attribute issues when using GCC but enabling the warning is too noisy.
* Ignore -Wliteral-suffix since it warns about the use of reserved identifiers. Note Only GCC 7.0 supports disabling this warning.
* Ignore -Wc++14-compat since it warns about the sized new/delete overloads.
Reviewers: EricWF
Differential Revision: https://reviews.llvm.org/D24003
llvm-svn: 280007
This assignment operator was previously broken since the SFINAE always resulted
in substitution failure. This caused assignments to turn into
copy construction + assignment.
This patch was originally committed as r279953 but was reverted due to warnings
in the test-suite. This new patch corrects those warnings.
llvm-svn: 279955
This assignment operator was previously broken since the SFINAE always resulted
in substitution failure. This caused assignments to turn into
copy construction + assignment.
llvm-svn: 279953
This patch implements the std::sample function added to C++17 from LFTS. It
also removes the std::experimental::sample implementation which now forwards
to std::sample.
llvm-svn: 279948
Libc++'s implementation of shuffle and sample already support lvalue and rvalue
RNG's. This patch adds tests for both categories and marks the issue as complete.
This patch also contains drive-by change for std::experimental::sample which
improves the diagnostics produced when the correct iterator categories are
not supplied.
llvm-svn: 279947
Similar to rL242623, move C++ version checks outside of _NOEXCEPT_()
macro invocation argument lists, to avoid "embedding a directive within
macro arguments has undefined behavior" warnings.
Differential Revision: https://reviews.llvm.org/D23961
llvm-svn: 279926
Summary:
The point of this patch is to have a consistent convention for naming build, check and install targets so that the targets can be constructed from the project name.
This change renames a bunch of CMake components and targets from libcxx to cxx. For each renamed target I've added a convenience target that matches the old target name and depends on the new target. This will preserve function of the old targets so that the change doesn't break the world. We can evaluate if it is worth removing the extra targets later.
Reviewers: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23699
llvm-svn: 279675
basic_string's constructor calls init which was not getting inlined. This
prevented optimization of const string as init would appear as a call in between
a string's def and use.
Patch by Laxman Sole and Aditya Kumar.
Differential Revision: https://reviews.llvm.org/D22782
llvm-svn: 278356
Summary:
The synopsis in C++11 subclause 28.8 [re.regex] has:
```
basic_regex(const charT* p, size_t len,
flag_type f = regex_constants::ECMAScript);
```
The default argument is added to libc++ by this change.
Reviewers: mclow.lists, rsmith, hubert.reinterpretcast
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D22702
Reapplies r277966.
Patch by Jason Liu!
llvm-svn: 277968
Summary:
In the synopsis in C++11 subclause 28.8 [re.regex], `basic_regex` is
specified to have member typedefs `traits_type` and `string_type`. This
change adds them to libc++.
Reviewers: mclow.lists, rsmith, hubert.reinterpretcast
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D22698
Patch by Jason Liu!
llvm-svn: 277526
This is a breaking change. The SFINAE required is instantiated the second
the class is instantiated, and this can cause hard SFINAE errors
when applied to references to incomplete types. Ex.
struct IncompleteType;
extern IncompleteType it;
std::tuple<IncompleteType&> t(it); // SFINAE will blow up.
llvm-svn: 276598
In C++03 mode evaluating the SFINAE can cause a hard error due to
access control violations. This is a problem because the SFINAE
is evaluated as soon as the class is instantiated, and not later.
llvm-svn: 276594
Summary:
This patch attempts to fix the undefined behavior in __hash_table by changing the node pointer types used throughout. The pointer types are changed for raw pointers in the current ABI and for fancy pointers in ABI V2 (since the fancy pointer types may not be ABI compatible).
The UB in `__hash_table` arises because tree downcasts the embedded end node and then deferences that pointer. Currently there are 2 node types in __hash_table:
* `__hash_node_base` which contains the `__next_` pointer.
* `__hash_node` which contains `__hash_` and `__value_`.
Currently the bucket list, iterators, and `__next_` pointers store pointers to `__hash_node` even though they all need to store `__hash_node_base` pointers.
This patch makes that change by introducing a `__next_pointer` typedef which is a pointer to `__hash_node` in the current ABI and `__hash_node_base` afterwards.
One notable change is to the type of `__bucket_list` which used to be defined as `unique_ptr<__node_pointer[], ...>` and is now `unique_ptr<__next_pointer[], ...>` meaning that we now allocate and deallocate different types using a different allocator. I'm going to give this part of the change more thought since it may introduce compatibility issues.
This change is similar to D20786.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D20787
llvm-svn: 276533
There is a bug in Clang 3.6 and earlier that causes compile failures.
I suspect it's due to the usage of member function parameter names in the
attributes.
llvm-svn: 276507
Summary:
This patch uses the __attribute__((enable_if)) hack suggested by @rsmith to diagnose invalid arguments when possible.
In order to diagnose an invalid argument `m` to `f(m)` we provide an additional overload of `f` that is only enabled when `m` is invalid. When that function is enabled it uses __attribute__((unavailable)) to produce a diagnostic message.
Reviewers: mclow.lists, rsmith, jfb, EricWF
Subscribers: bcraig, jfb, rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D22557
llvm-svn: 276506
Although inheriting constructors have already been fixed in Clang 3.9 I still
choose to fix std::function so users can derive from it with older compilers.
llvm-svn: 276090
The previous implementation relied highly on specializations to handle
special cases. This new implementation lets the compiler do the work when possible.
llvm-svn: 276084
Libc++ provides static assertions to detect reference binding issues inside
tuple. This patch adds tests for those diagnostics.
It should be noted that these static assertions technically violate the
standard since it allows these illegal bindings to occur.
Also see https://llvm.org/bugs/show_bug.cgi?id=20855
llvm-svn: 276078
The functions arg, conj, imag, norm, proj, and real have additional overloads
for arguments of integral or floating point types. However these overloads should
not allow conversions to the integral/floating point types, only exact matches.
This patch constrains these functions so they no longer allow conversions.
llvm-svn: 276067
Summary:
This patch attempts to fix the undefined behavior in __tree by changing the node pointer types used throughout. The pointer types are changed for raw pointers in the current ABI and for fancy pointers in ABI V2 (since the fancy pointer types may not be ABI compatible).
The UB in `__tree` arises because tree downcasts the embedded end node and then deferences that pointer. Currently there are 3 node types in __tree.
* `__tree_end_node` which contains the `__left_` pointer. This node is embedded within the container.
* `__tree_node_base` which contains `__right_`, `__parent_` and `__is_black`. This node is used throughout the tree rebalancing algorithms.
* `__tree_node` which contains `__value_`.
Currently `__tree` stores the start of the tree, `__begin_node_`, as a pointer to a `__tree_node`. Additionally the iterators store their position as a pointer to a `__tree_node`. In both of these cases the pointee can be the end node. This is fixed by changing them to store `__tree_end_node` pointers instead.
To make this change I introduced an `__iter_pointer` typedef which is defined to be a pointer to either `__tree_end_node` in the new ABI or `__tree_node` in the current one.
Both `__tree::__begin_node_` and iterator pointers are now stored as `__iter_pointers`.
The other situation where `__tree_end_node` is stored as the wrong type is in `__tree_node_base::__parent_`. Currently `__left_`, `__right_`, and `__parent_` are all `__tree_node_base` pointers. Since the end node will only be stored in `__parent_` the fix is to change `__parent_` to be a pointer to `__tree_end_node`.
To make this change I introduced a `__parent_pointer` typedef which is defined to be a pointer to either `__tree_end_node` in the new ABI or `__tree_node_base` in the current one.
Note that in the new ABI `__iter_pointer` and `__parent_pointer` are the same type (but not in the old one). The confusion between these two types is unfortunate but it was the best solution I could come up with that maintains the ABI.
The typedef changes force a ton of explicit type casts to correct pointer types and to make current code compatible with both the old and new pointer typedefs. This is the bulk of the change and it's really messy. Unfortunately I don't know how to avoid it.
Please let me know what you think.
Reviewers: howard.hinnant, mclow.lists
Subscribers: howard.hinnant, bbannier, cfe-commits
Differential Revision: https://reviews.llvm.org/D20786
llvm-svn: 276003
This patch does the following:
* It renames `_LIBCPP_TRIVIAL_PAIR_COPY_CTOR` to `_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR`.
* It automatically enables this option on FreeBSD in ABI V1, since that's the current ABI FreeBSD ships.
* It cleans up the handling of this option in `std::pair`.
I would like the sign off from the FreeBSD maintainers. They will no longer need to keep their `__config` changes downstream.
I'm still hoping to come up with a better way to maintain the ABI without needing these constructors.
Reviewed in https://reviews.llvm.org/D21329
llvm-svn: 275749
This patch upgrades <tuple> to be C++17 compliant by implementing:
* tuple_size_v: This was forgotten when implementing the other _v traits.
* std::apply: This was added via LFTS v1 in p0220r1.
* std::make_from_tuple: This was added in p0209r2.
llvm-svn: 275745
This patch implements a simple optimization in __hash_table::find. When iterating
the found bucket we only constrain the bucket elements hash if it doesn't
already match the unconstrained hash of the specified key. This prevent
the performance of an expensive modulo operation.
Since the bucket element almost always matches the key, especially when the
load factor is low, this optimization has large performance impacts. For
a unordered_set<int> of random integers this patch improves the performance of
'find(...)' by 40%.
llvm-svn: 275734
From r229162:
Visual Studio's SAL extension uses a macro named __deallocate. This
macro is used pervasively
Using -Werror when building for Windows can force the use of -Wno-#warnings
specifically because of this __deallocate #warning. Instead of forcing
builds to disable all #warnings, this option allows libc++ to be built
without this particular warning, while leaving other #warnings enabled.
Patch by Dave Lee!
llvm-svn: 275172
This cleans up a previous optimization attempt in hash, and results in
additional performance improvements over that previous attempt. Additionally
this new optimization does not hinder the power of 2 bucket count optimization.
llvm-svn: 275114
Summary: The current implementations of __hash_table::find used by std::unordered_set/unordered_map call key_eq on each key that lands in the same bucket as the key you're looking for. However, since equal objects mush hash to the same value, you can short-circuit the possibly expensive call to key_eq by checking the hashes first.
Reviewers: EricWF
Subscribers: kmensah, cfe-commits
Differential Revision: http://reviews.llvm.org/D21510
llvm-svn: 274857
This patch improves the performance of unordered_set's find by 45% when
the value exists within the set. __hash_tables find method
needs to check if it's reached the end of the bucket by constraining the
hash of the current node and checking it against the bucket index. However
constraining the hash is an expensive operations and it can be avoided if the
two unconstrained hashes are equal. This patch applies that optimization.
This patch also adds a top level directory called benchmarks. 'benchmarks/'
is intended to store any/all benchmarks written for the standard library.
Currently nothing is done with files under 'benchmarks/' but I would like
to move towards introducing a formal format and test runner.
llvm-svn: 274423
This patch is the last in a series that replaces recursive meta-programming
in std::tuple with non-recursive implementations.
Previously std::tuple could only be instantiated with 126 elements before
it blew the max template instantiation depth. Now the size of std::tuple is
essentially unbounded (I've tested with over 5000 elements).
One unfortunate side-effect of this change is that tuple_constructible
and similar no longer short circuit after the first failure. Instead they
evaluate the conditions for all elements. This could be potentially breaking.
I plan to look into this further.
llvm-svn: 274331
This patch attempts to improve the QoI of std::tuples tuple_element and
__make_tuple_types helpers. Previously they required O(N) instantiations,
one for every element in the tuple
The new implementations are O(1) after __tuple_indices<Id...> is created.
llvm-svn: 274330
The previous __make_tuple_indices implementation caused O(N) instantiations
and was pretty inefficient. The C++14 __make_integer_sequence implementation
is much better, since it either uses a builtin to generate the sequence or
a very nice Log8(N) implementation provided by richard smith.
This patch moves the __make_integer_sequence implementation into __tuple
and uses it to implement __make_tuple_indices.
Since libc++ can't expose the name 'integer_sequence' in C++11 this patch
also introduces a dummy type '__integer_sequence' which is used when generating
the sequence. One the sequence is generated '__integer_sequence' can be
converted into the required type; either '__tuple_indices' or 'integer_sequence'.
llvm-svn: 274286
Since at least the C++11 standard insert iterators are specified
as having ::reference typedef void. Libc++ was not doing that.
This patch corrects the typedef.
This patch changes the std::iterator base class of insert_iterator,
front_insert_iterator and back_insert_iterator. This should not
be an ABI breaking change.
llvm-svn: 274209
This patch adds the weak_type typedef in shared_ptr. It is available in
C++17 and newer.
This patch also updates the _LIBCPP_STD_VER and TEST_STD_VER macros to
have the value of 16, since 2016 is the current year.
llvm-svn: 273839
See https://llvm.org/bugs/show_bug.cgi?id=27115
The problem was that the conversion from
'const enable_shared_from_this<T>*' to 'const T*' didn't work if
T inherited enable_shared_from_this as a virtual base class. The fix
is to take the original pointer passed to shared_ptr's constructor in the
__enable_weak_this method and perform an upcast to 'const T*' instead of
performing a downcast from the enable_shared_from_this base.
llvm-svn: 273835
The move constructor for wstring_convert accidentally copied the state member
into the converted count member in the move constructor. This patch fixes
the typo.
While working on this I discovered that wstring_convert doesn't actually
provide a move constructor according to the standard and therefore this
constructor is a libc++ extension. I'll look further into whether libc++ should
provide this constructor at all. Neither libstdc++ or MSVC's STL provide it.
llvm-svn: 273831
This patch makes the bind placeholders in std::placeholders both (1) const and
(2) constexpr (See below).
This is technically a breaking change for any code using the placeholders
outside of std::bind and depending on them being non-const. However I don't
think this will break any real world code.
(1) Previously the placeholders were non-const extern globals in all
dialects. This patch changes these extern globals to be const in all dialects.
Since the cv-qualifiers don't participate in name mangling for globals this
is an ABI compatible change.
(2) Make the placeholders constexpr in C++11 and beyond. Although LWG 2488 only
applies to C++17 I don't see any reason not to backport this change.
llvm-svn: 273824
Summary: this fixes build error when built with c++14 and no exceptions
Reviewers: rmaprath
Subscribers: weimingz, grandinj, rmaprath, cfe-commits
Differential Revision: http://reviews.llvm.org/D21673
llvm-svn: 273697
Libc++ has to deduce the 'allocator_arg_t' parameter as 'AllocArgT' for the
following constructor:
template <class Alloc> tuple(allocator_arg_t, Alloc const&)
Previously libc++ has tried to support tags derived from 'allocator_arg_t' by
using 'is_base_of<AllocArgT, allocator_arg_t>'. However this breaks whenever a
2-tuple contains a reference to an incomplete type as its first parameter.
See https://llvm.org/bugs/show_bug.cgi?id=27684
llvm-svn: 273334
This changes how filesystem::permissions(p, perms) handles symlinks. Previously
symlinks were not resolved by default instead only getting resolved when
"perms::resolve_symlinks" was used. After this change symlinks are resolved
by default and perms::symlink_nofollow must be given to change this.
This issue has not yet been moved to Ready status, and I will revert if it
doesn't get moved at the current meeting. However I feel confident that it
will and it's nice to have implementations when moving issues.
llvm-svn: 273328
Summary:
An implementation of std::experimental::propagate_const from Library Fundamentals Technical Specification v2.
No tests are provided for disallowed types like fancy pointers or function pointers as no code was written to handle these.
Reviewers: EricWF, mclow.lists
Differential Revision: http://reviews.llvm.org/D12486
llvm-svn: 273122
Use strtof and strtod for floats and doubles respectively instead of
always using strtold. The other parts of the change are already implemented
in libc++.
This patch also has a drive by fix to wbuffer_convert::underflow() which
prevents it from calling memmove(buff, null, 0).
llvm-svn: 273106
Summary:
Currently the implementation of [util.smartptr.shared.atomic] is provided only when using Clang, and not with GCC. This is a relic of not having a GCC implementation of <atomic>, even though <atomic> isn't actually used in the implementation. This patch enables support for atomic shared_ptr functions when using GCC.
Note that this is not a header only change. Previously only Clang builds of libc++.so would provide the required symbols. There is no reason for this restriction.
After this change both Clang and GCC builds should be binary compatible with each other WRT these symbols.
Reviewers: mclow.lists, rmaprath, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D21407
llvm-svn: 273076
Add the completed std::experimental::filesystem implementation and tests.
The implementation supports C++11 or newer.
The TS is built as part of 'libc++experimental.a'. Users of the TS need to
manually link this library. Building and testing the TS can be disabled using
the CMake option '-DLIBCXX_ENABLE_FILESYSTEM=OFF'.
Currently 'libc++experimental.a' is not installed by default. To turn on the
installation of the library use '-DLIBCXX_INSTALL_EXPERIMENTAL_LIBRARY=ON'.
llvm-svn: 273034
Summary:
This patch implements the variadic `lock_guard` paper.
Making `lock_guard` variadic is a ABI breaking change because the specialization `lock_guard<_Mutex>` mangles differently then when it was the primary template. This change only provides variadic `lock_guard` in ABI V2 or when `_LIBCPP_ABI_VARIADIC_LOCK_GUARD` is defined.
Note that in ABI V2 `lock_guard` must always be declared as a variadic template, even in C++03, in order to keep the ABI consistent. For this reason `lock_guard` is forward declared as a variadic template in all standard dialects and therefore depends on variadic templates being provided as an extension in C++03. All supported versions of Clang and GCC provide this extension.
Reviewers: mclow.lists
Subscribers: K-ballo, mclow.lists, cfe-commits
Differential Revision: http://reviews.llvm.org/D21260
llvm-svn: 272634
Patch by Laman Sole <laxman.g@partner.samsung.com>, Sebastian Pop
<s.pop@samsung.com>, Aditya Kumar <aditya.k7@samsung.com>
Differential Revision: http://reviews.llvm.org/D21103
llvm-svn: 272401
Summary:
Exactly what it sounds like.
I plan to commit this in a couple of days assuming no objections.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D20799
llvm-svn: 271464
This patch addresses the following issues in the test suite:
1. Move "std::bad_array_length" test from std/ to libcxx/ test directory
since the feature is not a part of the standard.
2. Rename "futures.tas" test directory to "futures.task" since that is the
correct stable name.
3. Move tests for "packaged_task<T>::result_type" from std/ to libcxx/
test directory since the typedef is a libc++ extension.
llvm-svn: 271430
The existing pthread detection code in __config is pretty good for
common operating systems. It doesn't allow cmake-time choices to be
made for uncommon operating systems though.
This change adds the LIBCXX_HAS_PTHREAD_API cmake flag, which turns
into the _LIBCPP_HAS_THREAD_API_PTHREAD preprocessor define. This is
a name change from the old _LIBCPP_THREAD_API_PTHREAD. The lit tests
want __config_site.in variables to have a _LIBCPP_HAS prefix.
http://reviews.llvm.org/D20573
llvm-svn: 270735
The various _l locale extension functions originate from very
different places. Some come from POSIX, some are BSD extensions,
and some are shared BSD and GLIBC extensions. This patch tries to
group the local extension reimplementations by source. This should
make it easier to make libcxx work with POSIX compliant C libraries
that lack these extensions.
The fallback locale functions are also useful on their own for other
lightweight platforms. Putting these fallback implementations in
support/xlocale should enable code sharing.
I have no access to a newlib system or an android system to build
and test with. I _do_ have access to a system without any of the _l
locale extensions though, and I was able to ensure that the new
__posix_l_fallback.h and __strtonum_fallback.h didn't have any massive
problems.
http://reviews.llvm.org/D17416
llvm-svn: 270213
This patch implements the C++11 version of declval without requiring a template
instantiation.
See PR27798 for more information. https://llvm.org/bugs/show_bug.cgi?id=27798
llvm-svn: 269991
When you assign a shared_ptr, the deleter gets called and assigned. In this routine, the assignment happens inside a critical section, which could (potentially) lead to a deadlock, if the deleter did something wonky. Now we swap the old value with an (empty) temporary shared_ptr, and then let the temporary delete the old value when it goes out of scope (after the lock has been released). This should fix PR#27724. Thanks to Hans Boehm for the bug report and the suggested fix.
llvm-svn: 269965
This patch extracts out all the pthread dependencies of libcxx into the
new header __threading_support. The motivation is to make it easy to
re-target libcxx into platforms that do not support pthread.
Original patch from Fulvio Esposito (fulvio.esposito@outlook.com) - D11781
Applied with tweaks - D19412
Change-Id: I301111f0075de93dd8129416e06babc195aa936b
llvm-svn: 268734
This patch fixes a bunch of bugs in the fallback implementation of
is_convertible, which is used by GCC. Removing the "__is_convertible"
specializations for array/function types we fallback on the SFINAE test,
which is more correct.
See https://llvm.org/bugs/show_bug.cgi?id=27538
llvm-svn: 268359
Summary:
Replace non-Standard "atomic_flag f(false);" with Standard "atomic_flag f;" in clear tests.
Although the value of 'f' is unspecified it shouldn't matter because these tests always call `f.test_and_set()` without checking the result, so the initial state shouldn't matter.
The test init03.pass.cpp is explicitly testing this non-Standard extension; It has been moved into the `test/libcxx` directory.
Reviewers: mclow.lists, STL_MSFT
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D19758
llvm-svn: 268355
This change doesn't impact the behavior of the install-libcxx target which installs whichever libcxx components you build, it just adds a separate target to just install the headers.
llvm-svn: 268124
Summary:
when setting LIBCXX_ENABLE_EXCEPTIONS=false, _LIBCPP_NO_EXCEPTIONS wil be defined in both commandline and _config
Reviewers: bcraig, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D19344
llvm-svn: 266956
Summary:
Hi,
When creating a new thread libc++ performs at least 2 allocations. The first allocates a tuple of args and the functor that will be passed to the new thread. The second allocation is for the thread local storage needed internally by libc++. Currently the second allocation happens in the child thread, meaning that if it throws the program will terminate with an uncaught bad alloc.
The solution to this is to allocate ALL memory in the parent thread and then pass it to the child.
See https://llvm.org/bugs/show_bug.cgi?id=15638
Reviewers: mclow.lists, danalbert, jroelofs, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13748
llvm-svn: 266851
The primary purpose of this patch is to add the 'is_callable' traits.
Since 'is_nothrow_callable' required making 'INVOKE' conditionally noexcept
I also took this oppertunity to implement a constexpr version of INVOKE.
This fixes 'std::experimental::apply' which required constexpr 'INVOKE support'.
This patch will be followed up with some cleanup. Primarly removing most
of "__member_function_traits" since it's no longer used by INVOKE (in C++11 at least).
llvm-svn: 266836
In cases where emplace is called with two arguments and the first one
matches the key_type we can Key to check for duplicates before allocating.
This patch expands on work done by dexonsmith@apple.com.
llvm-svn: 266498
There are two main fixes in this patch.
First the constructor SFINAE was changed so that it's evaluated in two stages
where the first stage evaluates the "safe" SFINAE conditions and the second
evaluates the "dangerous" ones. The key is that the second stage is lazily
evaluated only if the first stage passes. This helps fix PR23256
(https://llvm.org/bugs/show_bug.cgi?id=23256).
The second fix is for PR22806 and LWG issue 2549. This fix applies
the suggested resolution to the LWG issue in order to prevent the construction
of dangling references. The SFINAE for this check is contained within
the _PreferTupleLikeConstructor alias template. The tuple-like constructors
are disabled whenever that trait returns false.
(https://llvm.org/bugs/show_bug.cgi?id=22806)
(http://cplusplus.github.io/LWG/lwg-active.html#2549)
llvm-svn: 266461
Summary:
A default uses-allocator constructor has been added since that overload was previously provided by the extended constructor.
Since Clang does implicit conversion checking after substitution this constructor has to deduce the allocator_arg_t parameter so that it can prevent the evaluation of "is_default_constructible" if the first argument doesn't match. See http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1391 for more information.
This patch fixes PR24779 (https://llvm.org/bugs/show_bug.cgi?id=24779)
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D19006
llvm-svn: 266409
map's allocator may only be used to construct objects of 'value_type',
or in this case 'pair<const Key, Value>'. In order to respect this requirement
in operator[], which requires default constructing the 'mapped_type', we have
to use pair's piecewise constructor with '(tuple<Kep>, tuple<>)'.
Unfortunately we still need to provide a fallback implementation for C++03
since we don't have <tuple>. Even worse this fallback is the last remaining
user of '__hash_map_node_destructor' and '__construct_node_with_key'.
This patch also switches try_emplace over to __tree.__emplace_unique_key_args.
llvm-svn: 264989
This patch is fairly large and contains a number of changes. The changes all work towards
allowing __tree to properly handle __value_type esspecially when inserting into the __tree.
I chose not to break this change into smaller patches because it wouldn't be possible to
write meaningful standard-compliant tests for each patch.
It is very similar to r260513 "[libcxx] Teach __hash_table how to handle unordered_map's __hash_value_type".
Changes in <map>
* Remove __value_type's constructors because it should never be constructed directly.
* Make map::emplace and multimap::emplace forward to __tree and remove the old definitions
* Remove "__construct_node" map and multimap member functions. Almost all of the construction is done within __tree.
* Fix map's move constructor to access "__value_type.__nc" directly and pass this object to __tree::insert.
Changes in <__tree>
* Add traits to detect, handle, and unwrap, map's "__value_type".
* Convert methods taking "value_type" to take "__container_value_type" instead. Previously these methods caused
unwanted implicit conversions from "std::pair<Key, Value>" to "__value_type<Key, Value>".
* Delete __tree_node and __tree_node_base's constructors and assignment operators. The node types should never be constructed
because the "__value_" member of __tree_node must be constructed directly by the allocator.
* Make the __tree_node_destructor class and "__construct_node" methods unwrap "__node_value_type" into "__container_value_type" before invoking the allocator. The user's allocator can only be used to construct and destroy the container's value_type. Passing it map's "__value_type" was incorrect.
* Cleanup the "__insert" and "__emplace" methods. Have __insert forward to an __emplace function wherever possible to reduce
code duplication. __insert_unique(value_type const&) and __insert_unique(value_type&&) forward to __emplace_unique_key_args.
These functions will not allocate a new node if the value is already in the tree.
* Change the __find* functions to take the "key_type" directly instead of passing in "value_type" and unwrapping the key later.
This change allows the find functions to be used without having to construct a "value_type" first. This allows for a number
of optimizations.
* Teach __move_assign and __assign_multi methods to unwrap map's __value_type.
llvm-svn: 264986
Summary:
This was voted into C++17 at the Jacksonville meeting. The final P0152R1
paper will be in the upcoming post-Jacksonville mailing, and is also
available here:
http://jfbastien.github.io/papers/P0152R1.html
Reviewers: mclow.lists, rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D17951
llvm-svn: 264413
unordered_set::emplace and unordered_map::emplace construct a node, then
try to insert it. If insertion fails, the node gets deleted.
To avoid this unnecessary malloc traffic, check to see if the argument
to emplace has the appropriate key_type. If so, we can use that key
directly and delay the malloc until we're sure we're inserting something
new.
Test updates by Eric Fiselier, who rewrote the old allocation tests to
include the new cases.
There are two orthogonal future directions:
1. Apply the same optimization to set and map.
2. Extend the optimization to when the argument is not key_type, but can
be converted to it without side effects. Ideally, we could do this
whenever key_type is trivially destructible and the argument is
trivially convertible to key_type, but in practise the relevant type
traits "blow up sometimes". At least, we should catch a few simple
cases (such as when both are primitive types).
llvm-svn: 263746
This adds clang thread safety annotations to std::mutex and
std::lock_guard so code using these types can use these types directly
instead of having to wrap the types to provide annotations. These checks
when enabled by -Wthread-safety provide simple but useful static
checking to detect potential race conditions.
See http://clang.llvm.org/docs/ThreadSafetyAnalysis.html for details.
This patch was reviewed in http://reviews.llvm.org/D14731.
llvm-svn: 263611
std::addressof may be used on a storage of an object before the start
of its lifetime (see std::allocate_shared for example). CFI flags the
C-style cast as invalid in that case.
llvm-svn: 263310
For the locale refactor, the locale management functions (newlocale,
freelocale, uselocale) are needed in a separate header from the various _l
functions. This is because some platforms implement the _l functions in terms
of a locale switcher RAII helper, and the locale switcher RAII helper needs
the locale management functions. This patch helps pave the way by getting all
the functions in the right files, so that later diffs aren't completely
horrible.
Unfortunately, the Windows, Cygwin, and MinGW builds seemed to have
bit-rotted, so I wasn't able to test this completely. I don't think I made
things any worse than they already are though.
http://reviews.llvm.org/D17419
llvm-svn: 263020
Instead of checking _LIBCPP_LOCALE_L_EXTENSIONS all over, instead check it
once, and define the various *_l symbols once. The private redirector symbol
names are all prefixed with _libcpp_* so that they won't conflict with user
symbols, and so they won't conflict with future C library symbols. In
particular, glibc likes providing private symbols such as __locale_t, so we
should follow a different naming pattern (like _libcpp_*) to avoid problems
on that front.
Tested on Linux with glibc. Hoping for the best on OSX and the various BSDs.
http://reviews.llvm.org/D17456
llvm-svn: 263016
Eric Fiselier