From patchwork Fri Nov 26 15:23:43 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthias Kretz X-Patchwork-Id: 48195 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D0CF23857825 for ; Fri, 26 Nov 2021 15:24:08 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from lxmtout2.gsi.de (lxmtout2.gsi.de [140.181.3.112]) by sourceware.org (Postfix) with ESMTPS id 2B1E13858C39 for ; Fri, 26 Nov 2021 15:23:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2B1E13858C39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gsi.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gsi.de Received: from localhost (localhost [127.0.0.1]) by lxmtout2.gsi.de (Postfix) with ESMTP id B8572202AD67; Fri, 26 Nov 2021 16:23:49 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at lxmtout2.gsi.de Received: from lxmtout2.gsi.de ([127.0.0.1]) by localhost (lxmtout2.gsi.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xS3H-9XHpozL; Fri, 26 Nov 2021 16:23:49 +0100 (CET) Received: from srvex3.campus.gsi.de (unknown [10.10.4.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by lxmtout2.gsi.de (Postfix) with ESMTPS id 9FF38202AD65; Fri, 26 Nov 2021 16:23:49 +0100 (CET) Received: from excalibur.localnet (140.181.3.12) by srvex3.campus.gsi.de (10.10.4.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2375.17; Fri, 26 Nov 2021 16:23:49 +0100 From: Matthias Kretz To: , Jason Merrill Subject: [PATCH 0/2] c++: Print function template parms when relevant (was: [PATCH v4] c++: Add gnu::diagnose_as attribute) Date: Fri, 26 Nov 2021 16:23:43 +0100 Message-ID: <1800263.tdWV9SEqCh@excalibur> Organization: GSI Helmholtzzentrum =?utf-8?q?f=C3=BCr?= Schwerionenforschung In-Reply-To: <47662158-37ba-457a-ba02-fd4c9aaaae31@redhat.com> References: <4361366.VLH7GnMWUR@minbar> <2941803.SbB2uZ23bb@excalibur> <47662158-37ba-457a-ba02-fd4c9aaaae31@redhat.com> MIME-Version: 1.0 X-Originating-IP: [140.181.3.12] X-ClientProxiedBy: srvex3.Campus.gsi.de (10.10.4.16) To srvex3.campus.gsi.de (10.10.4.16) X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, RCVD_IN_MSPIKE_H2, SPF_PASS, TXREP, T_SPF_HELO_PERMERROR autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: , Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" On Friday, 19 November 2021 23:26:57 CET Jason Merrill wrote: > On 11/19/21 04:53, Matthias Kretz wrote: > > On Thursday, 18 November 2021 20:24:36 CET Jason Merrill wrote: > >> On 11/17/21 17:51, Matthias Kretz wrote: > >>>>> __FUNCTION__ was 'fun' all the time, but __PRETTY_FUNCTION__ was > >>>>> 'void fun(T) [with T = int]'. > >>>> > >>>> Isn't that true for instantiations, as well? > >>> > >>> No, instantiations don't have template args/parms in __FUNCTION__. > >> > >> Hmm, that inconsistency seems like a bug, though I'm not sure whether it > >> should have the template args or not; I lean toward not. The standard > >> says that the value of __func__ is implementation-defined, the GCC > >> manual says it's "the unadorned name of the function". > > > > So you think f1 in testsuite/g++.old-deja/g++.ext/pretty3.C needs to > > test for > > > > if (strcmp (function, "f1")) > > > > bad = true; > > > > if (strcmp (pretty, "void f1(T) [with T = int]")) > > > > bad = true; > > I think so. I just found out that the behavior of __FUNCTION__ and DWARF names is related because both go through lang_decl_name in cp/error.c. I.e by removing the test for pp_c_flag_gnu_v3 in dump_function_name and requesting TFF_NO_FUNCTION_ARGUMENTS from lang_decl_name I turned the __FUNCTION__ string into "f1" / "f1". I can filter the former by rejecting the most general template (the DECL_USE_TEMPLATE in dump_function_name we were wondering about). But I can't turn "f1" into "f1" without adding the test for pp_c_flag_gnu_v3 back in dump_function_name. So far __FUNCTION__ and DWARF names want to be the same string. If you want to keep it like this, let me know how the patch should go: "f1" or "f1" (the latter is the status quo and disambiguates different DWARF strings) The __PRETTY_FUNCTION__ string wants to be "void f1(T) [with T = int]", i.e. with the function tparms, because the template args are marked as explicitly specified. This depends on how the function specialization is declared, i.e. 'template<> void f1(int)' vs 'template<> void f1(int)'. I don't know if I can/want to do anything about that. Is that an acceptable result? I'll send two patches: The first patch is what I'd push. The second restores the diagnostics of specialized function templates. > >> That sounds good: omit defaulted parms only if they don't appear in the > >> signature (other than as another default template argument). > > > > Let me check whether I have the right idea: > > > > I could extend find_typenames (which walks the complete) tree to look for > > TEMPLATE_TYPE_PARM (and the 3 others I don't recall right now). But since > > that walks the *complete* tree, it'll simply find all parms with no > > indication > > whether they appear in the signature. Ideas: > Hmm, since it walks DECL_TEMPLATE_RESULT, I wouldn't expect it to find > template parms that aren't in the function signature. You were right, walking TREE_TYPE (DECL_TEMPLATE_RESULT (t)) does what I need.