| Message ID | 522C74E1.50305@oracle.com |
|---|---|
| State | New |
| Headers | show |
On Sun, Sep 8, 2013 at 8:00 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote: > Hi all, Gaby, > > in this bug Manuel noticed that the zeros in the diagnostic lines of the > form: > > <built-in>:0:0: .... > > don't provide useful information. Thus the below just avoids printing the > zeros basing directly on the file name: admittedly, it may seem a bit gross, > but in practice the strcmp would often fail early, and should be rather > efficient anyway because the second argument is known at compile-time. For builtins, we probably do not want to print the line number and the column number (both of which are zero). > > Tested x86_64-linux. > > Thanks, > Paolo. > > ////////////////////////
Hi Gaby, On 09/08/2013 03:41 PM, Gabriel Dos Reis wrote: > On Sun, Sep 8, 2013 at 8:00 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote: >> Hi all, Gaby, >> >> in this bug Manuel noticed that the zeros in the diagnostic lines of the >> form: >> >> <built-in>:0:0: .... >> >> don't provide useful information. Thus the below just avoids printing the >> zeros basing directly on the file name: admittedly, it may seem a bit gross, >> but in practice the strcmp would often fail early, and should be rather >> efficient anyway because the second argument is known at compile-time. > For builtins, we probably do not want to print the line number > and the column number (both of which are zero). I agree. This is exactly what my patch does, isn't it? Thanks, Paolo.
On Sun, Sep 8, 2013 at 8:59 AM, Paolo Carlini <paolo.carlini@oracle.com> wrote: > Hi Gaby, > > > On 09/08/2013 03:41 PM, Gabriel Dos Reis wrote: >> >> On Sun, Sep 8, 2013 at 8:00 AM, Paolo Carlini <paolo.carlini@oracle.com> >> wrote: >>> >>> Hi all, Gaby, >>> >>> in this bug Manuel noticed that the zeros in the diagnostic lines of the >>> form: >>> >>> <built-in>:0:0: .... >>> >>> don't provide useful information. Thus the below just avoids printing the >>> zeros basing directly on the file name: admittedly, it may seem a bit >>> gross, >>> but in practice the strcmp would often fail early, and should be rather >>> efficient anyway because the second argument is known at compile-time. >> >> For builtins, we probably do not want to print the line number >> and the column number (both of which are zero). > > I agree. This is exactly what my patch does, isn't it? What I meant is that we should not showing a location at all. I misread the original hunk + : !strcmp (s.file, N_("<built-in>")) + ? build_message_string ("%s%s:%s %s%s%s", locus_cs, s.file, locus_ce, + text_cs, text, text_ce) Sorry. Patch OK. > > Thanks, > Paolo.
Index: diagnostic.c =================================================================== --- diagnostic.c (revision 202358) +++ diagnostic.c (working copy) @@ -245,6 +245,9 @@ diagnostic_build_prefix (diagnostic_context *conte (s.file == NULL ? build_message_string ("%s%s:%s %s%s%s", locus_cs, progname, locus_ce, text_cs, text, text_ce) + : !strcmp (s.file, N_("<built-in>")) + ? build_message_string ("%s%s:%s %s%s%s", locus_cs, s.file, locus_ce, + text_cs, text, text_ce) : context->show_column ? build_message_string ("%s%s:%d:%d:%s %s%s%s", locus_cs, s.file, s.line, s.column, locus_ce, text_cs, text, text_ce) Index: testsuite/g++.dg/overload/new1.C =================================================================== --- testsuite/g++.dg/overload/new1.C (revision 202358) +++ testsuite/g++.dg/overload/new1.C (working copy) @@ -17,6 +17,5 @@ void f(X *x = new (3) X(6)); // { dg-error "" } void f(X *x = new (2) X[10]); // { dg-error "" } // { dg-message "candidate" "candidate note" { target *-*-* } 18 } -// { dg-message "operator new|candidate expects" "match candidate text" { target *-*-* } 00 } void f(X *x = new X[10][5]); // { dg-error "" }