public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jason Merrill <jason@redhat.com>
To: Patrick Palka <ppalka@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH v3 3/3] c++: note other candidates when diagnosing deletedness
Date: Sun, 10 Dec 2023 14:32:31 -0500	[thread overview]
Message-ID: <6c089ef1-0e7b-4e3b-bfd2-fc32c1c11c46@redhat.com> (raw)
In-Reply-To: <3cfbf151-f87b-49bc-11a0-a96034f9eabb@idea>

On 11/30/23 10:46, Patrick Palka wrote:
> On Fri, 27 Oct 2023, Patrick Palka wrote:
>> On Fri, 27 Oct 2023, Jason Merrill wrote:
>>> On 10/27/23 15:55, Patrick Palka wrote:
>>>> With the previous two patches in place, we can now extend our
>>>> deletedness diagnostic to note the other considered candidates, e.g.:
>>>>
>>>>     deleted16.C: In function 'int main()':
>>>>     deleted16.C:10:4: error: use of deleted function 'void f(int)'
>>>>        10 |   f(0);
>>>>           |   ~^~~
>>>>     deleted16.C:5:6: note: declared here
>>>>         5 | void f(int) = delete;
>>>>           |      ^
>>>>     deleted16.C:5:6: note: candidate: 'void f(int)' (deleted)
>>>>     deleted16.C:6:6: note: candidate: 'void f(...)'
>>>>         6 | void f(...);
>>>>           |      ^
>>>>     deleted16.C:7:6: note: candidate: 'void f(int, int)'
>>>>         7 | void f(int, int);
>>>>           |      ^
>>>>     deleted16.C:7:6: note:   candidate expects 2 arguments, 1 provided
>>>>
>>>> These notes are controlled by a new command line flag -fnote-all-cands,
>>>> which also controls whether we note ignored candidates more generally.
>>>>
>>>> gcc/ChangeLog:
>>>>
>>>> 	* doc/invoke.texi (C++ Dialect Options): Document -fnote-all-cands.
>>>>
>>>> gcc/c-family/ChangeLog:
>>>>
>>>> 	* c.opt: Add -fnote-all-cands.
>>>>
>>>> gcc/cp/ChangeLog:
>>>>
>>>> 	* call.cc (print_z_candidates): Only print ignored candidates
>>>> 	when -fnote-all-cands is set.
>>>> 	(build_over_call): When diagnosing deletedness, call
>>>> 	print_z_candidates if -fnote-all-cands is set.
>>>
>>> My suggestion was also to suggest using the flag in cases where it would make
>>> a difference, e.g.
>>>
>>> note: some candidates omitted, use '-fnote-all-cands' to display them
>>
>> Ah thanks, fixed.  That'll help a lot with discoverability of the flag.
>>
>>>
>>> Maybe "-fdiagnostics-all-candidates"?
>>
>> Nice, that's a better name indeed :)
>>
>> How does the following look?  Full bootstrap/regtest in progress.
>>
>> Here's the output of e.g. deleted16a.C.  I think I'd prefer to not print
>> the source line when emitting the suggestion, but I don't know how to do
>> that properly (aside from e.g. emitting the note at UNKNOWN_LOCATION).
>>
>> In file included from gcc/testsuite/g++.dg/cpp0x/deleted16a.C:4:
>> gcc/testsuite/g++.dg/cpp0x/deleted16.C: In function ‘int main()’:
>> gcc/testsuite/g++.dg/cpp0x/deleted16.C:21:4: error: use of deleted function ‘void f(int)’
>>     21 |   f(0); // { dg-error "deleted" }
>>        |   ~^~~
>> gcc/testsuite/g++.dg/cpp0x/deleted16.C:6:6: note: declared here
>>      6 | void f(int) = delete; // { dg-message "declared here" }
>>        |      ^
>> gcc/testsuite/g++.dg/cpp0x/deleted16.C:21:4: note: use ‘-fdiagnostics-all-candidates’ to display considered candidates
>>     21 |   f(0); // { dg-error "deleted" }
>>        |   ~^~~
>> gcc/testsuite/g++.dg/cpp0x/deleted16.C:22:4: error: use of deleted function ‘void g(int)’
>>     22 |   g(0); // { dg-error "deleted" }
>>        |   ~^~~
>> gcc/testsuite/g++.dg/cpp0x/deleted16.C:12:6: note: declared here
>>     12 | void g(int) = delete; // { dg-message "declared here" }
>>        |      ^
>> gcc/testsuite/g++.dg/cpp0x/deleted16.C:22:4: note: use ‘-fdiagnostics-all-candidates’ to display considered candidates
>>     22 |   g(0); // { dg-error "deleted" }
>>        |   ~^~~
>> gcc/testsuite/g++.dg/cpp0x/deleted16.C:23:4: error: use of deleted function ‘void h(T, T) [with T = int]’
>>     23 |   h(1, 1); // { dg-error "deleted" }
>>        |   ~^~~~~~
>> gcc/testsuite/g++.dg/cpp0x/deleted16.C:17:24: note: declared here
>>     17 | template<class T> void h(T, T) = delete; // { dg-message "declared here|candidate" }
>>        |                        ^
>> gcc/testsuite/g++.dg/cpp0x/deleted16.C:23:4: note: use ‘-fdiagnostics-all-candidates’ to display considered candidates
>>     23 |   h(1, 1); // { dg-error "deleted" }
>>        |   ~^~~~~~
>>
>> -- >8 --
>>
>>
>> Subject: [PATCH 3/3] c++: note other candidates when diagnosing deletedness
>>
>> With the previous two patches in place, we can now extend our
>> deletedness diagnostic to note the other considered candidates, e.g.:
>>
>>    deleted16.C: In function 'int main()':
>>    deleted16.C:10:4: error: use of deleted function 'void f(int)'
>>       10 |   f(0);
>>          |   ~^~~
>>    deleted16.C:5:6: note: declared here
>>        5 | void f(int) = delete;
>>          |      ^
>>    deleted16.C:5:6: note: candidate: 'void f(int)' (deleted)
>>    deleted16.C:6:6: note: candidate: 'void f(...)'
>>        6 | void f(...);
>>          |      ^
>>    deleted16.C:7:6: note: candidate: 'void f(int, int)'
>>        7 | void f(int, int);
>>          |      ^
>>    deleted16.C:7:6: note:   candidate expects 2 arguments, 1 provided
>>
>> These notes are controlled by a new command line flag
>> -fdiagnostics-all-candidates which also controls whether we note
>> ignored candidates more generally.
>>
>> gcc/ChangeLog:
>>
>> 	* doc/invoke.texi (C++ Dialect Options): Document
>> 	-fdiagnostics-all-candidates.
>>
>> gcc/c-family/ChangeLog:
>>
>> 	* c.opt: Add -fdiagnostics-all-candidates.
>>
>> gcc/cp/ChangeLog:
>>
>> 	* call.cc (print_z_candidates): Only print ignored candidates
>> 	when -fdiagnostics-all-candidates is set, otherwise suggest
>> 	the flag.
>> 	(build_over_call): When diagnosing deletedness, note
>> 	other candidates only if -fdiagnostics-all-candidates is
>> 	set, otherwise suggest the flag.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 	* g++.dg/overload/error6.C: Pass -fdiagnostics-all-candidates.
>> 	* g++.dg/cpp0x/deleted16.C: New test.
>> 	* g++.dg/cpp0x/deleted16a.C: New test.
>> 	* g++.dg/overload/error6a.C: New test.
> 
> Ping.

OK.

Jason


  reply	other threads:[~2023-12-10 19:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-27 19:55 [PATCH v3 1/3] c++: sort candidates according to viability Patrick Palka
2023-10-27 19:55 ` [PATCH v3 2/3] c++: remember candidates that we ignored Patrick Palka
2023-10-27 19:55 ` [PATCH v3 3/3] c++: note other candidates when diagnosing deletedness Patrick Palka
2023-10-27 22:29   ` Jason Merrill
2023-10-27 23:22     ` Patrick Palka
2023-10-27 23:28       ` Patrick Palka
2023-11-30 15:46       ` Patrick Palka
2023-12-10 19:32         ` Jason Merrill [this message]
2023-10-27 22:05 ` [PATCH v3 1/3] c++: sort candidates according to viability Jason Merrill

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6c089ef1-0e7b-4e3b-bfd2-fc32c1c11c46@redhat.com \
    --to=jason@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ppalka@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).