From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id E6CD6394443E for ; Tue, 13 Apr 2021 12:41:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E6CD6394443E Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-388-3bOL79XsNlunZQseQCAXbQ-1; Tue, 13 Apr 2021 08:41:43 -0400 X-MC-Unique: 3bOL79XsNlunZQseQCAXbQ-1 Received: by mail-qt1-f200.google.com with SMTP id f8so1129059qtv.22 for ; Tue, 13 Apr 2021 05:41:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sLeAJI6hSfVV+LgaM1Lr7ZI8fHbbhglnkgumIEbS1Kc=; b=pPRnpo+oOYUh5tOAiZj1a0vTVVZzrgWhXsLd8ZWSGt5ks2FzjDjYgsg+Xa3ZALkLii FLACeMF+efMqO5Eh5V4caKv93vixxavKUY3F0KQXhBD5Q4f7I6+V32+25pFWfWBlwbuu h5AGv04U4N3VExgbJIpnfg60U27HCy7Y/RBZCV7OoTgTGdDsH0TIrzJkzn5gfCxB9e8z 0xX2ij5ivgitwTdjGb7/Yz4rbTg/dlrawbfNVwhCridJP5J9zrw28Di8kDii7YHqH3la SqJTaFxpwM65mHp2shztrPyC2PxVpnuuskvftJOuxXka9uo38uKNnYPpeUR6o89OxijX 17fA== X-Gm-Message-State: AOAM533evfUtS5WDuzvorzFYotrDfANXMAiKndvM1X7WgcvFT3XNuVoB EVoz4pFzOlAPhAgvU9ErK5UifItamFHCfYxZUBpRbLgLc75txEXCG7GTSXLGP/nvTNixrnJpIci jCyITcdpdB3NZn6xC2kKNX6thrDc6wr6fowK1BXInAdqsPDYV6esBQYD7f6jAR1WOEg== X-Received: by 2002:a05:620a:759:: with SMTP id i25mr2944798qki.193.1618317702620; Tue, 13 Apr 2021 05:41:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwKmY0VM4PON9YPhgIulTR0wPON1clu/foPKgAufA1eC2uAvL7m3D/0d534FeTvCtUaUqh3Mg== X-Received: by 2002:a05:620a:759:: with SMTP id i25mr2944775qki.193.1618317702299; Tue, 13 Apr 2021 05:41:42 -0700 (PDT) Received: from [192.168.1.148] (209-6-216-142.s141.c3-0.smr-cbr1.sbo-smr.ma.cable.rcncustomer.com. [209.6.216.142]) by smtp.gmail.com with ESMTPSA id 22sm9075628qtr.24.2021.04.13.05.41.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Apr 2021 05:41:41 -0700 (PDT) Subject: Re: [PATCH] c++: Reject alias CTAD in C++17 [PR99008] To: Patrick Palka Cc: gcc-patches@gcc.gnu.org References: <20210410195736.2059574-1-ppalka@redhat.com> <81b567a4-1287-b59a-fb57-6771fe2fd8c9@redhat.com> From: Jason Merrill Message-ID: <01fc1db7-f651-a321-a75d-ab635677609c@redhat.com> Date: Tue, 13 Apr 2021 08:41:40 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 12:41:47 -0000 On 4/12/21 6:24 PM, Patrick Palka wrote: > On Mon, 12 Apr 2021, Jason Merrill wrote: > >> On 4/10/21 3:57 PM, Patrick Palka wrote: >>> Here, in C++17 mode, we only pedwarn about the use of alias CTAD and >>> then later ICE from alias_ctad_tweaks when attempting to add a >>> constraint to one of the guides. Since the construction of the guides >>> of an alias template effectively relies on concepts, we shouldn't be >>> permissive about alias CTAD in C++17 mode, so this patch turns the >>> pertinent pedwarn in do_class_deduction into an error. >> >> Sounds good. >> >>> In order to get a consistent diagnostic for B() vs the other forms in >>> the added testcase, I had to remove the special handling of CTAD with >>> empty initializer in build_functional_cast_1 so that we always pass >>> 'complain' to do_auto_deduction. >> >> Did you compare the resulting diagnostics when deduction fails other than for >> trying to do alias deduction in C++17 mode? > > For plain CTAD, e.g. for > > template struct A { }; > auto a = A(); > > we previously emitted > > test.C:2:10: error: cannot deduce template arguments for ‘A<...auto...>’ from ‘()’ > 2 | auto a = A(); > | ^~~ > > and now we emit > > test.C:2:12: error: class template argument deduction failed: > 2 | auto a = A(); > | ^ > test.C:2:12: error: no matching function for call to ‘A()’ > test.C:1:27: note: candidate: ‘template A()-> A’ > 1 | template struct A { }; > | ^ > test.C:1:27: note: template argument deduction/substitution failed: > test.C:2:12: note: couldn’t deduce template parameter ‘T’ > 2 | auto a = A(); > | ^ > test.C:1:27: note: candidate: ‘template A(A)-> A’ > 1 | template struct A { }; > | ^ > test.C:1:27: note: template argument deduction/substitution failed: > test.C:2:12: note: candidate expects 1 argument, 0 provided > 2 | auto a = A(); > | ^ > > which is consistent with what we already emit for failed CTAD of the > form A{}, A(args) and A{args}. Thanks, that's fine. The patch is OK. > I think this change should have no diagnostic/functional impact in other > deduction situations because the code path is guarded by a > CLASS_PLACEHOLDER_TEMPLATE check (and we create template placeholders > only in C++17 mode). Jason