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.129.124]) by sourceware.org (Postfix) with ESMTPS id 904A13858C27 for ; Wed, 17 Nov 2021 06:09:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 904A13858C27 Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-275-pRAw-BRWPGCCRAxmUd_U0A-1; Wed, 17 Nov 2021 01:09:21 -0500 X-MC-Unique: pRAw-BRWPGCCRAxmUd_U0A-1 Received: by mail-qt1-f197.google.com with SMTP id u14-20020a05622a198e00b002b2f35a6dcfso1177134qtc.21 for ; Tue, 16 Nov 2021 22:09:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=8p2NN0cxbJMjBs5MTVLTEahc+XQeEyzWXHl+4DspQUA=; b=xEQNjRzWw+yOkkbvtOBcbPIzcngz/HLPik7aKO+FEc96tHelK+aQ0snHtO5qyEZBff Ju9mnAtsFbJxiApEfM9K2w1D4u0IkAiUpkkGVYoAlw5kb24ihxjijs5pGhDZLaut+/84 JDQx0Iufec/Nfv0o0JmJz0fDSC3JueE2wE/oPI5XMYc7DgmpGmCXopT0MVWXSaXTWvai RbfE5NUWhM6Fn9KlWeAYV3G2xo7KNWtHir5sgelB1yWxc/iA3qxeYsWnbCCmDthF2e0T SWnGkgWfxvWhbKnO19T+ehrnyg/hpHBG3UC4VchyzcuZTy+okqJSsYQH3r8hIdk7WoIh BZbQ== X-Gm-Message-State: AOAM533EfnC9u8R0xTvO1knB0SR9l/0zaG4/BTfh0woBh2cZP9wivR0O WR+q3u4KJAa4ijvbmVQWJ05ydO5/jgUVu52e8TqN/ZVjZttD+46Ip2EoU5ZmyiXj6EKXOaRFuZr IpLzjTzXfCEAIKJR04A== X-Received: by 2002:ac8:5c16:: with SMTP id i22mr13553876qti.313.1637129360152; Tue, 16 Nov 2021 22:09:20 -0800 (PST) X-Google-Smtp-Source: ABdhPJwyF5bP/hPBghKwr7weg6X3D63i0nd006rMooBSDTZHkmq4w6yjNagKox0/MlfzxG3HPC7qMg== X-Received: by 2002:ac8:5c16:: with SMTP id i22mr13553826qti.313.1637129359660; Tue, 16 Nov 2021 22:09:19 -0800 (PST) Received: from [192.168.1.149] (130-44-159-43.s15913.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id s11sm10043465qki.95.2021.11.16.22.09.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Nov 2021 22:09:18 -0800 (PST) Message-ID: <768aba03-0419-6934-96f9-d86cf9ef6547@redhat.com> Date: Wed, 17 Nov 2021 01:09:18 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Subject: Re: [RFC] c++: Print function template parms when relevant (was: [PATCH v4] c++: Add gnu::diagnose_as attribute) To: Matthias Kretz , gcc-patches@gcc.gnu.org References: <4361366.VLH7GnMWUR@minbar> <4019800.7NyaFmOyK0@excalibur> <1694479.jsd7nNDzyu@excalibur> From: Jason Merrill In-Reply-To: <1694479.jsd7nNDzyu@excalibur> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.7 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_NONE, TXREP 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: , X-List-Received-Date: Wed, 17 Nov 2021 06:09:24 -0000 On 11/8/21 11:40, Matthias Kretz wrote: > On Tuesday, 17 August 2021 20:31:54 CET Jason Merrill wrote: >>> 2. Given a DECL_TI_ARGS tree, can I query whether an argument was deduced >>> or explicitly specified? I'm asking because I still consider diagnostics >>> of function templates unfortunate. `template void f()` is fine, >>> as is `void f(T) [with T = float]`, but `void f() [with T = float]` could >>> be better. I.e. if the template parameter appears somewhere in the >>> function parameter list, dump_template_parms would only produce noise. >>> If, however, the template parameter was given explicitly, it would be >>> nice if it could show up accordingly in diagnostics. >> >> NON_DEFAULT_TEMPLATE_ARGS_COUNT has that information, though there are >> some issues with it. Attached is my WIP from May to improve it >> somewhat, if that's interesting. > > It is interesting. I used your patch to come up with the attached. Patch. I > must say, I didn't try to read through all the cp/pt.c code to understand all > of what you did there (which is why my ChangeLog entry says "Jason?"), but it > works for me (and all of `make check`). > > Anyway, I'd like to propose the following before finishing my diagnose_as > patch. I believe it's useful to fix this part first. The diagnostic/default- > template-args-[12].C tests show a lot of examples of the intent of this patch. > And the remaining changes to the testsuite show how it changes diagnostic > output. > > ---------------------- 8< -------------------- > > The choice when to print a function template parameter was still > suboptimal. That's because sometimes the function template parameter > list only adds noise, while in other situations the lack of a function > template parameter list makes diagnostic messages hard to understand. > > The general idea of this change is to print template parms wherever they > would appear in the source code as well. Thus, the diagnostics code > needs to know whether any template parameter was given explicitly. > > Signed-off-by: Matthias Kretz > > gcc/testsuite/ChangeLog: > > * g++.dg/debug/dwarf2/template-params-12n.C: Optionally, allow > DW_AT_default_value. > * g++.dg/diagnostic/default-template-args-1.C: New. > * g++.dg/diagnostic/default-template-args-2.C: New. > * g++.dg/diagnostic/param-type-mismatch-2.C: Expect template > parms in diagnostic. > * g++.dg/ext/pretty1.C: Expect function template specialization > to not pretty-print template parms. > * g++.old-deja/g++.ext/pretty3.C: Ditto. > * g++.old-deja/g++.pt/memtemp77.C: Ditto. > * g++.dg/goacc/template.C: Expect function template parms for > explicit arguments. > * g++.dg/gomp/declare-variant-7.C: Expect no function template > parms for deduced arguments. > * g++.dg/template/error40.C: Expect only non-default template > arguments in diagnostic. > > gcc/cp/ChangeLog: > > * cp-tree.h (GET_NON_DEFAULT_TEMPLATE_ARGS_COUNT): Return > absolute value of stored constant. > (EXPLICIT_TEMPLATE_ARGS_P): New. > (SET_EXPLICIT_TEMPLATE_ARGS_P): New. > (TFF_AS_PRIMARY): New constant. > * error.c (get_non_default_template_args_count): Avoid > GET_NON_DEFAULT_TEMPLATE_ARGS_COUNT if > NON_DEFAULT_TEMPLATE_ARGS_COUNT is a NULL_TREE. Make independent > of flag_pretty_templates. > (dump_template_bindings): Add flags parameter to be passed to > get_non_default_template_args_count. Print only non-default > template arguments. > (dump_function_decl): Call dump_function_name and dump_type of > the DECL_CONTEXT with specialized template and set > TFF_AS_PRIMARY for their flags. > (dump_function_name): Add and document conditions for calling > dump_template_parms. > (dump_template_parms): Print only non-default template > parameters. > * pt.c (determine_specialization): Jason? Also copy the inner TREE_VECs. > (template_parms_level_to_args): Jason? Always count non-default args. Also, I think > - if (CHECKING_P) > - SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT (a, TREE_VEC_LENGTH (a)); > + SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT (a, nondefault); should have been if (CHECKING_P || nondefault != TREE_VEC_LENGTH (a)) SET_NON_DEFAULT_TEMPLATE_ARGS_COUNT (a, nondefault); > (copy_template_args): Jason? Only copy the non-default template args count on TREE_VECs that should have it. > (fn_type_unification): Set EXPLICIT_TEMPLATE_ARGS_P on the > template arguments tree if any template parameter was explicitly > given. > (type_unification_real): Jason? Count non-default args sooner. > (get_partial_spec_bindings): Jason? Set non-default args count. > (tsubst_template_args): Determine number of defaulted arguments > from new argument vector, if possible. > --- > gcc/cp/cp-tree.h | 18 +++- > gcc/cp/error.c | 83 ++++++++++++++----- > gcc/cp/pt.c | 58 +++++++++---- > .../g++.dg/debug/dwarf2/template-params-12n.C | 2 +- > .../diagnostic/default-template-args-1.C | 73 ++++++++++++++++ > .../diagnostic/default-template-args-2.C | 37 +++++++++ > .../g++.dg/diagnostic/param-type-mismatch-2.C | 2 +- > gcc/testsuite/g++.dg/ext/pretty1.C | 2 +- > gcc/testsuite/g++.dg/goacc/template.C | 8 +- > gcc/testsuite/g++.dg/gomp/declare-variant-7.C | 4 +- > gcc/testsuite/g++.dg/template/error40.C | 6 +- > gcc/testsuite/g++.old-deja/g++.ext/pretty3.C | 2 +- > gcc/testsuite/g++.old-deja/g++.pt/memtemp77.C | 2 +- > 13 files changed, 242 insertions(+), 55 deletions(-) > create mode 100644 gcc/testsuite/g++.dg/diagnostic/default-template-args-1.C > create mode 100644 gcc/testsuite/g++.dg/diagnostic/default-template-args-2.C > > + /* Pretty print only template instantiations. Don't pretty print explicit > + specializations like 'template <> void fun (int)'. */ This seems like a significant change of behavior unrelated to printing default template arguments. What's the rationale for handling specializations differently from instantiations? I also don't understand the purpose of TFF_AS_PRIMARY. > +/* Print function template parameters if: > + 1. t is template, and > + 2. flags did not request "show only template-name", and > + 3. t is a specialization of a template (Why is this needed? This was present > + since 1999 via !DECL_FRIEND_PSEUDO_TEMPLATE_INSTANTIATION: "Don't crash if > + given a friend pseudo-instantiation". The DECL_USE_TEMPLATE should likely > + inform the PRIMARY parameter of dump_template_parms.), and Good question. It seems that the existing !DECL_FRIEND_PSEUDO_TEMPLATE_INSTANTIATION has mostly been excluding the most general template; removing that line changes things like int bar(T) [with T = int] to int bar(T) [with T = int] > + 4. either > + - flags requests to show no function arguments, in which case deduced > + types could be hidden, or > + - at least one function template argument was given explicitly, or > + - we're printing a DWARF name, ...but perhaps this can replace the above. Though, why do we want different behavior here when printing a DWARF name? > + 5. either > + - t is a member friend template of a template class (see DECL_TI_TEMPLATE > + documentation), or > + - Missing the last item. :) > + */ */ doesn't get its own line. > if (DECL_TEMPLATE_INFO (t) > && !(flags & TFF_TEMPLATE_NAME) > - && !DECL_FRIEND_PSEUDO_TEMPLATE_INSTANTIATION (t) > + && DECL_USE_TEMPLATE (t) > + && ((flags & TFF_NO_FUNCTION_ARGUMENTS) > + || (DECL_TI_ARGS (t) > + && EXPLICIT_TEMPLATE_ARGS_P (INNERMOST_TEMPLATE_ARGS > + (DECL_TI_ARGS (t)))) > + || (pp->flags & pp_c_flag_gnu_v3) != 0) > && (TREE_CODE (DECL_TI_TEMPLATE (t)) != TEMPLATE_DECL > || PRIMARY_TEMPLATE_P (DECL_TI_TEMPLATE (t)))) > - dump_template_parms (pp, DECL_TEMPLATE_INFO (t), !DECL_USE_TEMPLATE (t), > - flags); > + dump_template_parms (pp, DECL_TEMPLATE_INFO (t), false, flags); Jason