From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jwakely.gcc@gmail.com>
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com
 [IPv6:2a00:1450:4864:20::432])
 by sourceware.org (Postfix) with ESMTPS id 416EC397283A;
 Wed, 23 Jun 2021 06:32:49 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 416EC397283A
Received: by mail-wr1-x432.google.com with SMTP id j2so1226291wrs.12;
 Tue, 22 Jun 2021 23:32:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=tkI8pRQqZUEnn59GuDak7NPSISCWfwrdK26F0lDxcyA=;
 b=Bqlc2EGudJjz2DkLiLr9KyEBUeV6gTEQOHKUVEu1dUpMqqiLA5JkKUzqDTBh32pApQ
 TqSfVC124UlItsSniOMW3Y3+YDDiYckuwZL9fczDje+7VwEaHun5B/8lGrhyADIjbIds
 0hgAhUgIKvXlQMr7I9jN15TY1th+yDUWSk/SX2PeJAzfm2Uhaa+CnEdAnfnIh1K8xtHC
 D31iqx3RtlIgJ1xfNc0DUQkp6GD9y58Qpw8aPxilskLile4yjt17T4n6AQBgP2GZq1Yq
 WUWO8rrP97HoYBOjKrVE95rFI414ar6lsOou0DyTuDslrPRLMfJhVWF6XbjvtQTpRz4z
 bAqA==
X-Gm-Message-State: AOAM531cLouUjLQlUp0E0ItFD8125Gv6VQoHBTTTvO5eAmz8gFwCDEVI
 hH+LjDhzgACgcbkPAPzyU4cHBqDUd5GRUOuPW98=
X-Google-Smtp-Source: ABdhPJzQWoLilv0nIsVRcOlc7hwH1XZhHvPYfMDKysz6Uff1qDe+5ZmcAQ8hak7kbWEMSpqYkjTFxTeiWUGZjX2XVpY=
X-Received: by 2002:a5d:4703:: with SMTP id y3mr9304556wrq.321.1624429968080; 
 Tue, 22 Jun 2021 23:32:48 -0700 (PDT)
MIME-Version: 1.0
References: <20210622184514.1337889-1-ppalka@redhat.com>
 <CACb0b4n8=QeyxxJB7V120Cv2iHtVGgGoMNxRtBH3=9=fUAbpKw@mail.gmail.com>
 <9146c360-b84-d71b-575f-80a247c3df96@idea>
In-Reply-To: <9146c360-b84-d71b-575f-80a247c3df96@idea>
From: Jonathan Wakely <jwakely.gcc@gmail.com>
Date: Wed, 23 Jun 2021 07:32:35 +0100
Message-ID: <CAH6eHdS41qfayk4WmJ5-YQQPdDY05eCxu0C+VEaOVYGjpYtX5Q@mail.gmail.com>
Subject: Re: [PATCH] c++: CTAD and deduction guide selection [PR86439]
To: Patrick Palka <ppalka@redhat.com>
Cc: Jonathan Wakely <jwakely@redhat.com>, "libstdc++" <libstdc++@gcc.gnu.org>, 
 gcc Patches <gcc-patches@gcc.gnu.org>, jason@gcc.gnu.org
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE,
 RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS,
 TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
Content-Type: text/plain; charset="UTF-8"
X-Content-Filtered-By: Mailman/MimeDel 2.1.29
X-BeenThere: libstdc++@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Libstdc++ mailing list <libstdc++.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/libstdc++>,
 <mailto:libstdc++-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/libstdc++/>
List-Post: <mailto:libstdc++@gcc.gnu.org>
List-Help: <mailto:libstdc++-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/libstdc++>,
 <mailto:libstdc++-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jun 2021 06:32:50 -0000

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.