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
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
Since they're scheduled to be updated soon, we'll just comment out this test for
the moment, and re-commit when the bots are updated.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@261661 91177308-0d34-0410-b5e6-96231b3b80d8
This patch is very similar to r260431.
This patch is the first in a series of patches that's meant to better
support map. map has a special "value_type" that
differs from pair<const Key, Value>. In order to meet the EmplaceConstructible
and CopyInsertable requirements we need to teach __tree about this
special value_type.
This patch creates a "__tree_node_types" traits class that contains
all of the typedefs needed by the associative containers and their iterators.
These typedefs include ones for each node type and node pointer type,
as well as special typedefs for "map"'s value type.
Although the associative containers already supported incomplete types, this
patch makes it official by adding tests.
This patch will be followed up shortly with various cleanups within __tree and
fixes for various map bugs and problems.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@261416 91177308-0d34-0410-b5e6-96231b3b80d8
unordered_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'.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@260601 91177308-0d34-0410-b5e6-96231b3b80d8
This patch is fairly large and contains a number of changes. The main change
is teaching '__hash_table' how to handle '__hash_value_type'. Unfortunately
this change is a rampant layering violation, but it's required to make
unordered_map conforming without re-writing all of __hash_table.
After this change 'unordered_map' can delegate to '__hash_table' in almost all cases.
The major changes found in this patch are:
* Teach __hash_table to differentiate between the true container value type
and the node value type by introducing the "__container_value_type" and
"__node_value_type" typedefs. In the case of unordered_map '__container_value_type'
is 'pair<const Key, Value>' and '__node_value_type' is '__hash_value_type'.
* Switch almost all overloads in '__hash_table' previously taking 'value_type'
(AKA '__node_value_type) to take '__container_value_type' instead. Previously
'pair<K, V>' would be implicitly converted to '__hash_value_type<K, V>' because
of the function signature.
* Add '__get_key', '__get_value', '__get_ptr', and '__move' static functions to
'__key_value_types'. These functions allow '__hash_table' to unwrap
'__node_value_type' objects into '__container_value_type' and its sub-parts.
* Pass '__hash_value_type::__value_' to 'a.construct(p, ...)' instead of
'__hash_value_type' itself. The C++14 standard requires that 'a.construct()'
and 'a.destroy()' are only ever instantiated for the containers value type.
* Remove '__hash_value_type's constructors and destructors. We should never
construct an instance of this type.
(TODO this is UB but we already do it in plenty of places).
* Add a generic "try-emplace" function to '__hash_table' called
'__emplace_unique_key_args(Key const&, Args...)'.
The following changes were done as cleanup:
* Introduce the '_LIBCPP_CXX03_LANG' macro to be used in place of
'_LIBCPP_HAS_NO_VARIADICS' or '_LIBCPP_HAS_NO_RVALUE_REFERENCE'.
* Cleanup C++11 only overloads that assume an incomplete C++11 implementation.
For example this patch removes the __construct_node overloads that do
manual pack expansion.
* Forward 'unordered_map::emplace' to '__hash_table' and remove dead code
resulting from the change. This includes almost all
'unordered_map::__construct_node' overloads.
The following changes are planed for future revisions:
* Fix LWG issue #2469 by delegating 'unordered_map::operator[]' to use
'__emplace_unique_key_args'.
* Rewrite 'unordered_map::try_emplace' in terms of '__emplace_unique_key_args'.
* Optimize '__emplace_unique' to call '__emplace_unique_key_args' when possible.
This prevent unneeded allocations when inserting duplicate entries.
The additional follow up work needed after this patch:
* Respect the lifetime rules for '__hash_value_type' by actually constructing it.
* Make '__insert_multi' act similar to '__insert_unique' for objects of type
'T&' and 'T const &&' with 'T = __container_value_type'.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@260514 91177308-0d34-0410-b5e6-96231b3b80d8
This patch is fairly large and contains a number of changes. The main change
is teaching '__hash_table' how to handle '__hash_value_type'. Unfortunately
this change is a rampant layering violation, but it's required to make
unordered_map conforming without re-writing all of __hash_table.
After this change 'unordered_map' can delegate to '__hash_table' in almost all cases.
The major changes found in this patch are:
* Teach __hash_table to differentiate between the true container value type
and the node value type by introducing the "__container_value_type" and
"__node_value_type" typedefs. In the case of unordered_map '__container_value_type'
is 'pair<const Key, Value>' and '__node_value_type' is '__hash_value_type'.
* Switch almost all overloads in '__hash_table' previously taking 'value_type'
(AKA '__node_value_type) to take '__container_value_type' instead. Previously
'pair<K, V>' would be implicitly converted to '__hash_value_type<K, V>' because
of the function signature.
* Add '__get_key', '__get_value', '__get_ptr', and '__move' static functions to
'__key_value_types'. These functions allow '__hash_table' to unwrap
'__node_value_type' objects into '__container_value_type' and its sub-parts.
* Pass '__hash_value_type::__value_' to 'a.construct(p, ...)' instead of
'__hash_value_type' itself. The C++14 standard requires that 'a.construct()'
and 'a.destroy()' are only ever instantiated for the containers value type.
* Remove '__hash_value_type's constructors and destructors. We should never
construct an instance of this type.
(TODO this is UB but we already do it in plenty of places).
* Add a generic "try-emplace" function to '__hash_table' called
'__emplace_unique_key_args(Key const&, Args...)'.
The following changes were done as cleanup:
* Introduce the '_LIBCPP_CXX03_LANG' macro to be used in place of
'_LIBCPP_HAS_NO_VARIADICS' or '_LIBCPP_HAS_NO_RVALUE_REFERENCE'.
* Cleanup C++11 only overloads that assume an incomplete C++11 implementation.
For example this patch removes the __construct_node overloads that do
manual pack expansion.
* Forward 'unordered_map::emplace' to '__hash_table' and remove dead code
resulting from the change. This includes almost all
'unordered_map::__construct_node' overloads.
The following changes are planed for future revisions:
* Fix LWG issue #2469 by delegating 'unordered_map::operator[]' to use
'__emplace_unique_key_args'.
* Rewrite 'unordered_map::try_emplace' in terms of '__emplace_unique_key_args'.
* Optimize '__emplace_unique' to call '__emplace_unique_key_args' when possible.
This prevent unneeded allocations when inserting duplicate entries.
The additional follow up work needed after this patch:
* Respect the lifetime rules for '__hash_value_type' by actually constructing it.
* Make '__insert_multi' act similar to '__insert_unique' for objects of type
'T&' and 'T const &&' with 'T = __container_value_type'.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@260513 91177308-0d34-0410-b5e6-96231b3b80d8
This time I kept <ext/hash_map> working!
This patch is the first in a series of patches that's meant to better
support unordered_map. unordered_map has a special "value_type" that
differs from pair<const Key, Value>. In order to meet the EmplaceConstructible
and CopyInsertable requirements we need to teach __hash_table about this
special value_type.
This patch creates a "__hash_node_types" traits class that contains
all of the typedefs needed by the unordered containers and it's iterators.
These typedefs include ones for each node type and node pointer type,
as well as special typedefs for "unordered_map"'s value type.
As a result of this change all of the unordered containers now all support
incomplete types.
As a drive-by fix I changed the difference_type in __hash_table to always
be ptrdiff_t. There is a corresponding change to size_type but it cannot
take affect until an ABI break.
This patch will be followed up shortly with fixes for various unordered_map
bugs and problems.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@260431 91177308-0d34-0410-b5e6-96231b3b80d8
<string.h> and wcschr, wcspbrk, wcsrchr, wmemchr, and wcsstr from <wchar.h> to
provide a const-correct overload set even when the underlying C library does
not.
This change adds a new macro, _LIBCPP_PREFERRED_OVERLOAD, which (if defined)
specifies that a given overload is a better match than an otherwise equally
good function declaration without the overload. This is implemented in modern
versions of Clang via __attribute__((enable_if)), and not elsewhere.
We use this new macro to define overloads in the global namespace for these
functions that displace the overloads provided by the C library, unless we
believe the C library is already providing the correct signatures.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@260337 91177308-0d34-0410-b5e6-96231b3b80d8
This patch is the first in a series of patches that's meant to better
support unordered_map. unordered_map has a special "value_type" that
differs from pair<const Key, Value>. In order to meet the EmplaceConstructible
and CopyInsertable requirements we need to teach __hash_table about this
special value_type.
This patch creates a "__hash_node_types" traits class that contains
all of the typedefs needed by the unordered containers and it's iterators.
These typedefs include ones for each node type and node pointer type,
as well as special typedefs for "unordered_map"'s value type.
As a result of this change all of the unordered containers now all support
incomplete types.
As a drive-by fix I changed the difference_type in __hash_table to always
be ptrdiff_t. There is a corresponding change to size_type but it cannot
take affect until an ABI break.
This patch will be followed up shortly with fixes for various unordered_map
fixes.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@260012 91177308-0d34-0410-b5e6-96231b3b80d8
Rather than crashing in match_results::format() when a reference to a
marked subexpression is out of range, format the subexpression as empty
(i.e., replace it with an empty string). Note that
match_results::operator[]() has a range-check and returns a null match
in this case, so this just re-uses that logic.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@259682 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
These are the tests that didn't fail in the release candidate because they were
covered by another 'REQUIRES' directive.
Reviewers: mclow.lists, hans, bcraig, EricWF
Subscribers: EricWF, dim, cfe-commits
Differential Revision: http://reviews.llvm.org/D16408
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@258920 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch is similar to the <list> fix but it has a few differences. This patch doesn't use a `__link_pointer` typedef because we don't need to change the linked list pointers because `forward_list` never stores a `__forward_begin_node` in the linked list itself.
The issue with `forward_list` is that the iterators store pointers to `__forward_list_node` and not `__forward_begin_node`. This is incorrect because `before_begin()` and `cbefore_begin()` return iterators that point to a `__forward_begin_node`. This means we incorrectly downcast the `__forward_begin_node` pointer to a `__node_pointer`. This downcast itself is sometimes UB but it cannot be safely removed until ABI v2. The more common cause of UB is when we deference the downcast pointer. (for example `__ptr_->__next_`). This can be fixed without an ABI break by upcasting `__ptr_` before accessing it.
The fix is as follows:
1. Introduce a `__iter_node_pointer` typedef that works similar to `__link_pointer` in the last patch. In ABI v2 it is always a typedef for `__begin_node_pointer`.
2. Change the `__before_begin()` method to return the correct pointer type (`__begin_node_pointer`),
Previously it incorrectly downcasted the `__forward_begin_node` to a `__node_pointer` so it could be used to constructor the iterator types.
3. Change `__forward_list_iterator` and `__forward_list_const_iterator` in the following way:
1. Change `__node_pointer __ptr_;` member to have the `__iter_node_pointer` type instead.
2. Add additional private constructors that accept `__begin_node_pointer` in addition to `__node_pointer` and then correctly cast them to the stored `__iter_node_pointer` type.
3. Add `__get_begin()` and `__get_node_unchecked()` accessor methods that correctly cast `__ptr_` to the expected pointer type. `__get_begin()` is always safe to use and should be
preferred. `__get_node_unchecked()` can only be used on a deferencible iterator.
4. Replace direct access to `__forward_list_iterator::__ptr_` with the safe accessor methods.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15836
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@258888 91177308-0d34-0410-b5e6-96231b3b80d8
