Change the behavior of the libc++ std::unordered_map synthetic provider to
present children as std::pair values, just like std::map does. This change
also applies equally to std::unordered_multimap.
Before this change, the synthetic provider for libc++ std::unordered_map has
returned children whose type is an trivial wrapper struct
(__hash_value_type). For example, given an unordered map initialized with
{{1,2}, {3, 4}}, the output is:
(std::unordered_map<int, int, std::hash<int>, std::equal_to<int>, std::allocator<std::pair<const int, int> > >) map = size=2 {
[0] = {
__cc = (first = 3, second = 4)
}
[1] = {
__cc = (first = 1, second = 2)
}
}Compare this output to std::map:
(std::map<int, int, std::less<int>, std::allocator<std::pair<const int, int> > >) map = size=2 {
[0] = (first = 1, second = 2)
[1] = (first = 3, second = 4)The children of std::map have the type std::pair<const Key, T>.
For std::unordered_map, it's not useful to expose the internal wrapper type.
This type is structurally a trivial wrapper, having a single field (__cc)
whose type is std::pair. This change exposes the pair instead of the internal
wrapper type.
It appears the synthetic provider implementation for unordered_map was meant
to provide this behavior (see rGd22a94377f7554a7e9df050f6dfc3ee42384e3fe). The
code has both an m_node_type and an m_element_type, but has only used the
former. The latter, m_element_type, is exactly the type needed for the
children pairs. With this existing code, it's not much of a change to make this
work.
This is not right -- libc++ allows customizing its inline namespace name for versioning purpose; it's not __1 across all deployments. For example, with the libc++ unstable ABI, it will likely be something else. To handle this properly I think you'll need to look for either std::name< or something like std::[a-zA-Z0-9_]*::name<.