http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #42 from Jonathan Wakely 2012-04-16
15:47:37 UTC ---
Awesome, thank you very very much, Paolo and Manu.
The example in comment 23 can now be added to
http://gcc.gnu.org/wiki/ClangDiagnosticsComparison ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #40 from paolo at gcc dot gnu.org
2012-04-16 15:32:28 UTC ---
Author: paolo
Date: Mon Apr 16 15:32:22 2012
New Revision: 186499
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186499
Log:
/cp
2012-04-16 Paolo Carlini
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Manuel López-Ibáñez changed:
What|Removed |Added
Depends on||24985
--- Comment #39 from Manuel L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #38 from Andrew Pinski 2012-04-03
03:41:00 UTC ---
(In reply to comment #37)
> Actually, it's not clear to me that the caret line would be likely to cause
> trouble for IDEs in any case; they already have to deal with output that isn'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #37 from Jason Merrill 2012-04-02
22:05:13 UTC ---
(In reply to comment #36)
> I know some of us use tee and that disables termainal detection code usually.
Right, so then you don't get the caret by default. You can still enable it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #36 from pinskia at gmail dot com
2012-04-02 17:35:59 UTC ---
I know some of us use tee and that disables termainal detection code usually.
Or output to a file and then use tail -f. So please don't do that. It would
confuse lots of us
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #35 from Manuel López-Ibáñez 2012-04-02
17:19:15 UTC ---
(In reply to comment #34)
> (In reply to comment #32)
> >
> > Of course this may fail in some cases, like non-ANSI input, and not
> > preprocessing, but it will work in 99% of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #34 from Manuel López-Ibáñez 2012-04-02
17:18:34 UTC ---
(In reply to comment #32)
>
> Of course this may fail in some cases, like non-ANSI input, and not
> preprocessing, but it will work in 99% of the cases. In any case, it is not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #33 from Manuel López-Ibáñez 2012-04-02
17:15:47 UTC ---
(In reply to comment #32)
> (In reply to comment #31)
> > Well, that is reassuring. Then, will we still pretty-print expressions in
> > diagnostics once we have the caret?
>
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #32 from Jason Merrill 2012-04-02
15:57:16 UTC ---
(In reply to comment #31)
> Well, that is reassuring. Then, will we still pretty-print expressions in
> diagnostics once we have the caret?
No, there should be no need to.
> Is ther
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #31 from Manuel López-Ibáñez 2012-04-02
08:16:52 UTC ---
(In reply to comment #30)
> (In reply to comment #26)
> > The caret is not a solution to this problem, because what Gabriel wants is
> > to
> > not reconstruct expressions ONLY
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #30 from Jason Merrill 2012-04-02
05:16:05 UTC ---
(In reply to comment #26)
> The caret is not a solution to this problem, because what Gabriel wants is to
> not reconstruct expressions ONLY when the caret is shown, but he has said i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #28 from Manuel López-Ibáñez 2012-04-01
13:23:01 UTC ---
(In reply to comment #27)
> (In reply to comment #26)
> > because if you want nice diagnostics, why don't just use
> > Clang?
>
> Because G++ gives much better diagnostics for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #27 from Jonathan Wakely 2012-04-01
12:55:34 UTC ---
(In reply to comment #26)
> because if you want nice diagnostics, why don't just use
> Clang?
Because G++ gives much better diagnostics for template argument deduction
failures, so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #26 from Manuel López-Ibáñez 2012-04-01
11:24:14 UTC ---
(In reply to comment #24)
> Personally, I don't believe Gaby is open to other solutions outside the
> full-fledged "caret diagnostics" context, thus for the time being at least
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #25 from Paolo Carlini 2012-03-31
02:15:19 UTC ---
And, hey, I'm of course speaking only for myself, you are welcome to pursue a
compromise solution. For example, I don't know, if we could identify a
*restricted* class of expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #24 from Paolo Carlini 2012-03-31
02:03:02 UTC ---
Personally, I don't believe Gaby is open to other solutions outside the
full-fledged "caret diagnostics" context, thus for the time being at least I'm
personally going to stand to his
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #23 from Manuel López-Ibáñez 2012-03-31
00:34:58 UTC ---
BTW, I think this example was mentioned some where already, but I cannot find
it now. From http://clang.llvm.org/diagnostics.html
manuel@gcc12:~$ cat t.cc
struct a {
virtual
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #22 from Manuel López-Ibáñez 2012-03-31
00:25:50 UTC ---
Is there a final verdict on this? Jonathan, Paolo, did you change your mind?
Or do you still think this should be fixed but you don't believe there is any
hope to get your pat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Manuel López-Ibáñez changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #20 from Ralph Loader 2012-03-23
07:54:51 UTC ---
Re comment 12 - as someone who regularly needs to understand gcc diagnostics, I
disagree completely.
Understanding a failure to look something up, the single most important thing
to k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #19 from Jonathan Wakely 2012-03-22
14:27:11 UTC ---
(In reply to comment #18)
> But that is not correct: '&' might be overloaded for the type in question...]
If the diagnostics were improved for all types except for those with over
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #18 from Ralph Loader 2012-03-22
14:21:33 UTC ---
Flaws from the pretty-printing not listed in this bug (from 25362):
It takes the address of integer constants.
The pretty printing confuses '.' and '->' [this has changed slightly si
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #17 from Manuel López-Ibáñez 2012-03-22
12:59:30 UTC ---
(In reply to comment #16)
> Right, we have the column numbers to indicate the position in the source
> (not perfect, but enough to show which sub-expression the error refers to)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #16 from Jonathan Wakely 2012-03-22
12:01:58 UTC ---
Right, we have the column numbers to indicate the position in the source
(not perfect, but enough to show which sub-expression the error refers to)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #15 from Manuel López-Ibáñez 2012-03-22
11:37:17 UTC ---
(In reply to comment #13)
> Please don't close this as a dup of the caret diagnostics PR.
>
> I agree there's no consensus on what should be done, but printing of
I only know
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #14 from Jonathan Wakely 2012-03-22
11:17:36 UTC ---
Also, comment 2 shows another clear bug in the current diagnostics. It doesn't
matter whether you prefer carets or types or reconstructed expressions,
printing x[1] as *(x + 4u) is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #13 from Jonathan Wakely 2012-03-22
11:02:29 UTC ---
Please don't close this as a dup of the caret diagnostics PR.
I agree there's no consensus on what should be done, but printing of
reconstructed expressions is utterly awful. I th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #12 from Paolo Carlini 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Manuel López-Ibáñez changed:
What|Removed |Added
CC||suckfish at ihug dot co.nz
--- Comm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #8 from Christopher Yeleighton
2011-09-27 22:23:34 UTC ---
> I agree that this would be an improvement, even without clang's selective
> typedef unwrapping. But I have some doubts such a patch will be accepted. I
> was
> told in a co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #7 from Manuel López-Ibáñez 2011-09-21
23:56:25 UTC ---
(In reply to comment #6)
> Thanks, Manu. Most of the PRs mentioned on that page are FIXED, and I don't
PR 35441 is still broken. In any case, most of the fixes just gave up on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #6 from Jonathan Wakely 2011-09-21
23:30:34 UTC ---
Thanks, Manu. Most of the PRs mentioned on that page are FIXED, and I don't
see specific mention of outputting the types involved in the operation, just
better way of outputting the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #4 from Jonathan Wakely 2011-09-21
21:03:37 UTC ---
The common thing in my original example and comment 2 is that when printing "no
match" for a binary operator, the diagnostic machinery tries to "reconstruct"
the left operand, but pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #3 from Jonathan Wakely 2011-09-21
20:16:24 UTC ---
Wow, that one is worthy of its own bug report, it's not just an unclear
diagnostic, it's completely bogus.
x[01] is *(x+1) or *((char*)x + 4) but what G++ prints is just wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #2 from Christopher Yeleighton
2011-09-21 20:06:42 UTC ---
== Code ==
struct X { int x; };
void trigger (X x []) { x [01] = 0; }
== Result (v4.6) ==
doit.cpp:2:34: error: no match for ‘operator=’ in ‘*(x + 4u) = 0’
But who refere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
Christopher Yeleighton changed:
What|Removed |Added
CC||giecrilj at stegny dot
42 matches
Mail list logo
