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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@266498 91177308-0d34-0410-b5e6-96231b3b80d8
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)
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@266461 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@264989 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@264986 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@263746 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@263611 91177308-0d34-0410-b5e6-96231b3b80d8
Commit f49839299a085505eb673544744b61d2d9cdd1db in glibc-2.14 changed the
locales to the currently required format. However, they were again changed in
commit 55bdd2866f23b28422d969060b3518909a12b100 which has been released in 2.17.
That leads to the current situation where Debian and e.g. CentOS 6 have the
pre-2.14 locales, for example Ubuntu 14.04 has pre-2.17 and CentOS 7 on the
other hand has the newest locales in glibc-2.17.
Differential Revision: http://reviews.llvm.org/D18187
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@263554 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@263310 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@263020 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@263016 91177308-0d34-0410-b5e6-96231b3b80d8
