[PATCH] c++: CTAD and deduction guide selection [PR86439]

Jonathan Wakely jwakely.gcc@gmail.com
Wed Jun 23 06:32:35 GMT 2021


On Wed, 23 Jun 2021, 05:20 Patrick Palka via Libstdc++, <
libstdc++@gcc.gnu.org> wrote:

> On Tue, 22 Jun 2021, Jonathan Wakely wrote:
>
> > On Tue, 22 Jun 2021 at 19:45, Patrick Palka wrote:
> > > This change causes us to reject some container CTAD examples in the
> > > libstdc++ testsuite due to deduction failure for {}, which AFAICT is
> the
> > > correct behavior.  Previously, in the case of e.g. the first removed
> > > example for std::map, the type of {} would be deduced to less<int> as a
> > > side effect of forming the call to the selected guide
> > >
> > >   template<typename _Key, typename _Tp, typename _Compare = less<_Key>,
> > >              typename _Allocator = allocator<pair<const _Key, _Tp>>,
> > >              typename = _RequireNotAllocator<_Compare>,
> > >              typename = _RequireAllocator<_Allocator>>
> > >       map(initializer_list<pair<_Key, _Tp>>,
> > >           _Compare = _Compare(), _Allocator = _Allocator())
> > >       -> map<_Key, _Tp, _Compare, _Allocator>;
> > >
> > > which made later overload resolution for the constructor call
> > > unambiguous.  Now, the type of {} remains undeduced until constructor
> > > overload resolution, and we complain about ambiguity with the two
> > > constructors
> > >
> > >   map(initializer_list<value_type> __l,
> > >       const _Compare& __comp = _Compare(),
> > >       const allocator_type& __a = allocator_type())
> > >
> > >   map(initializer_list<value_type> __l, const allocator_type& __a)
> > >
> > > This patch just removes these problematic container CTAD examples.
> >
> > Do all the problematic cases have a corresponding case that doesn't
> > use {} but uses an actual type?
> >
> > If not, we might want to add such cases, to ensure we're still
> > covering all the cases that really *should* work.
>
> Ah, it looks like most tests have one such corresponding case, but since
> the {} can potentially be an allocator or a function, for maximum
> coverage we should have two corresponding cases.  So the revised patch
> below instead replaces each problematic CTAD example with the other
> untested case.
>
> Interestingly two of these new CTAD examples for std::set and std::multiset
> end up triggering an unrelated CTAD bug PR101174 on trunk, so the patch
> comments out these adjusted examples for now.
>

OK, thanks.


More information about the Gcc-patches mailing list