public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Malcolm <dmalcolm@redhat.com>
To: Matthias Kretz <m.kretz@gsi.de>, gcc-patches@gcc.gnu.org
Cc: libstdc++@gcc.gnu.org
Subject: Re: [PATCH] Add gnu::diagnose_as attribute
Date: Tue, 04 May 2021 15:00:51 -0400	[thread overview]
Message-ID: <bf4768b29ea2e91bbeccdf6cb17cafbbfcacdcce.camel@redhat.com> (raw)
In-Reply-To: <9837144.KqQxQWANqO@excalibur>

On Tue, 2021-05-04 at 16:23 +0200, Matthias Kretz wrote:
> On Tuesday, 4 May 2021 15:34:13 CEST David Malcolm wrote:
> > On Tue, 2021-05-04 at 13:13 +0200, Matthias Kretz wrote:
> > > This attribute overrides the diagnostics output string for the
> > > entity
> > > it
> > > appertains to. The motivation is to improve QoI for library TS
> > > implementations, where diagnostics have a very bad signal-to-
> > > noise
> > > ratio
> > > due to the long namespaces involved.
> > > [...]
> > 
> > Thanks for the patch, it looks very promising.
> 
> Thanks. I'm new to modifying the compiler like this, so please be
> extra 
> careful with my patch. I believe I understand most of what I did, but
> I might 
> have misunderstood. :)

That's tends to be how I feel when working on the C++ FE :)

> 
> > The patch has no testcases; it should probably add test coverage
> > for:
> > - the various places and ways in which diagnose_as can affect the
> > output,
> > - disabling it with the option
> > - the various ways in which the user can get diagnose_as wrong
> > - etc
> 
> Right. If you know of an existing similar testcase, that'd help me a
> lot to 
> get started.

FWIW I implemented the %H and %I codes in
f012c8ef4b35dcee9b5a3807868d050812d5b3b9 and that commit adds various
DejaGnu testcases that exercise C++ diagnostics with and without
various options, verifying the precise wording of errors.  So that
might be a good place to look.


> 
> > Does the patch affect the output of labels when underlining ranges of
> > source code in diagnostics?
> 
> AFAIU (and tested), it doesn't affect source code output. So, no?

Sorry, I was unclear.  I was referring to this kind of thing:

$ cat t.C
#include <string>

std::string test (std::string s)
{
    return &s;
}

$ g++ t.C
t.C: In function ‘std::string test(std::string)’:
t.C:5:12: error: could not convert ‘& s’ from ‘std::string*’ {aka
‘std::__cxx11::basic_string<char>*’} to ‘std::string’ {aka
‘std::__cxx11::basic_string<char>’}
    5 |     return &s;
      |            ^~
      |            |
      |            std::string* {aka std::__cxx11::basic_string<char>*}

i.e. the final line in the output above, where the underlined range of
source code in line 5 is labelled, showing the type of the expression.

Hopefully it ought to automatically just drop out of the work you've
already done.

FWIW an example of implementation this can be seen in
a14feb3c783fba6af8d66b8138214a3a313be5c5 (which added labels for type
errors in C++ binary operators).


> Does the patch interact correctly with the %H and %I codes that try to
> show the differences between two template types?

I don't know. I'll try to find out. If you have a good idea (or
pointer) for a 
testcase, let me know.

See above.


Dave


  parent reply	other threads:[~2021-05-04 19:00 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <14205410.xuKvIAzr1H@excalibur>
     [not found] ` <20210427094648.GL3008@redhat.com>
2021-05-04 11:13   ` Matthias Kretz
2021-05-04 13:34     ` David Malcolm
2021-05-04 14:23       ` Matthias Kretz
2021-05-04 14:32         ` Matthias Kretz
2021-05-04 19:00         ` David Malcolm [this message]
2021-05-04 19:22           ` Matthias Kretz
2021-05-14 16:05     ` Martin Sebor
2021-05-26 21:33       ` Matthias Kretz
2021-05-27 17:39     ` Jason Merrill
2021-05-27 18:54       ` Matthias Kretz
2021-05-27 21:15         ` Jason Merrill
2021-05-27 22:07           ` Matthias Kretz
2021-05-28  3:05             ` Jason Merrill
2021-05-28  7:42               ` Matthias Kretz
2021-06-01 19:12                 ` Jason Merrill
2021-06-01 21:01                   ` Matthias Kretz
2021-06-11 10:01                   ` Matthias Kretz
2021-06-15 15:51                     ` Jason Merrill
2021-06-15 20:56                       ` Matthias Kretz
2021-06-16  0:48                         ` Jason Merrill
2021-06-22  7:30                           ` Matthias Kretz
2021-06-22 19:52                             ` Jason Merrill
2021-06-22 20:01                               ` Matthias Kretz
2021-06-22 20:12                                 ` Jason Merrill
2021-07-01  9:28                                   ` Matthias Kretz
2021-07-01 15:18                                     ` Jason Merrill
2021-07-05 14:18                                       ` Matthias Kretz
2021-07-07 22:34                                         ` Jason Merrill
2021-07-07  8:23                               ` Matthias Kretz
2021-07-08  1:19                                 ` 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=bf4768b29ea2e91bbeccdf6cb17cafbbfcacdcce.camel@redhat.com \
    --to=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=libstdc++@gcc.gnu.org \
    --cc=m.kretz@gsi.de \
    /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).