On 09/10/21 00:59 +0100, Jonathan Wakely wrote:
>This is a step towards restoring support for incomplete types in
>unordered containers (PR 53339).
>
>We do not need to instantiate the node type to get its value_type
>member, because we know that the value type is the first template
>parameter. We can deduce that template argument using a custom trait and
>a partial specialization for _Hash_node. If we wanted to support custom
>hash node types we could still use typename _Tp::value_type in the
>primary template of that trait, but that seems unnecessary.
>
>The other change needed is to defer a static assert at class scope, so
>that it is done when the types are complete. We must have a complete
>type in the destructor, so we can do it there instead.
>
>libstdc++-v3/ChangeLog:
>
>	* include/bits/hashtable.h: Move static assertion to destructor.
>	* include/bits/hashtable_policy.h: Deduce value type from node
>	type without instantiating it.
>
>Tested powerpc64le-linux. Committed to trunk.
>
>This is the patch I referred to in:
>https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576028.html

And this is the one attached to:
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575964.html

This restores support for incomplete types in std::unordered_map.

Tested powerpc64le-linux. Committed to trunk.

     libstdc++: Access std::pair members without tuple-like helpers
     
     This avoids the tuple-like API for std::pair in the unordered
     containers, removing some overly generic code.
     
     The _Select1st projection can figure out the member types of a std::pair
     without using decltype(std::get<0>(...)).
     
     We don't need _Select2nd because it's only needed in
     _NodeBuilder::_S_build, and that can just access the .second member of
     the pair directly. The return type of that function doesn't need to be
     deduced by decltype, we can just expose the __node_type typedef of the
     node generator.