[committed] libstdc++: container erasure overloads (P2077) [PR117404]

[Nathan Myers]

Patched 786e316de5c25a3fddeaa2003f6efb64fb5ab4a9

On 2/6/26 3:07 AM, Jonathan Wakely wrote:
> 
> 
> On Thu, 5 Feb 2026, 23:58 Jakub Jelinek, <jakub@redhat.com 
> <mailto:jakub@redhat.com>> wrote:
> 
>     On Wed, Feb 04, 2026 at 05:42:52PM -0500, Nathan Myers wrote:
>      > +#ifdef __cpp_concepts
>      > +template <typename _Kt, typename _Container>
>      > +  concept __not_container_iterator =
>      > +    (!is_convertible_v<_Kt&&, typename _Container::iterator> &&
>      > +     !is_convertible_v<_Kt&&, typename _Container::const_iterator>);
>      > +
>      > +template <typename _Kt, typename _Container>
>      > +  concept __heterogeneous_key =
>      > +    (!is_same_v<typename _Container::key_type,
>     remove_cvref_t<_Kt>>) &&
> 
>     Shouldn't this be __remove_cvref_t ?
>     I see
>     +FAIL: g++.dg/concepts/expression.C  -std=gnu++17 (test for excess
>     errors)
>     +UNRESOLVED: g++.dg/concepts/expression.C  -std=gnu++17 compilation
>     failed to produce executable
>     remove_cvref_t is C++20 feature, and while concepts are also a C++20
>     feature, we allow -fconcepts -std=c++17 to enable concepts already.
> 
> 
> Then maybe the new concepts should be guarded by __glibcxx_concepts for 
> the library support, or by a macro specific to the container features.
> 
> We don't need or want to find that concept for C++17.
> 
> 
> 
>              Jakub
>