* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
@ 2012-03-21 12:06 ` manu at gcc dot gnu.org
2012-04-04 15:28 ` manu at gcc dot gnu.org
` (37 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-03-21 12:06 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |borut.razem at gmail dot
| |com
--- Comment #15 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-03-21 12:05:08 UTC ---
*** Bug 52655 has been marked as a duplicate of this bug. ***
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
2012-03-21 12:06 ` manu at gcc dot gnu.org
@ 2012-04-04 15:28 ` manu at gcc dot gnu.org
2012-04-04 15:32 ` manu at gcc dot gnu.org
` (36 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-04-04 15:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu.org
--- Comment #16 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-04 15:26:50 UTC ---
@Jason,
This is my current patch. It directly opens the file a looks for the line.
I see several improvements that could be made, like handling very long lines in
a smarter way, a cache of already opened files, and moving all this code to
libcpp (or even better to a separate liblinemap library). But there are
improvements that could be done post-commit.
This patch bootstraps for languages=all,ada with both the default set to off
and on, and regression tested with the default set to off, because I couldn't
find a good way to tell DejaGNU to always use -fno-diagnostics-show-caret. Does
anyone know the correct way to do this? This is the only missing piece.
If it looks ok to you, I will write a changelog and submit it to gcc-patches.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
2012-03-21 12:06 ` manu at gcc dot gnu.org
2012-04-04 15:28 ` manu at gcc dot gnu.org
@ 2012-04-04 15:32 ` manu at gcc dot gnu.org
2012-04-04 15:50 ` paolo.carlini at oracle dot com
` (35 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-04-04 15:32 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #17 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-04 15:28:08 UTC ---
Created attachment 27089
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27089
caret diagnostics patch
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2012-04-04 15:32 ` manu at gcc dot gnu.org
@ 2012-04-04 15:50 ` paolo.carlini at oracle dot com
2012-04-04 18:49 ` jason at gcc dot gnu.org
` (34 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: paolo.carlini at oracle dot com @ 2012-04-04 15:50 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
Paolo Carlini <paolo.carlini at oracle dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |paolo.carlini at oracle dot
| |com
--- Comment #18 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-04-04 15:49:33 UTC ---
Oh my, Manuel, yesterday I was walking by myself and it occurred to me that I
didn't understand at all why we are not doing *already* what you are suggesting
now!! Of course the idea came from Jason's comment about using a script. I said
to myself: if we can do it so easily with a script, why can't we do it as part
of GCC itself?!? (I'm not touching at all the issues with existing bugs in the
column information, ranges, etc)
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2012-04-04 15:50 ` paolo.carlini at oracle dot com
@ 2012-04-04 18:49 ` jason at gcc dot gnu.org
2012-04-04 18:53 ` manu at gcc dot gnu.org
` (33 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: jason at gcc dot gnu.org @ 2012-04-04 18:49 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #19 from Jason Merrill <jason at gcc dot gnu.org> 2012-04-04 18:47:58 UTC ---
Created attachment 27092
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27092
Patch to add -fno-diagnostics-show-caret for testing
This seems like what you want for the last bit.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2012-04-04 18:49 ` jason at gcc dot gnu.org
@ 2012-04-04 18:53 ` manu at gcc dot gnu.org
2012-04-04 19:20 ` jason at gcc dot gnu.org
` (32 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-04-04 18:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #20 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-04 18:52:32 UTC ---
(In reply to comment #19)
> Created attachment 27092 [details]
> Patch to add -fno-diagnostics-show-caret for testing
>
> This seems like what you want for the last bit.
Great, this works for C++, however, the caret is enabled for diagnostic that
uses the diagnostics machinery, independently of the language (for example,
warnings from the middle-end). If there is no general way, I guess I can do
this for every language.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2012-04-04 18:53 ` manu at gcc dot gnu.org
@ 2012-04-04 19:20 ` jason at gcc dot gnu.org
2012-04-05 12:14 ` manu at gcc dot gnu.org
` (31 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: jason at gcc dot gnu.org @ 2012-04-04 19:20 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #27092|0 |1
is obsolete| |
--- Comment #21 from Jason Merrill <jason at gcc dot gnu.org> 2012-04-04 19:19:21 UTC ---
Created attachment 27093
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27093
Patch to prune caret diagnostics from gcc output
Actually, this seems like a better approach: rather than disable the caret
diagnostics, prune them from the output. This regexp will remove any pair of
lines where the first starts with a space and the second consists of spaces
followed by a caret.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2012-04-04 19:20 ` jason at gcc dot gnu.org
@ 2012-04-05 12:14 ` manu at gcc dot gnu.org
2012-04-05 17:02 ` jason at gcc dot gnu.org
` (30 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-04-05 12:14 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #22 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-05 12:13:01 UTC ---
(In reply to comment #21)
> Created attachment 27093 [details]
> Patch to prune caret diagnostics from gcc output
>
> Actually, this seems like a better approach: rather than disable the caret
> diagnostics, prune them from the output. This regexp will remove any pair of
> lines where the first starts with a space and the second consists of spaces
> followed by a caret.
Unfortunately this does not work for several reasons:
* DejaGNU trims leading whitespace before passing the text to prune.
* DejaGNU matches as many lines as possible for each dg-* directive, so if you
have something in the source line printed that is matched by a dg-* directive,
the line is removed and the above regexp fails to prune the caret line.
The problem is that the default regexp of DejaGNU is:
"(^|\n)(\[^\n\]+$line\[^\n\]*($pattern)\[^\n\]*\n?)+"
the "+" at the end means that it matches as many lines as possible. It also
matches any trailing and any leading whitespace. That is, it is impossible to
tell to DejaGNU to match some line exactly.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2012-04-05 12:14 ` manu at gcc dot gnu.org
@ 2012-04-05 17:02 ` jason at gcc dot gnu.org
2012-04-05 22:06 ` manu at gcc dot gnu.org
` (29 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: jason at gcc dot gnu.org @ 2012-04-05 17:02 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #23 from Jason Merrill <jason at gcc dot gnu.org> 2012-04-05 17:00:59 UTC ---
(In reply to comment #22)
> * DejaGNU trims leading whitespace before passing the text to prune.
So it does. Bizarre.
set comp_output [string trimleft $comp_output]
I guess we can just remove the initial space from that prune pattern.
> The problem is that the default regexp of DejaGNU is:
>
> "(^|\n)(\[^\n\]+$line\[^\n\]*($pattern)\[^\n\]*\n?)+"
>
> the "+" at the end means that it matches as many lines as possible.
Yes, but only lines that match the line number followed by the pattern; the
source line shouldn't have its own line number before the pattern.
However, if an expected error contains .*, it will typically match both the
error message and the source line, so any .* in testcases would need to change
to \[^\n\].
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2012-04-05 17:02 ` jason at gcc dot gnu.org
@ 2012-04-05 22:06 ` manu at gcc dot gnu.org
2012-04-05 22:10 ` manu at gcc dot gnu.org
` (28 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-04-05 22:06 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #24 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-05 22:05:15 UTC ---
(In reply to comment #23)
> (In reply to comment #22)
> > * DejaGNU trims leading whitespace before passing the text to prune.
>
> So it does. Bizarre.
>
> set comp_output [string trimleft $comp_output]
>
> I guess we can just remove the initial space from that prune pattern.
>
> > The problem is that the default regexp of DejaGNU is:
> >
> > "(^|\n)(\[^\n\]+$line\[^\n\]*($pattern)\[^\n\]*\n?)+"
> >
> > the "+" at the end means that it matches as many lines as possible.
>
> Yes, but only lines that match the line number followed by the pattern; the
> source line shouldn't have its own line number before the pattern.
There are a few dg- directives with line number 0. They match everywhere.
Another problem with c99-vla-jump-3.c and similar testcases is that it seems as
if DejaGNU limits the output (or has a limited size buffer for text) and
decides to stop parsing in the middle of a source line, which breaks the
pruning (and misses several diagnostics that need to be matched). Could this be
true or am I doing something wrong?
I am starting to reconsider adding -fno-diagnostics-show-caret everywhere.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2012-04-05 22:06 ` manu at gcc dot gnu.org
@ 2012-04-05 22:10 ` manu at gcc dot gnu.org
2012-04-07 12:55 ` manu at gcc dot gnu.org
` (27 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-04-05 22:10 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #25 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-05 22:09:30 UTC ---
> Another problem with c99-vla-jump-3.c and similar testcases is that it seems as
> if DejaGNU limits the output (or has a limited size buffer for text) and
> decides to stop parsing in the middle of a source line, which breaks the
> pruning (and misses several diagnostics that need to be matched). Could this be
> true or am I doing something wrong?
PR12096 ?
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2012-04-05 22:10 ` manu at gcc dot gnu.org
@ 2012-04-07 12:55 ` manu at gcc dot gnu.org
2012-04-09 16:07 ` dodji at seketeli dot org
` (26 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-04-07 12:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dodji at gcc dot gnu.org
--- Comment #26 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-07 12:53:34 UTC ---
A sneak-peek into the future ;-)
manuel@gcc12:~/test2/186200M/build/gcc$ ./cc1 -ftrack-macro-expansion
~/macro-clang.c
foo
/home/manuel/macro-clang.c: In function ‘foo’:
/home/manuel/macro-clang.c:2:94: error: invalid operands to binary < (have
‘struct mystruct’ and ‘float’)
#define MYMAX(A,B) __extension__ ({ __typeof__(A) __a = (A); __typeof__(B)
__b = (B); __a < __b ? __b : __a; })
^
/home/manuel/macro-clang.c:2:94: note: in expansion of macro 'MYMAX'
#define MYMAX(A,B) __extension__ ({ __typeof__(A) __a = (A); __typeof__(B)
__b = (B); __a < __b ? __b : __a; })
^
/home/manuel/macro-clang.c:8:11: note: expanded from here
float x = MYMAX(p, f);
^
This is not possible with the patch just posted, but I will send this follow up
after the initial part is committed. Of course, it needs some fine-tuning to
avoid repetitions, but this is a problem with the locations given by the macro
expansion unwinder, which, in my opinion, doesn't give the best location for
each message and already produces repetitions. See:
/home/manuel/macro-caret.c: In function ‘g’:
/home/manuel/macro-caret.c:5:14: error: invalid operands to binary << (have
‘double’ and ‘int’)
OPERATE (A,<<,B)
^
/home/manuel/macro-caret.c:2:9: note: in expansion of macro 'OPERATE'
OPRD1 OPRT OPRD2;
^
/home/manuel/macro-caret.c:5:3: note: expanded from here
OPERATE (A,<<,B)
^
/home/manuel/macro-caret.c:5:14: note: in expansion of macro 'SHIFTL'
OPERATE (A,<<,B)
^
/home/manuel/macro-caret.c:8:3: note: expanded from here
SHIFTL (A,1)
^
/home/manuel/macro-caret.c:8:3: note: in expansion of macro 'MULT'
SHIFTL (A,1)
^
/home/manuel/macro-caret.c:13:3: note: expanded from here
MULT (1.0);// 1.0 << 1; <-- so this is an error.
^
Another possibility could be to print the preprocessed string when saying "in
expansion". However, I am not sure how hard it will be to obtain the
preprocessed string (or to re-create it at runtime). Help and pointers on how
to achieve that are welcome.
Dodji, are you planning to propose to enable -ftrack-macro-expansion by default
in GCC 4.8?
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2012-04-07 12:55 ` manu at gcc dot gnu.org
@ 2012-04-09 16:07 ` dodji at seketeli dot org
2012-04-09 16:20 ` dodji at seketeli dot org
` (25 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: dodji at seketeli dot org @ 2012-04-09 16:07 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #27 from dodji at seketeli dot org <dodji at seketeli dot org> 2012-04-09 16:04:46 UTC ---
"manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> a écrit:
> Dodji, are you planning to propose to enable -ftrack-macro-expansion
> by default in GCC 4.8?
Wow, what a timing!
I am working on a patch-set to enable -ftrack-macro-expansion by default
for GCC 4.8. It appeared that quite some fixes were still needed for
that ;-) It seems to pass bootstrap for C/C++ at the moment, so I think
I'll start polishing & flushing it out to gcc-patches shortly.
For the curious, my current tree is browsable at
http://seketeli.net/git/~dodji/gcc.git/log/?h=track-locs-by-default
To get the code, do:
git clone git://seketeli.net/~dodji/gcc gcc.git
cd gcc.git
git checkout track-locs-by-default
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (12 preceding siblings ...)
2012-04-09 16:07 ` dodji at seketeli dot org
@ 2012-04-09 16:20 ` dodji at seketeli dot org
2012-04-11 9:28 ` manu at gcc dot gnu.org
` (24 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: dodji at seketeli dot org @ 2012-04-09 16:20 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #28 from dodji at seketeli dot org <dodji at seketeli dot org> 2012-04-09 16:19:15 UTC ---
"manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> a écrit:
> Of course, it needs some fine-tuning to avoid repetitions, but this is
> a problem with the locations given by the macro expansion unwinder,
> which, in my opinion, doesn't give the best location for each message
> and already produces repetitions. See:
>
> /home/manuel/macro-caret.c: In function ‘g’:
> /home/manuel/macro-caret.c:5:14: error: invalid operands to binary << (have
> ‘double’ and ‘int’)
> OPERATE (A,<<,B)
> ^
> /home/manuel/macro-caret.c:2:9: note: in expansion of macro 'OPERATE'
> OPRD1 OPRT OPRD2;
> ^
> /home/manuel/macro-caret.c:5:3: note: expanded from here
> OPERATE (A,<<,B)
> ^
> /home/manuel/macro-caret.c:5:14: note: in expansion of macro 'SHIFTL'
> OPERATE (A,<<,B)
> ^
> /home/manuel/macro-caret.c:8:3: note: expanded from here
> SHIFTL (A,1)
> ^
> /home/manuel/macro-caret.c:8:3: note: in expansion of macro 'MULT'
> SHIFTL (A,1)
> ^
> /home/manuel/macro-caret.c:13:3: note: expanded from here
> MULT (1.0);// 1.0 << 1; <-- so this is an error.
> ^
Could you please file a specific bug for this and CC me? I'd be
interested to give this a look.
Thanks.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (13 preceding siblings ...)
2012-04-09 16:20 ` dodji at seketeli dot org
@ 2012-04-11 9:28 ` manu at gcc dot gnu.org
2012-04-11 9:53 ` manu at gcc dot gnu.org
` (23 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-04-11 9:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #29 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-11 09:26:55 UTC ---
Author: manu
Date: Wed Apr 11 09:26:48 2012
New Revision: 186305
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186305
Log:
2012-04-11 Manuel López-Ibáñez <manu@gcc.gnu.org>
PR 24985
gcc/
* diagnostic.h (show_caret): Declare.
(caret_max_width): Declare.
(diagnostic_show_locus): Declare.
* diagnostic.c (diagnostic_initialize): Initialize to false.
(diagnostic_show_locus): New.
(diagnostic_report_diagnostic): Call it.
(getenv_columns): New.
(adjust_line): New.
(diagnostic_set_caret_max_width): New.
* input.c (read_line): New.
(location_get_source_line): New.
* input.h (location_get_source_line): Declare.
* toplev.c (general_init): Initialize show_caret from options.
* dwarf2out.c (gen_producer_string): Handle fdiagnostics-show-caret.
* opts.c (common_handle_option): Likewise.
* pretty-print.h (pp_get_prefix): New.
(pp_base_get_prefix): New.
* common.opt (fdiagnostics-show-caret): New option.
* doc/invoke.texi (fdiagnostics-show-caret): Document it.
testsuite/
* lib/prune.exp: Add -fno-diagnostics-show-caret.
libstdc++-v3/
* testsuite/lib/prune.exp: Handle caret.
libmudflap/
* testsuite/lib/libmudflap.exp: Handle caret.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/common.opt
trunk/gcc/diagnostic.c
trunk/gcc/diagnostic.h
trunk/gcc/doc/invoke.texi
trunk/gcc/dwarf2out.c
trunk/gcc/input.c
trunk/gcc/input.h
trunk/gcc/opts.c
trunk/gcc/pretty-print.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/lib/prune.exp
trunk/gcc/toplev.c
trunk/libmudflap/ChangeLog
trunk/libmudflap/testsuite/lib/libmudflap.exp
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/lib/prune.exp
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (14 preceding siblings ...)
2012-04-11 9:28 ` manu at gcc dot gnu.org
@ 2012-04-11 9:53 ` manu at gcc dot gnu.org
2012-04-12 21:45 ` jason at gcc dot gnu.org
` (22 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-04-11 9:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #30 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-11 09:52:26 UTC ---
So we have caret diagnostics in GCC 4.8! :-) :-) :-)
In any case, I am leaving this open. There are some improvements that I still
would like to make before 4.8.0, and surely there will be some bugs found.
If you have specific improvements/bugs that you will love to see
implemented/fixed, please add them as blockers of this PR.
A few things I am NOT going to work on, but it would be great if someone
implemented them:
* Caching of file buffers: Since we often reopen+seek on the same file, a cache
of recently opened files would (probably) speed up things. However, I guess
that the OS has such cache, because at least in GNU/Linux, it feels fast
enough. So, I am not 100% sure how much this will save versus how much overhead
it will add.
* Handling wide chars, tabs, etc, according to GNU Coding Standards. There are
some bugs in libcpp about this, so those would need to be fixed first.
* Fixing DejaGNU so we can parse the caret lines conveniently. Fixing this will
also fix other long-standing testsuite bugs.
* Start/end location pairs for expressions so we can print a single expression
(or a range) instead of the whole source line. See A.1 and A.4 in
http://gcc.gnu.org/wiki/Better_Diagnostics
@Paolo,
I don't see any reason why your patch replacing %qE with %qT cannot go in now.
@Dodji
If -ftrack-macro-expansion becomes the default in 4.8, this will be an awesome
release!
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (15 preceding siblings ...)
2012-04-11 9:53 ` manu at gcc dot gnu.org
@ 2012-04-12 21:45 ` jason at gcc dot gnu.org
2012-04-12 21:59 ` manu at gcc dot gnu.org
` (21 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: jason at gcc dot gnu.org @ 2012-04-12 21:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #31 from Jason Merrill <jason at gcc dot gnu.org> 2012-04-12 21:44:23 UTC ---
The effect of this patch on overload resolution diagnostics is problematic:
-----
void f();
void f(int,int);
int main()
{
f(1);
}
-----
wa2.C: In function ‘int main()’:
wa2.C:6:6: error: no matching function for call to ‘f(int)’
f(1);
^
wa2.C:6:6: note: candidates are:
f(1);
^
wa2.C:1:6: note: void f()
void f();
^
wa2.C:1:6: note: candidate expects 0 arguments, 1 provided
void f();
^
wa2.C:2:6: note: void f(int, int)
void f(int,int);
^
wa2.C:2:6: note: candidate expects 2 arguments, 1 provided
void f(int,int);
^
When there are multiple diagnostics at the same input location, we should only
print the source/caret information once.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (16 preceding siblings ...)
2012-04-12 21:45 ` jason at gcc dot gnu.org
@ 2012-04-12 21:59 ` manu at gcc dot gnu.org
2012-04-13 2:26 ` paolo.carlini at oracle dot com
` (20 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-04-12 21:59 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #32 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-12 21:58:59 UTC ---
(In reply to comment #31)
> The effect of this patch on overload resolution diagnostics is problematic:
> wa2.C: In function ‘int main()’:
> wa2.C:6:6: error: no matching function for call to ‘f(int)’
> f(1);
> ^
> wa2.C:6:6: note: candidates are:
> f(1);
> ^
> wa2.C:1:6: note: void f()
> void f();
> ^
> wa2.C:1:6: note: candidate expects 0 arguments, 1 provided
> void f();
> ^
> wa2.C:2:6: note: void f(int, int)
> void f(int,int);
> ^
> wa2.C:2:6: note: candidate expects 2 arguments, 1 provided
> void f(int,int);
> ^
>
> When there are multiple diagnostics at the same input location, we should only
> print the source/caret information once.
True. Actually, in this case, perhaps we should print:
wa2.C:6:6: error: no matching function for call to ‘f(int)’
f(1);
^
note: candidates are:
wa2.C:1:6: note: candidate expects 0 arguments, 1 provided
void f();
^
wa2.C:2:6: note: candidate expects 2 arguments, 1 provided
void f(int,int);
^
no? Any other suggestions?
We could also print the %qD in the same line as:
wa2.C:6:6: error: no matching function for call to ‘f(int)’
f(1);
^
note: candidates are:
wa2.C:1:6: note: candidate 'void f()' expects 0 arguments, 1 provided
void f();
^
wa2.C:2:6: note: candidate 'void f(int, int)' expects 2 arguments, 1
provided
void f(int,int);
^
What do you think?
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (17 preceding siblings ...)
2012-04-12 21:59 ` manu at gcc dot gnu.org
@ 2012-04-13 2:26 ` paolo.carlini at oracle dot com
2012-04-13 9:57 ` rguenth at gcc dot gnu.org
` (19 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: paolo.carlini at oracle dot com @ 2012-04-13 2:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #33 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-04-13 02:25:48 UTC ---
Thanks Manu for the reminder, I have a couple of pending things in my TODO and
then I will resurrect it for the great 'caret times' ;)
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (18 preceding siblings ...)
2012-04-13 2:26 ` paolo.carlini at oracle dot com
@ 2012-04-13 9:57 ` rguenth at gcc dot gnu.org
2012-04-13 10:59 ` manu at gcc dot gnu.org
` (18 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-04-13 9:57 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #34 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-04-13 09:56:48 UTC ---
(In reply to comment #32)
> (In reply to comment #31)
> > The effect of this patch on overload resolution diagnostics is problematic:
> > wa2.C: In function ‘int main()’:
> > wa2.C:6:6: error: no matching function for call to ‘f(int)’
> > f(1);
> > ^
> > wa2.C:6:6: note: candidates are:
> > f(1);
> > ^
> > wa2.C:1:6: note: void f()
> > void f();
> > ^
> > wa2.C:1:6: note: candidate expects 0 arguments, 1 provided
> > void f();
> > ^
> > wa2.C:2:6: note: void f(int, int)
> > void f(int,int);
> > ^
> > wa2.C:2:6: note: candidate expects 2 arguments, 1 provided
> > void f(int,int);
> > ^
> >
> > When there are multiple diagnostics at the same input location, we should only
> > print the source/caret information once.
>
> True. Actually, in this case, perhaps we should print:
>
> wa2.C:6:6: error: no matching function for call to ‘f(int)’
> f(1);
> ^
> note: candidates are:
> wa2.C:1:6: note: candidate expects 0 arguments, 1 provided
> void f();
> ^
> wa2.C:2:6: note: candidate expects 2 arguments, 1 provided
> void f(int,int);
> ^
>
> no? Any other suggestions?
>
> We could also print the %qD in the same line as:
>
> wa2.C:6:6: error: no matching function for call to ‘f(int)’
> f(1);
> ^
> note: candidates are:
> wa2.C:1:6: note: candidate 'void f()' expects 0 arguments, 1 provided
> void f();
> ^
> wa2.C:2:6: note: candidate 'void f(int, int)' expects 2 arguments, 1
> provided
> void f(int,int);
> ^
>
> What do you think?
I think we should simply omit carets for all 'note's for now and add a
way for the callers to suppress carets. Though if you consider the testcase
changed to
void f(); void f(int,int);
int main()
{
f(1);
}
then suddenly the carets get more useful and the situation less clear:
t.C: In function 'int main()':
t.C:5:6: error: no matching function for call to 'f(int)'
f(1);
^
t.C:5:6: note: candidates are:
f(1);
^
t.C:1:6: note: void f()
void f(); void f(int,int);
^
t.C:1:6: note: candidate expects 0 arguments, 1 provided
void f(); void f(int,int);
^
t.C:1:17: note: void f(int, int)
void f(); void f(int,int);
^
t.C:1:17: note: candidate expects 2 arguments, 1 provided
void f(); void f(int,int);
^
btw, why do we print a location info for
t.C:5:6: note: candidates are:
f(1);
^
at all?
t.C:1:6: note: candidate expects 0 arguments, 1 provided
void f(); void f(int,int);
^
t.C:1:17: note: void f(int, int)
void f(); void f(int,int);
^
and the 2nd note here looks wrong.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (19 preceding siblings ...)
2012-04-13 9:57 ` rguenth at gcc dot gnu.org
@ 2012-04-13 10:59 ` manu at gcc dot gnu.org
2012-04-13 11:35 ` rguenth at gcc dot gnu.org
` (17 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-04-13 10:59 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #35 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-13 10:59:17 UTC ---
(In reply to comment #34)
>
> btw, why do we print a location info for
>
> t.C:5:6: note: candidates are:
> f(1);
> ^
>
> at all?
I am proposing to print just: "note: candidates are:", with enough leading
empty space to align with the previous error and no caret. Is that OK? Richard,
Jason?
>
> t.C:1:6: note: candidate expects 0 arguments, 1 provided
> void f(); void f(int,int);
> ^
> t.C:1:17: note: void f(int, int)
> void f(); void f(int,int);
> ^
>
> and the 2nd note here looks wrong.
Could you explain why?
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (20 preceding siblings ...)
2012-04-13 10:59 ` manu at gcc dot gnu.org
@ 2012-04-13 11:35 ` rguenth at gcc dot gnu.org
2012-04-13 11:52 ` redi at gcc dot gnu.org
` (16 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-04-13 11:35 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #36 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-04-13 11:34:04 UTC ---
(In reply to comment #35)
> (In reply to comment #34)
> >
> > btw, why do we print a location info for
> >
> > t.C:5:6: note: candidates are:
> > f(1);
> > ^
> >
> > at all?
>
> I am proposing to print just: "note: candidates are:", with enough leading
> empty space to align with the previous error and no caret. Is that OK? Richard,
> Jason?
Sounds good to me. But I think GNU conventions require a location here?
> >
> > t.C:1:6: note: candidate expects 0 arguments, 1 provided
> > void f(); void f(int,int);
> > ^
> > t.C:1:17: note: void f(int, int)
> > void f(); void f(int,int);
> > ^
> >
> > and the 2nd note here looks wrong.
>
> Could you explain why?
Because void f(int, int) is not of type "candidate expects 0 arguments" but
it is of expects two which is duplicate of the following
t.C:1:17: note: candidate expects 2 arguments, 1 provided
void f(); void f(int,int);
^
But that's of course a different bug.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (21 preceding siblings ...)
2012-04-13 11:35 ` rguenth at gcc dot gnu.org
@ 2012-04-13 11:52 ` redi at gcc dot gnu.org
2012-04-13 11:54 ` redi at gcc dot gnu.org
` (15 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: redi at gcc dot gnu.org @ 2012-04-13 11:52 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #37 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-13 11:50:33 UTC ---
I think for Richard's example a nice compromise would be:
t.C: In function 'int main()':
t.C:5:6: error: no matching function for call to 'f(int)'
f(1);
^
note: candidates are:
t.C:1:6: note: void f()
t.C:1:6: note: candidate expects 0 arguments, 1 provided
void f(); void f(int,int);
^
t.C:1:17: note: void f(int, int)
t.C:1:17: note: candidate expects 2 arguments, 1 provided
void f(); void f(int,int);
^
That includes all the relevant information but removes the duplication caused
by printing the same source code and caret after each pair of notes, and the
whitespace on the "candidates are" line instead of location info does help make
it look less cluttered. GCC diagnostics do tend to look more densely packed
than some other compilers. Caret diagnostics change that, but it's not
necessarily an improvement if they just space out every line with duplicated
snippets of source and carets.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (22 preceding siblings ...)
2012-04-13 11:52 ` redi at gcc dot gnu.org
@ 2012-04-13 11:54 ` redi at gcc dot gnu.org
2012-04-13 11:56 ` manu at gcc dot gnu.org
` (14 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: redi at gcc dot gnu.org @ 2012-04-13 11:54 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #38 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-13 11:53:31 UTC ---
(In reply to comment #36)
> > > t.C:1:6: note: candidate expects 0 arguments, 1 provided
> > > void f(); void f(int,int);
> > > ^
> > > t.C:1:17: note: void f(int, int)
> > > void f(); void f(int,int);
> > > ^
> > >
> > > and the 2nd note here looks wrong.
> >
> > Could you explain why?
>
> Because void f(int, int) is not of type "candidate expects 0 arguments" but
> it is of expects two which is duplicate of the following
>
> t.C:1:17: note: candidate expects 2 arguments, 1 provided
> void f(); void f(int,int);
> ^
You're confusing two separate notes.
This bit refers to the first overload, which expects 0 args:
t.C:1:6: note: candidate expects 0 arguments, 1 provided
void f(); void f(int,int);
^
And this bit refers to the second overload:
t.C:1:17: note: void f(int, int)
void f(); void f(int,int);
^
The line following says "expects 2 arguments"
This is why in my previous comment I suggested removing the caret diagnostic
between the related notes, so the notes that refer to the same thing are
adjacent.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (23 preceding siblings ...)
2012-04-13 11:54 ` redi at gcc dot gnu.org
@ 2012-04-13 11:56 ` manu at gcc dot gnu.org
2012-04-13 11:59 ` manu at gcc dot gnu.org
` (13 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-04-13 11:56 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #39 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-13 11:54:53 UTC ---
(In reply to comment #36)
> Sounds good to me. But I think GNU conventions require a location here?
Well, if that is a hard requirement, I can just suppress the caret. Or we can
just not print the "note: candidates are:". It seems superfluous info to me.
> > > t.C:1:6: note: candidate expects 0 arguments, 1 provided
> > > void f(); void f(int,int);
> > > ^
> > > t.C:1:17: note: void f(int, int)
> > > void f(); void f(int,int);
> > > ^
> > >
> > > and the 2nd note here looks wrong.
> >
> > Could you explain why?
>
> Because void f(int, int) is not of type "candidate expects 0 arguments" but
> it is of expects two which is duplicate of the following
>
> t.C:1:17: note: candidate expects 2 arguments, 1 provided
> void f(); void f(int,int);
> ^
>
> But that's of course a different bug.
I see. The problem is that the output is meant to be read as (locations and
duplicated carets removed for clarity):
note: candidates are:
note: candidate #1 is void f()
void f(); void f(int,int);
^
note: candidate #1 expects 0 arguments, 1 provided
note: candidate #2 is void f(int, int)
void f(); void f(int,int);
^
note: candidate #2 expects 2 arguments, 1 provided
that is, first print the candidate, then the reason for failure. If you read
again the original, the 2nd and 3rd notes go together, like the 4th and 5th, so
the output is correct (although I agree that quite confusing). That is why I
proposed:
note: candidate 'void f()' expects 0 arguments, 1 provided
void f(); void f(int,int);
^
note: candidate 'void f(int, int)' expects 2 arguments, 1 provided
void f(); void f(int,int);
^
(that is, instead of two notes per candidate, just one). Or we could number the
candidates like above.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (24 preceding siblings ...)
2012-04-13 11:56 ` manu at gcc dot gnu.org
@ 2012-04-13 11:59 ` manu at gcc dot gnu.org
2012-04-13 12:09 ` redi at gcc dot gnu.org
` (12 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-04-13 11:59 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #40 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-13 11:58:04 UTC ---
I think what Jonathan proposed in comment #37 is also nice. If Jason approves,
I will implement it.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (25 preceding siblings ...)
2012-04-13 11:59 ` manu at gcc dot gnu.org
@ 2012-04-13 12:09 ` redi at gcc dot gnu.org
2012-04-13 12:09 ` rguenth at gcc dot gnu.org
` (11 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: redi at gcc dot gnu.org @ 2012-04-13 12:09 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #41 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-13 12:07:01 UTC ---
(In reply to comment #39)
> just not print the "note: candidates are:". It seems superfluous info to me.
Personally I like the "candidates are" line, I don't find it superfluous.
If there are two erroneous calls:
f(1);
f(2);
the "candidates are" notes help break up the errors and help me parse them. In
real code these lines might be very long and wrap on the screen:
t.cc:1:6: note: void f()
t.cc:1:6: note: candidate expects 0 arguments, 1 provided
The short, concise "candidates are" line is easy for me to locate quickly and
start scanning down the list from there, especially when there is more than one
error in the code.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (26 preceding siblings ...)
2012-04-13 12:09 ` redi at gcc dot gnu.org
@ 2012-04-13 12:09 ` rguenth at gcc dot gnu.org
2012-04-13 12:16 ` manu at gcc dot gnu.org
` (10 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: rguenth at gcc dot gnu.org @ 2012-04-13 12:09 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #42 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-04-13 12:08:02 UTC ---
(In reply to comment #40)
> I think what Jonathan proposed in comment #37 is also nice. If Jason approves,
> I will implement it.
Yes, I like that, too. For reference, the following:
note: candidate 'void f()' expects 0 arguments, 1 provided
void f(); void f(int,int);
^
note: candidate 'void f(int, int)' expects 2 arguments, 1 provided
void f(); void f(int,int);
^
I'll approve a patch that implements this.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (27 preceding siblings ...)
2012-04-13 12:09 ` rguenth at gcc dot gnu.org
@ 2012-04-13 12:16 ` manu at gcc dot gnu.org
2012-04-13 12:19 ` manu at gcc dot gnu.org
` (9 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-04-13 12:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #43 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-13 12:15:45 UTC ---
(In reply to comment #42)
> (In reply to comment #40)
> > I think what Jonathan proposed in comment #37 is also nice. If Jason approves,
> > I will implement it.
>
> Yes, I like that, too. For reference, the following:
>
> note: candidate 'void f()' expects 0 arguments, 1 provided
> void f(); void f(int,int);
> ^
> note: candidate 'void f(int, int)' expects 2 arguments, 1 provided
> void f(); void f(int,int);
> ^
To avoid confusion, that was not what Jonathan proposed in comment #37.
> I'll approve a patch that implements this.
With all due respect, since this is a C++ FE issue, I'll still wait for Jason's
opinion before implementing anything. I still appreciate yours (or anyone else)
comments. Thanks.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (28 preceding siblings ...)
2012-04-13 12:16 ` manu at gcc dot gnu.org
@ 2012-04-13 12:19 ` manu at gcc dot gnu.org
2012-04-13 12:24 ` redi at gcc dot gnu.org
` (8 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-04-13 12:19 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #44 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-13 12:18:35 UTC ---
(In reply to comment #41)
> (In reply to comment #39)
> > just not print the "note: candidates are:". It seems superfluous info to me.
>
> Personally I like the "candidates are" line, I don't find it superfluous.
OK, I don't have a strong opinion on this. Let's Jason decide.
You seem to agree with me on removing the duplicated location in front of it,
per comment #37, am I right?
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (29 preceding siblings ...)
2012-04-13 12:19 ` manu at gcc dot gnu.org
@ 2012-04-13 12:24 ` redi at gcc dot gnu.org
2012-04-13 12:32 ` manu at gcc dot gnu.org
` (7 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: redi at gcc dot gnu.org @ 2012-04-13 12:24 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #45 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-13 12:24:30 UTC ---
(In reply to comment #42)
> Yes, I like that, too. For reference, the following:
>
> note: candidate 'void f()' expects 0 arguments, 1 provided
> void f(); void f(int,int);
> ^
> note: candidate 'void f(int, int)' expects 2 arguments, 1 provided
> void f(); void f(int,int);
> ^
I like this for this example, but does it work as well if the function name is
very long, and the "expects 2 arguments, 1 provided" is no longer in a
predictable position, but pushed off to the right of a very long line?
t.cc: In function 'int main()':
t.cc:10:25: error: no matching function for call to 'a_long_function_name(int)'
t.cc:10:25: note: candidates are:
t.cc:5:6: note: void a_long_function_name()
t.cc:5:6: note: candidate expects 0 arguments, 1 provided
t.cc:6:6: note: void a_long_function_name(something_verbose::my_very_long_type,
something_verbose::my_very_long_type)
t.cc:6:6: note: candidate expects 2 arguments, 1 provided
would become
t.cc: In function 'int main()':
t.cc:10:25: error: no matching function for call to 'a_long_function_name(int)'
a_long_function_name(1);
^
t.cc:10:25: note: candidates are:
t.cc:5:6: note: candidate 'void a_long_function_name()' expects 0 arguments,
1 provided
void a_long_function_name();
^
t.cc:6:6: note: candidate 'void
a_long_function_name(something_verbose::my_very_long_type,
something_verbose::my_very_long_type)' expects 2 arguments, 1 provided
void a_long_function_name(something_verbose::my_very_long_type,
something_verbose::my_very_long_type);
^
(we do already have this problem when printing ridiculous paths for stdlib
headers with superfluous lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../..
rubbish in them, is there an existing bug for that?)
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (30 preceding siblings ...)
2012-04-13 12:24 ` redi at gcc dot gnu.org
@ 2012-04-13 12:32 ` manu at gcc dot gnu.org
2012-04-13 19:06 ` jason at gcc dot gnu.org
` (6 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-04-13 12:32 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #46 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-13 12:31:41 UTC ---
(In reply to comment #45)
> (In reply to comment #42)
> > Yes, I like that, too. For reference, the following:
> >
> > note: candidate 'void f()' expects 0 arguments, 1 provided
> > void f(); void f(int,int);
> > ^
> > note: candidate 'void f(int, int)' expects 2 arguments, 1 provided
> > void f(); void f(int,int);
> > ^
>
> I like this for this example, but does it work as well if the function name is
> very long, and the "expects 2 arguments, 1 provided" is no longer in a
> predictable position, but pushed off to the right of a very long line?
I see your point, I am convinced.
> (we do already have this problem when printing ridiculous paths for stdlib
> headers with superfluous lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../..
> rubbish in them, is there an existing bug for that?)
Please open one with a reproducible testcase and I will take a look. This is
very annoying to me as well, and there should be a way to make these paths
shorter.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (31 preceding siblings ...)
2012-04-13 12:32 ` manu at gcc dot gnu.org
@ 2012-04-13 19:06 ` jason at gcc dot gnu.org
2012-04-13 19:41 ` manu at gcc dot gnu.org
` (5 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: jason at gcc dot gnu.org @ 2012-04-13 19:06 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #47 from Jason Merrill <jason at gcc dot gnu.org> 2012-04-13 19:04:50 UTC ---
Jonathan's proposed output looks fine to me. The "candidates are" note had a
source location for the sake of dejagnu, but we can deal with that by adjusting
the prune.exp note handling.
But I also want a general solution to the issue of multiple diagnostics with
the same source location; overload resolution isn't the only example.
I think suppressing the caret by default for notes makes sense.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (32 preceding siblings ...)
2012-04-13 19:06 ` jason at gcc dot gnu.org
@ 2012-04-13 19:41 ` manu at gcc dot gnu.org
2012-04-13 22:59 ` manu at gcc dot gnu.org
` (4 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-04-13 19:41 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #48 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-13 19:40:53 UTC ---
(In reply to comment #47)
> Jonathan's proposed output looks fine to me. The "candidates are" note had a
> source location for the sake of dejagnu, but we can deal with that by adjusting
> the prune.exp note handling.
OK, so I will do that.
> But I also want a general solution to the issue of multiple diagnostics with
> the same source location; overload resolution isn't the only example.
Yes, we should disable the caret if the last caret printed was at the same
location.
> I think suppressing the caret by default for notes makes sense.
There are a lot of notes that give useful info with carets. Like "declared
here". And notes are used for macro expansion. Anyway, I will have to add some
kind of inform_without_locus("") to implement the above, so if we decide to
switch all notes to use it, the implementation will be ready.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (33 preceding siblings ...)
2012-04-13 19:41 ` manu at gcc dot gnu.org
@ 2012-04-13 22:59 ` manu at gcc dot gnu.org
2012-04-14 10:54 ` manu at gcc dot gnu.org
` (3 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-04-13 22:59 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #27089|0 |1
is obsolete| |
Attachment #27093|0 |1
is obsolete| |
--- Comment #49 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-13 22:59:12 UTC ---
Created attachment 27155
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27155
fix overload carets
The patch that I am currently bootstrapping. I made a small change to the
output. It looks like this now:
caret-overload.C:102:6: error: no matching function for call to ‘f(int)’
f(1);
^
note: candidates are:
caret-overload.C:1:6: note: void f()
note: candidate expects 0 arguments, 1 provided
void f();
^
caret-overload.C:10:6: note: void f(int, int)
note: candidate expects 2 arguments, 1 provided
void f(int,int);
^
But if you don't like it, I can switch off the DI_HIDE_PREFIX for the failure
reason. Note that the notes without prefix will be perfectly aligned with the
previous message.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (34 preceding siblings ...)
2012-04-13 22:59 ` manu at gcc dot gnu.org
@ 2012-04-14 10:54 ` manu at gcc dot gnu.org
2012-04-22 16:36 ` manu at gcc dot gnu.org
` (2 subsequent siblings)
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-04-14 10:54 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #50 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-14 10:53:25 UTC ---
(In reply to comment #49)
> Created attachment 27155 [details]
> fix overload carets
>
> The patch that I am currently bootstrapping. I made a small change to the
> output. It looks like this now:
It bootstraps but, of course, there are a lot of failures. This one:
> note: candidates are:
I can remove in prune.exp but this:
> note: candidate expects 0 arguments, 1 provided
We probably want to match in messages. I am pretty sure there is a way to add a
new { dg-notes-2 "note1" "note2" } which passes a regexp such as
"[^\n]*note1[^\n]*\n[^\n]*note2[^\n]*" to process-message, but my Tcl foo is
not strong enough.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (35 preceding siblings ...)
2012-04-14 10:54 ` manu at gcc dot gnu.org
@ 2012-04-22 16:36 ` manu at gcc dot gnu.org
2012-05-04 0:33 ` manu at gcc dot gnu.org
2012-05-13 22:38 ` manu at gcc dot gnu.org
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-04-22 16:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #51 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-22 16:35:34 UTC ---
BTW, if you have more examples where printing the caret seems unnecessary,
please open PRs and add me to the CC. I will try to deal with them and
hopefully the caret will stay enabled by default for GCC 4.8.
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (36 preceding siblings ...)
2012-04-22 16:36 ` manu at gcc dot gnu.org
@ 2012-05-04 0:33 ` manu at gcc dot gnu.org
2012-05-13 22:38 ` manu at gcc dot gnu.org
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-05-04 0:33 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #52 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-05-04 00:31:58 UTC ---
Author: manu
Date: Fri May 4 00:31:55 2012
New Revision: 187134
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187134
Log:
2012-05-04 Manuel López-Ibáñez <manu@gcc.gnu.org>
PR c++/24985
gcc/
* tree-diagnostic.c (maybe_unwind_expanded_macro_loc): Show caret
for macro expansion.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-diagnostic.c
^ permalink raw reply [flat|nested] 54+ messages in thread* [Bug c++/24985] caret diagnostics
[not found] <bug-24985-4@http.gcc.gnu.org/bugzilla/>
` (37 preceding siblings ...)
2012-05-04 0:33 ` manu at gcc dot gnu.org
@ 2012-05-13 22:38 ` manu at gcc dot gnu.org
38 siblings, 0 replies; 54+ messages in thread
From: manu at gcc dot gnu.org @ 2012-05-13 22:38 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #53 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-05-13 22:32:19 UTC ---
Well, I would consider this fixed in 4.8. Specific caret issues should have
their own PRs.
^ permalink raw reply [flat|nested] 54+ messages in thread