Re: Updated GCC vs Clang diagnostics

Re: Updated GCC vs Clang diagnostics

[Manuel López-Ibáñez]

Hi Jonathan,

I think the wiki page is a great idea! Thanks for doing this.

I am planning to open PRs for all the issues where GCC is worse. I
think it would be nice to have even more examples where GCC is better.
Examples where GCC is worse can be added to
http://gcc.gnu.org/wiki/Better_Diagnostics

About automatic macro expansion, actually Clang does not expand
macros, they simply track macro locations. GCC can do this right now
with -ftrack-macro-expansion, which hopefully will be enabled by
default in GCC 4.8 thanks to Dodji's work. And I have a very simple
patch that shows the caret for those macro expansions, so the output
is the same (except colors and ranges).

Then, there are three obvious differences between GCC's and Clang's
diagnostics shown int that page: color, ranges and fix-it hints.

* The diagnostics support to print a range given two locations is
trivial to implement. However, modifying the location machinery so it
tracks ranges seems much more complex (and deciding which range to
choose in each diagnostic is a lot of work, because there are a lot of
diagnostics).

* Implementing color is trivial and there are reference
implementations in GNU grep and GNU make. It would be much more
reliable than parsing the output of GCC. Specially with caret
diagnostics.

* Fix-it hints would also be quite trivial to implement, but it would
be a lot of work to decide which diagnostics should use it, and how.

Of course, the major question is: Are the decision makers in GCC
interested on any of this?

Would some reviewer reject patches implementing them?

Are there any conditions attached to the implementation that would be
good to know beforehand?

Cheers,

Manuel.

Re: Updated GCC vs Clang diagnostics

[Gabriel Dos Reis]

On Thu, Apr 12, 2012 at 4:49 PM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> Hi Jonathan,
>[....]
> Of course, the major question is: Are the decision makers in GCC
> interested on any of this?
>
> Would some reviewer reject patches implementing them?

I suspect decisions will be based on the implementations themselves.

> Are there any conditions attached to the implementation that would be
> good to know beforehand?

The devils are in the details.

-- Gaby

Re: Updated GCC vs Clang diagnostics

[Manuel López-Ibáñez]

On 12 April 2012 23:54, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> On Thu, Apr 12, 2012 at 4:49 PM, Manuel López-Ibáñez
> <lopezibanez@gmail.com> wrote:
>> Hi Jonathan,
>>[....]
>> Of course, the major question is: Are the decision makers in GCC
>> interested on any of this?
>>
>> Would some reviewer reject patches implementing them?
>
> I suspect decisions will be based on the implementations themselves.
>

So given your ideal implementation, if the user-visible result was
exactly like the one in Clang, will you be happy with any of the three
things: ranges, color and fix-it hints?

Or you will prefer to never have some of them or to have them disabled
by default?

Or to have them, but in a different (user-visible) manner?

Cheers,

Manuel.

Re: Updated GCC vs Clang diagnostics

[Gabriel Dos Reis]

On Thu, Apr 12, 2012 at 5:05 PM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> On 12 April 2012 23:54, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
>> On Thu, Apr 12, 2012 at 4:49 PM, Manuel López-Ibáñez
>> <lopezibanez@gmail.com> wrote:
>>> Hi Jonathan,
>>>[....]
>>> Of course, the major question is: Are the decision makers in GCC
>>> interested on any of this?
>>>
>>> Would some reviewer reject patches implementing them?
>>
>> I suspect decisions will be based on the implementations themselves.
>>
>
> So given your ideal implementation, if the user-visible result was
> exactly like the one in Clang, will you be happy with any of the three
> things: ranges, color and fix-it hints?

My ideal isn't to replicate Clang :-)

I would like us to set a standard that Clang would have to follow :-)
There are several things that need to be considered.
The three items above are choices in the toolset.  Ideally, I would
like to have a mechanism where the output could be configured
(through a command line switch, etc) that allows for example IDEs
(not just GNU Emacs) to hook into databases of advices, standard
definitions, etc.  Even for our own testsuites, this might be useful
instead of the current one-dimensional char sequence
oriented diagnostic testing.


>
> Or you will prefer to never have some of them or to have them disabled
> by default?
>
> Or to have them, but in a different (user-visible) manner?

I suspect to some degree this is closer to I would like to see, but again,
I would prefer to make a judgment based on an implementation.

-- Gaby

Re: Updated GCC vs Clang diagnostics

[Lawrence Crowl]

On 4/12/12, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote:
> So given your ideal implementation, if the user-visible result
> was exactly like the one in Clang, will you be happy with any of
> the three things: ranges, color and fix-it hints?

There are many issues with color.  Does your reader have any
color deficiencies?  Does your software address them?  Does the
system software render colors well?  Is color contrast sufficient?
Is greyscale contrast sufficient?  Color is low on my list of
desirables.

> Or you will prefer to never have some of them or to have them
> disabled by default?

The first thing I do is turn off colors in /bin/ls because there
are actually too few readable color combinations to be very usable.
So, I want to have the ability to turn warning colors off.

> Or to have them, but in a different (user-visible) manner?

This question is hard to answer because I don't know all manners.

-- 
Lawrence Crowl

Re: Updated GCC vs Clang diagnostics

[Manuel López-Ibáñez]

On 13 April 2012 00:17, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> On Thu, Apr 12, 2012 at 5:05 PM, Manuel López-Ibáñez
> <lopezibanez@gmail.com> wrote:
>> On 12 April 2012 23:54, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
>>> On Thu, Apr 12, 2012 at 4:49 PM, Manuel López-Ibáñez
>>> <lopezibanez@gmail.com> wrote:
>>>> Hi Jonathan,
>>>>[....]
>>>> Of course, the major question is: Are the decision makers in GCC
>>>> interested on any of this?
>>>>
>>>> Would some reviewer reject patches implementing them?
>>>
>>> I suspect decisions will be based on the implementations themselves.
>>>
>>
>> So given your ideal implementation, if the user-visible result was
>> exactly like the one in Clang, will you be happy with any of the three
>> things: ranges, color and fix-it hints?
>
> My ideal isn't to replicate Clang :-)
>
> I would like us to set a standard that Clang would have to follow :-)
> There are several things that need to be considered.
> The three items above are choices in the toolset.  Ideally, I would
> like to have a mechanism where the output could be configured
> (through a command line switch, etc) that allows for example IDEs
> (not just GNU Emacs) to hook into databases of advices, standard
> definitions, etc.  Even for our own testsuites, this might be useful
> instead of the current one-dimensional char sequence
> oriented diagnostic testing.

That sounds nice. Are you working on this on a branch? I hope you
manage to finish it for GCC 4.8.

I would like to have color output. And since nobody is paying me to do
this work, I'd rather work on what I would like to have. The question
is whether this is something that GCC wants to have.

If the answer is NO, that is fine, I will have more free time.

If the answer is yes but the implementation has to autodetect low
contrast settings / read colors from a configuration file / allow
users to input colors in their own language, then thanks but no
thanks, I'll choose my free time.

If it is ok that the implementation works like grep's, then I may try
to find some free time to give it a try, since the probability that
some new contributor will implement it instead of just using Clang
gets closer to zero as time goes by.

Cheers,

Manuel.

Re: Updated GCC vs Clang diagnostics

[Joe Buck]

On Fri, Apr 13, 2012 at 12:42:19AM +0200, Manuel López-Ibáñez wrote:
> I would like to have color output. And since nobody is paying me to do
> this work, I'd rather work on what I would like to have. The question
> is whether this is something that GCC wants to have.
>
> If the answer is NO, that is fine, I will have more free time.

I'm not interested in color output, and would turn it off if it were
implemented (the escape sequences would just mess things up when capturing
compiler output in log files).

Clang is much smarter about identifying what the user probably meant when
the issue is a typo, or "." instead of "->" or vice versa.  Getting GCC to
do at least as well in this area is a much better use of developers' time
than presenting a cascade of unintelligible messages resulting from
template expansion in full color.

That said, you're free to work on what interests you.

Re: Updated GCC vs Clang diagnostics

[Manuel López-Ibáñez]

On 13 April 2012 03:40, Joe Buck <Joe.Buck@synopsys.com> wrote:
> On Fri, Apr 13, 2012 at 12:42:19AM +0200, Manuel López-Ibáñez wrote:
>> I would like to have color output. And since nobody is paying me to do
>> this work, I'd rather work on what I would like to have. The question
>> is whether this is something that GCC wants to have.
>>
>> If the answer is NO, that is fine, I will have more free time.
>
> I'm not interested in color output, and would turn it off if it were
> implemented (the escape sequences would just mess things up when capturing
> compiler output in log files).

My proposal is to follow grep, that is, --color=[never|auto|always].
With auto, color would only be printed when isatty() is true. The
default could be auto, or never if some people are very much against
it.

> Clang is much smarter about identifying what the user probably meant when
> the issue is a typo, or "." instead of "->" or vice versa.  Getting GCC to
> do at least as well in this area is a much better use of developers' time
> than presenting a cascade of unintelligible messages resulting from
> template expansion in full color.
>
> That said, you're free to work on what interests you.

Yes, there is plenty of things that could be fixed in GCC. And I have
fixed my fair share of bugs that don't actually affect me at all, for
free, on my free time.

I find the color output of Clang just beautiful and, in my opinion,
color support in GCC would make it a bit more beautiful and attract
new users, so it is a much better use of developer's time than fixing
yet another obscure diagnostic issue that only triggers with a careful
ad-hoc example. That said, I do really think you are free to work on
what interests you, so I hope to see your patches fixing diagnostics
issues soon.

Cheers,

Manuel.

Re: Updated GCC vs Clang diagnostics

[Gabriel Dos Reis]

On Thu, Apr 12, 2012 at 9:26 PM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:

> I find the color output of Clang just beautiful and, in my opinion,
> color support in GCC would make it a bit more beautiful and attract
> new users, so it is a much better use of developer's time than fixing
> yet another obscure diagnostic issue that only triggers with a careful
> ad-hoc example. That said, I do really think you are free to work on
> what interests you, so I hope to see your patches fixing diagnostics
> issues soon.

Is this the kind of protracted passive-aggressive opinion you were looking for?

-- Gaby

Re: Updated GCC vs Clang diagnostics

[Ian Lance Taylor]

Lawrence Crowl <crowl@google.com> writes:

> On 4/12/12, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote:
>> So given your ideal implementation, if the user-visible result
>> was exactly like the one in Clang, will you be happy with any of
>> the three things: ranges, color and fix-it hints?
>
> There are many issues with color.  Does your reader have any
> color deficiencies?  Does your software address them?  Does the
> system software render colors well?  Is color contrast sufficient?
> Is greyscale contrast sufficient?  Color is low on my list of
> desirables.

It would be terrible if an error message could not be understood without
color.  But nobody is suggesting that.

The question at hand is whether color can be used to enhance an error
message that can be understood without color.  For example, whether
color can be added to current error messages without any other changes.

I personally think it would be an excellent idea.  Even clang's C++
error messages can be long.  A simple use of color is an excellent way
to draw the eye to the more important parts of the message.  If the
color is not available, then it doesn't help, but the error message can
be understood without it.

Ian

Re: Updated GCC vs Clang diagnostics

[Gabriel Dos Reis]

On Fri, Apr 13, 2012 at 12:11 AM, Ian Lance Taylor <iant@google.com> wrote:

> I personally think it would be an excellent idea.  Even clang's C++
> error messages can be long.  A simple use of color is an excellent way
> to draw the eye to the more important parts of the message.  If the
> color is not available, then it doesn't help, but the error message can
> be understood without it.

I would expect that an implementation in this  direction would transform

     error ("there is no operator %E with arguments %T and %T", foo, bar, baz)

into an internal IL rich enough to represent formatting directives
(and "2D" representation) independent of the actual rendering device's
capabilities.
It would then be up to each output device to display the diagnostics based on
their own characteristics (color or not, caret or not, pointing the cursor back
to the source file or not).  And indeed, it would be really terrible idea if the
intelligibility of a diagnostic -requires- colors.

-- Gaby

Re: Updated GCC vs Clang diagnostics

[Jakub Jelinek]

On Thu, Apr 12, 2012 at 10:11:48PM -0700, Ian Lance Taylor wrote:
> Lawrence Crowl <crowl@google.com> writes:
> 
> > On 4/12/12, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote:
> >> So given your ideal implementation, if the user-visible result
> >> was exactly like the one in Clang, will you be happy with any of
> >> the three things: ranges, color and fix-it hints?
> >
> > There are many issues with color.  Does your reader have any
> > color deficiencies?  Does your software address them?  Does the
> > system software render colors well?  Is color contrast sufficient?
> > Is greyscale contrast sufficient?  Color is low on my list of
> > desirables.
> 
> It would be terrible if an error message could not be understood without
> color.  But nobody is suggesting that.
> 
> The question at hand is whether color can be used to enhance an error
> message that can be understood without color.  For example, whether
> color can be added to current error messages without any other changes.
> 
> I personally think it would be an excellent idea.  Even clang's C++
> error messages can be long.  A simple use of color is an excellent way
> to draw the eye to the more important parts of the message.  If the
> color is not available, then it doesn't help, but the error message can
> be understood without it.

Yeah, I second this.  As Manuel said, we should have an option to select
never/auto/always coloring, colors must be just visual enhancements of the
diagnostics that even when colors are disabled gives all the info that
is needed (highlight error/warning/note diagnostic kind keywords, keywords
in the source, perhaps types, whatever), we should limit to a very small
set of colors, because not so many colors are actually very readable and
perhaps make the color sets configurable somehow (things might be different
if people use normally black characters on white background or white
characters on black background, grep has GREP_COLORS env var here, ls
LS_COLORS).

	Jakub

Re: Updated GCC vs Clang diagnostics

[Gabriel Dos Reis]

On Fri, Apr 13, 2012 at 1:03 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>  we should limit to a very small
> set of colors, because not so many colors are actually very readable and
> perhaps make the color sets configurable somehow (things might be different
> if people use normally black characters on white background or white
> characters on black background, grep has GREP_COLORS env var here, ls
> LS_COLORS).

I would certainly expect the set of used colors to be small and configurable.
Ideally, when mapped to a bicolor rendering with bold and/or
underlying they should
convey the same visual information.

-- Gaby

Re: Updated GCC vs Clang diagnostics

[Manuel López-Ibáñez]

On 13 April 2012 05:36, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> On Thu, Apr 12, 2012 at 9:26 PM, Manuel López-Ibáñez
> <lopezibanez@gmail.com> wrote:
>
>> I find the color output of Clang just beautiful and, in my opinion,
>> color support in GCC would make it a bit more beautiful and attract
>> new users, so it is a much better use of developer's time than fixing
>> yet another obscure diagnostic issue that only triggers with a careful
>> ad-hoc example. That said, I do really think you are free to work on
>> what interests you, so I hope to see your patches fixing diagnostics
>> issues soon.
>
> Is this the kind of protracted passive-aggressive opinion you were looking for?

I think my words above should be read in their own context, where
their true meaning can be fully appreciated. Then, one may be able to
appreciate that:

* Saying "I don't think X is important, so I am against it and you
should spend your free time in Y." and "Of course, you are free to
spend your time in whatever you want." is not logically consistent.
The only choices offered are Y or nothing.

* A real choice is offered by the paragraph above which changes the
statement to "I don't think X is important, and you should use spend
your free time on Y, but I am not against Y, so patches welcome."

* In the paragraph above, you also seem to have missed the irony that
the example I chose as "not important" are small diagnostic issues, on
which I (among very very few) have spent significant effort in the
recent years. I was hoping that this irony would help the reader to
understand that the example is not meant to be taken seriously, and it
is only there to demonstrate the previous logical inconsistency.

But my writing skills are still as poor as always, since it seems I am
having trouble making myself understood by some. So if you still
didn't get my point above, I am unable to explain myself in better
terms. Thus, let's forget about this and focus on the issue at hand.

Cheers,

Manuel.

Re: Updated GCC vs Clang diagnostics

[Manuel López-Ibáñez]

On 13 April 2012 08:03, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Apr 12, 2012 at 10:11:48PM -0700, Ian Lance Taylor wrote:
>> Lawrence Crowl <crowl@google.com> writes:
>>
>> > On 4/12/12, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote:
>> >> So given your ideal implementation, if the user-visible result
>> >> was exactly like the one in Clang, will you be happy with any of
>> >> the three things: ranges, color and fix-it hints?
>> >
>> > There are many issues with color.  Does your reader have any
>> > color deficiencies?  Does your software address them?  Does the
>> > system software render colors well?  Is color contrast sufficient?
>> > Is greyscale contrast sufficient?  Color is low on my list of
>> > desirables.
>>
>> It would be terrible if an error message could not be understood without
>> color.  But nobody is suggesting that.
>>
>> The question at hand is whether color can be used to enhance an error
>> message that can be understood without color.  For example, whether
>> color can be added to current error messages without any other changes.
>>
>> I personally think it would be an excellent idea.  Even clang's C++
>> error messages can be long.  A simple use of color is an excellent way
>> to draw the eye to the more important parts of the message.  If the
>> color is not available, then it doesn't help, but the error message can
>> be understood without it.
>
> Yeah, I second this.  As Manuel said, we should have an option to select
> never/auto/always coloring, colors must be just visual enhancements of the
> diagnostics that even when colors are disabled gives all the info that
> is needed (highlight error/warning/note diagnostic kind keywords, keywords
> in the source, perhaps types, whatever), we should limit to a very small
> set of colors, because not so many colors are actually very readable and
> perhaps make the color sets configurable somehow (things might be different
> if people use normally black characters on white background or white
> characters on black background, grep has GREP_COLORS env var here, ls
> LS_COLORS).

This is exactly what I would like to implement, if I am allowed.

But I don't want to turn the diagnostics machinery upside down and
implement a "diagnostics internal language" (which I already did in
XML http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19165#c10, and it sits
there useless), just to achieve this.

I just want to have a little file called colors.c which abstracts the
color implementation including the handling of GCC_COLORS. And add the
least amount of code needed to diagnostics.c to check whether the
prefix (warning|error|note) should be colored, the caret should be
colored, and perhaps the message itself should be colored (or not,
once you see the prefix, it is easy to identify the start of
messages). That is all that I am proposing.

Now, if I can get enough support for this to hope that with a nice
implementation it will get accepted, then I will try to get it done.
Otherwise, I will just forget about it and enjoy the sun.
Cheers,

Manuel.

Re: Updated GCC vs Clang diagnostics

[Gabriel Dos Reis]

On Fri, Apr 13, 2012 at 3:27 AM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> On 13 April 2012 05:36, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
>> On Thu, Apr 12, 2012 at 9:26 PM, Manuel López-Ibáñez
>> <lopezibanez@gmail.com> wrote:
>>
>>> I find the color output of Clang just beautiful and, in my opinion,
>>> color support in GCC would make it a bit more beautiful and attract
>>> new users, so it is a much better use of developer's time than fixing
>>> yet another obscure diagnostic issue that only triggers with a careful
>>> ad-hoc example. That said, I do really think you are free to work on
>>> what interests you, so I hope to see your patches fixing diagnostics
>>> issues soon.
>>
>> Is this the kind of protracted passive-aggressive opinion you were looking for?
>
> I think my words above should be read in their own context, where
> their true meaning can be fully appreciated. Then, one may be able to
> appreciate that:
>
> * Saying "I don't think X is important, so I am against it and you
> should spend your free time in Y." and "Of course, you are free to
> spend your time in whatever you want." is not logically consistent.
> The only choices offered are Y or nothing.
>
> * A real choice is offered by the paragraph above which changes the
> statement to "I don't think X is important, and you should use spend
> your free time on Y, but I am not against Y, so patches welcome."
>
> * In the paragraph above, you also seem to have missed the irony that
> the example I chose as "not important" are small diagnostic issues, on
> which I (among very very few) have spent significant effort in the
> recent years. I was hoping that this irony would help the reader to
> understand that the example is not meant to be taken seriously, and it
> is only there to demonstrate the previous logical inconsistency.
>
> But my writing skills are still as poor as always, since it seems I am
> having trouble making myself understood by some. So if you still
> didn't get my point above, I am unable to explain myself in better
> terms. Thus, let's forget about this and focus on the issue at hand.
>
> Cheers,
>
> Manuel.

If you believe people miss your use of irony, then it is up to you to decide how
to effectively get your points through effectively -- I am just not sure
blaming people for missing your use of irony is effective.

If this passive-aggressive strategy was the first or second time, I would
not mind -- in fact, I was hoping you would get tired of it yourself.

So, yes just to straight to the points.

-- Gaby

Re: Updated GCC vs Clang diagnostics

[Gabriel Dos Reis]

On Fri, Apr 13, 2012 at 3:41 AM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:

> But I don't want to turn the diagnostics machinery upside down and
> implement a "diagnostics internal language"

I do think  an internal formatting IL/IR for better representation is
needed for the
kind of things you would like to (e.g. colors) to keep things manageable.
 That isn't turning things upside down, and it isn't helpful to view
it that way.

-- Gaby

Re: Updated GCC vs Clang diagnostics

[Jonathan Wakely]

On 13 April 2012 02:40, Joe Buck wrote:
> I'm not interested in color output, and would turn it off if it were
> implemented (the escape sequences would just mess things up when capturing
> compiler output in log files).

There's no reason it would have to do that.  Git does a great job of
colouring output automatically when printing to a terminal but not
when redirected to a file or pipe. It also automatically pipes output
through a pager when it won't fit on the screen, and because it runs
the pager internally it still knows the final output is a terminal and
so outputs in colour.

Re: Updated GCC vs Clang diagnostics

[Manuel López-Ibáñez]

On 13 April 2012 10:46, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> On Fri, Apr 13, 2012 at 3:41 AM, Manuel López-Ibáñez
> <lopezibanez@gmail.com> wrote:
>
>> But I don't want to turn the diagnostics machinery upside down and
>> implement a "diagnostics internal language"
>
> I do think  an internal formatting IL/IR for better representation is
> needed for the
> kind of things you would like to (e.g. colors) to keep things manageable.
>  That isn't turning things upside down, and it isn't helpful to view
> it that way.

I am not opposed to having a diagnostics IL/IR, so you or anyone else
should feel free to start working on it. But after the XML diagnostics
experiment, I personally don't find it interesting enough to work on
it (specially to start such a project on my own). As a means to get
color output, it would be significantly more code, more invasive
change, require more time and effort and produce potentially more bugs
than the implementation of colors I am proposing above. So I'd rather
work on the latter, even if it is much more limited and less flexible
than a diagnostics IL.

Cheers,

Manuel.


>
> -- Gaby

Re: Updated GCC vs Clang diagnostics

[Gabriel Dos Reis]

On Fri, Apr 13, 2012 at 3:58 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 13 April 2012 02:40, Joe Buck wrote:
>> I'm not interested in color output, and would turn it off if it were
>> implemented (the escape sequences would just mess things up when capturing
>> compiler output in log files).
>
> There's no reason it would have to do that.  Git does a great job of
> colouring output automatically when printing to a terminal but not
> when redirected to a file or pipe. It also automatically pipes output
> through a pager when it won't fit on the screen, and because it runs
> the pager internally it still knows the final output is a terminal and
> so outputs in colour.

Yes, I do not think adding colored output is a challenge when done properly
(e.g. checking that, for example, the output device supports ANSI control
sequences even when it is a terminal, etc.)  What I am concerned about is that
the rush to have colored output may shadow the need to do it properly.

-- Gaby

Re: Updated GCC vs Clang diagnostics

[Jonathan Wakely]

On 13 April 2012 09:27, Manuel López-Ibáñez wrote:
>
> I think my words above should be read in their own context, where
> their true meaning can be fully appreciated. Then, one may be able to
> appreciate that:
>
> * Saying "I don't think X is important, so I am against it and you
> should spend your free time in Y." and "Of course, you are free to
> spend your time in whatever you want." is not logically consistent.
> The only choices offered are Y or nothing.

Joe didn't say *you* should spend your time on Y, he suggested
something he thought was more important, and he said *he'd* turn off
colour output which is not the same as saying it shouldn't be added.

> * A real choice is offered by the paragraph above which changes the
> statement to "I don't think X is important, and you should use spend
> your free time on Y, but I am not against Y, so patches welcome."

That's how I read Joe's mail.

There's no reason for this discussion to get heated, we're all working
towards the same goal.

> * In the paragraph above, you also seem to have missed the irony that
> the example I chose as "not important" are small diagnostic issues, on
> which I (among very very few) have spent significant effort in the
> recent years. I was hoping that this irony would help the reader to
> understand that the example is not meant to be taken seriously, and it
> is only there to demonstrate the previous logical inconsistency.

I'm afraid I missed that irony too, despite being well aware of all
the great work you've done on those sort of diagnostics. I was about
to reply saying the mixing up "." and "->" is not obscure at all.
Irony and subtly don't work by email.

Re: Updated GCC vs Clang diagnostics

[Gabriel Dos Reis]

On Fri, Apr 13, 2012 at 4:00 AM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> On 13 April 2012 10:46, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
>> On Fri, Apr 13, 2012 at 3:41 AM, Manuel López-Ibáñez
>> <lopezibanez@gmail.com> wrote:
>>
>>> But I don't want to turn the diagnostics machinery upside down and
>>> implement a "diagnostics internal language"
>>
>> I do think  an internal formatting IL/IR for better representation is
>> needed for the
>> kind of things you would like to (e.g. colors) to keep things manageable.
>>  That isn't turning things upside down, and it isn't helpful to view
>> it that way.
>
> I am not opposed to having a diagnostics IL/IR, so you or anyone else
> should feel free to start working on it. But after the XML diagnostics
> experiment,

The XML diagnostics experiment was an external representation.

> I personally don't find it interesting enough to work on
> it (specially to start such a project on my own). As a means to get
> color output, it would be significantly more code, more invasive
> change, require more time and effort and produce potentially more bugs
> than the implementation of colors I am proposing above. So I'd rather
> work on the latter, even if it is much more limited and less flexible
> than a diagnostics IL.

the short term desire to add color should not cloud the architectural concerns.
I don't want to get into a situation when in 3 months someone come and complain
that the diagnostic code is too obscure or to hard to debug, and when pressed
to explain declares that it was just out of frustration or irony --
and even if it was
just frustration, that is a concern.

-- Gaby

Re: Updated GCC vs Clang diagnostics

[Manuel López-Ibáñez]

On 13 April 2012 11:04, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
> On Fri, Apr 13, 2012 at 3:58 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> On 13 April 2012 02:40, Joe Buck wrote:
>>> I'm not interested in color output, and would turn it off if it were
>>> implemented (the escape sequences would just mess things up when capturing
>>> compiler output in log files).
>>
>> There's no reason it would have to do that.  Git does a great job of
>> colouring output automatically when printing to a terminal but not
>> when redirected to a file or pipe. It also automatically pipes output
>> through a pager when it won't fit on the screen, and because it runs
>> the pager internally it still knows the final output is a terminal and
>> so outputs in colour.
>
> Yes, I do not think adding colored output is a challenge when done properly
> (e.g. checking that, for example, the output device supports ANSI control
> sequences even when it is a terminal, etc.)  What I am concerned about is that
> the rush to have colored output may shadow the need to do it properly.

If a diagnostics IR is a hard requirement to add color support, then
fine. Please, let me know once the diagnostics IR is implemented, and
I may consider to try to add color support depending on how complex
the IR code is.

Please, also let me know if at some moment a simple implementation à
la grep becomes acceptable.

My excuses to all the readers for such a long thread to reach such a
simple conclusion. I also want to apologize to Joe for
misunderstanding his position. I don't have anything else to say on
this subject.

Cheers,

Manuel.

Re: Updated GCC vs Clang diagnostics

[Richard Guenther]

On Fri, Apr 13, 2012 at 12:53 PM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> On 13 April 2012 11:04, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
>> On Fri, Apr 13, 2012 at 3:58 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>> On 13 April 2012 02:40, Joe Buck wrote:
>>>> I'm not interested in color output, and would turn it off if it were
>>>> implemented (the escape sequences would just mess things up when capturing
>>>> compiler output in log files).
>>>
>>> There's no reason it would have to do that.  Git does a great job of
>>> colouring output automatically when printing to a terminal but not
>>> when redirected to a file or pipe. It also automatically pipes output
>>> through a pager when it won't fit on the screen, and because it runs
>>> the pager internally it still knows the final output is a terminal and
>>> so outputs in colour.
>>
>> Yes, I do not think adding colored output is a challenge when done properly
>> (e.g. checking that, for example, the output device supports ANSI control
>> sequences even when it is a terminal, etc.)  What I am concerned about is that
>> the rush to have colored output may shadow the need to do it properly.
>
> If a diagnostics IR is a hard requirement to add color support, then
> fine. Please, let me know once the diagnostics IR is implemented, and
> I may consider to try to add color support depending on how complex
> the IR code is.
>
> Please, also let me know if at some moment a simple implementation à
> la grep becomes acceptable.
>
> My excuses to all the readers for such a long thread to reach such a
> simple conclusion. I also want to apologize to Joe for
> misunderstanding his position. I don't have anything else to say on
> this subject.

I suppose we'd want to make the diagnostic machinery accessible by
plugins so that IDEs could get an easier hand on things anyway.  That
way colorization could be achieved using a plugin, too.

Richard.

> Cheers,
>
> Manuel.

Re: Updated GCC vs Clang diagnostics

[Gabriel Dos Reis]

On Fri, Apr 13, 2012 at 6:36 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:

> I suppose we'd want to make the diagnostic machinery accessible by
> plugins so that IDEs could get an easier hand on things anyway.  That
> way colorization could be achieved using a plugin, too.

Indeed, we definitely want a standard way to get IDEs communicate with
the diagnostic machinery; once that is appreciated, colorization becomes
an almost trivial thing to do.

-- Gaby

Re: Updated GCC vs Clang diagnostics

[Jakub Jelinek]

On Fri, Apr 13, 2012 at 04:09:19AM -0500, Gabriel Dos Reis wrote:
> the short term desire to add color should not cloud the architectural concerns.
> I don't want to get into a situation when in 3 months someone come and complain
> that the diagnostic code is too obscure or to hard to debug, and when pressed
> to explain declares that it was just out of frustration or irony --
> and even if it was
> just frustration, that is a concern.

On the other side, at least for basic color support I see no reason why it
would imply the need for any rearchitecturing of the diagnostic machinery.
If all we want to initially color is error: in one kind of color, warning:
in another one, note: in another one, caret line perhaps some other, then it
is just a matter of inserting a few pp_color_switch (pp, COLOR_ERROR); ...
pp_color_switch (pp, COLOR_NORMAL);.  Or if slightly more is needed, it can be
added around some format %letter handlers, say %T could print in some
special color if requested.  At that point we can have the color support
written and if some diagnostic machinery redesign is implemented later,
it won't be hard to adjust to it and do more color if desired.

Shooting down a potentially user friendly feature to wait until some blue
sky redesign is implemented means it might never be implemented.

	Jakub

Re: Updated GCC vs Clang diagnostics

[Gabriel Dos Reis]

On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek <jakub@redhat.com> wrote:

> Shooting down a potentially user friendly feature to wait until some blue
> sky redesign is implemented means it might never be implemented.

This is a mischaracterization and you know it.

-- Gaby

Re: Updated GCC vs Clang diagnostics

[NightStrike]

On Fri, Apr 13, 2012 at 11:22 AM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>
>> Shooting down a potentially user friendly feature to wait until some blue
>> sky redesign is implemented means it might never be implemented.
>
> This is a mischaracterization and you know it.
>
> -- Gaby

It is and it isn't.  The guy willing to do the basic color stuff has
no desire to do what you want.  Is there someone else lined up to do
it?  If not, then forcing a wait on it effectively blocks the
available developer.

Re: Updated GCC vs Clang diagnostics

[Gabriel Dos Reis]

On Fri, Apr 13, 2012 at 10:30 AM, NightStrike <nightstrike@gmail.com> wrote:
> On Fri, Apr 13, 2012 at 11:22 AM, Gabriel Dos Reis
> <gdr@integrable-solutions.net> wrote:
>> On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>>
>>> Shooting down a potentially user friendly feature to wait until some blue
>>> sky redesign is implemented means it might never be implemented.
>>
>> This is a mischaracterization and you know it.
>>
>> -- Gaby
>
> It is and it isn't.  The guy willing to do the basic color stuff has
> no desire to do what you want.  Is there someone else lined up to do
> it?  If not, then forcing a wait on it effectively blocks the
> available developer.

No. When you submit a patch to GCC (whether it is diagnostics or not
is immaterial), you expect that it will get reviewed and recommendations
will be made about the appropriate way to get it done.  Just have a look
at gcc-patches.  There is no thing new here.  If the submitter
refused to follow the recommendations, it is unfair it is being shut down
or blocked.

Re: Updated GCC vs Clang diagnostics

[NightStrike]

On Fri, Apr 13, 2012 at 11:36 AM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> On Fri, Apr 13, 2012 at 10:30 AM, NightStrike <nightstrike@gmail.com> wrote:
>> On Fri, Apr 13, 2012 at 11:22 AM, Gabriel Dos Reis
>> <gdr@integrable-solutions.net> wrote:
>>> On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>>>
>>>> Shooting down a potentially user friendly feature to wait until some blue
>>>> sky redesign is implemented means it might never be implemented.
>>>
>>> This is a mischaracterization and you know it.
>>>
>>> -- Gaby
>>
>> It is and it isn't.  The guy willing to do the basic color stuff has
>> no desire to do what you want.  Is there someone else lined up to do
>> it?  If not, then forcing a wait on it effectively blocks the
>> available developer.
>
> No. When you submit a patch to GCC (whether it is diagnostics or not
> is immaterial), you expect that it will get reviewed and recommendations
> will be made about the appropriate way to get it done.  Just have a look
> at gcc-patches.  There is no thing new here.  If the submitter
> refused to follow the recommendations, it is unfair it is being shut down
> or blocked.

Be that as it may, at the end of the day, we won't have color gcc if
you insist on waiting for the better framework.

Unless, of course, you're going to build the better framework.

When you're hungry, sometimes it's better to take an offer of an apple
when you really want an orange, because otherwise you have nothing.

Re: Updated GCC vs Clang diagnostics

[Gabriel Dos Reis]

On Fri, Apr 13, 2012 at 10:41 AM, NightStrike <nightstrike@gmail.com> wrote:
> On Fri, Apr 13, 2012 at 11:36 AM, Gabriel Dos Reis
> <gdr@integrable-solutions.net> wrote:
>> On Fri, Apr 13, 2012 at 10:30 AM, NightStrike <nightstrike@gmail.com> wrote:
>>> On Fri, Apr 13, 2012 at 11:22 AM, Gabriel Dos Reis
>>> <gdr@integrable-solutions.net> wrote:
>>>> On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>>>>
>>>>> Shooting down a potentially user friendly feature to wait until some blue
>>>>> sky redesign is implemented means it might never be implemented.
>>>>
>>>> This is a mischaracterization and you know it.
>>>>
>>>> -- Gaby
>>>
>>> It is and it isn't.  The guy willing to do the basic color stuff has
>>> no desire to do what you want.  Is there someone else lined up to do
>>> it?  If not, then forcing a wait on it effectively blocks the
>>> available developer.
>>
>> No. When you submit a patch to GCC (whether it is diagnostics or not
>> is immaterial), you expect that it will get reviewed and recommendations
>> will be made about the appropriate way to get it done.  Just have a look
>> at gcc-patches.  There is no thing new here.  If the submitter
>> refused to follow the recommendations, it is unfair it is being shut down
>> or blocked.
>
> Be that as it may, at the end of the day, we won't have color gcc if
> you insist on waiting for the better framework.

Not necessarily.

Would you or Jakub say that he is attempting to shoot down the switch to C++,
just  because he wants to see some components converted done first
(blue sky redesigned done first) even though he did not explicitly offer to
do that conversion himself, or would  you say that he is making a
recommendation
of what he considers to be in  the best long term interest. I would
say the latter.
Orange and apple analogy aside.


-- Gaby

Re: Updated GCC vs Clang diagnostics

[NightStrike]

On Fri, Apr 13, 2012 at 11:53 AM, Gabriel Dos Reis
<gdr@integrable-solutions.net> wrote:
> On Fri, Apr 13, 2012 at 10:41 AM, NightStrike <nightstrike@gmail.com> wrote:
>> On Fri, Apr 13, 2012 at 11:36 AM, Gabriel Dos Reis
>> <gdr@integrable-solutions.net> wrote:
>>> On Fri, Apr 13, 2012 at 10:30 AM, NightStrike <nightstrike@gmail.com> wrote:
>>>> On Fri, Apr 13, 2012 at 11:22 AM, Gabriel Dos Reis
>>>> <gdr@integrable-solutions.net> wrote:
>>>>> On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>>>>>
>>>>>> Shooting down a potentially user friendly feature to wait until some blue
>>>>>> sky redesign is implemented means it might never be implemented.
>>>>>
>>>>> This is a mischaracterization and you know it.
>>>>>
>>>>> -- Gaby
>>>>
>>>> It is and it isn't.  The guy willing to do the basic color stuff has
>>>> no desire to do what you want.  Is there someone else lined up to do
>>>> it?  If not, then forcing a wait on it effectively blocks the
>>>> available developer.
>>>
>>> No. When you submit a patch to GCC (whether it is diagnostics or not
>>> is immaterial), you expect that it will get reviewed and recommendations
>>> will be made about the appropriate way to get it done.  Just have a look
>>> at gcc-patches.  There is no thing new here.  If the submitter
>>> refused to follow the recommendations, it is unfair it is being shut down
>>> or blocked.
>>
>> Be that as it may, at the end of the day, we won't have color gcc if
>> you insist on waiting for the better framework.
>
> Not necessarily.
>
> Would you or Jakub say that he is attempting to shoot down the switch to C++,
> just  because he wants to see some components converted done first
> (blue sky redesigned done first) even though he did not explicitly offer to
> do that conversion himself, or would  you say that he is making a
> recommendation
> of what he considers to be in  the best long term interest. I would
> say the latter.
> Orange and apple analogy aside.
>
>
> -- Gaby

Ok, fine, but then explain to me how color gcc happens if nobody wants
to do the extra work you want?

Re: Updated GCC vs Clang diagnostics

[Gabriel Dos Reis]

On Fri, Apr 13, 2012 at 10:59 AM, NightStrike <nightstrike@gmail.com> wrote:
> On Fri, Apr 13, 2012 at 11:53 AM, Gabriel Dos Reis
> <gdr@integrable-solutions.net> wrote:
>> On Fri, Apr 13, 2012 at 10:41 AM, NightStrike <nightstrike@gmail.com> wrote:
>>> On Fri, Apr 13, 2012 at 11:36 AM, Gabriel Dos Reis
>>> <gdr@integrable-solutions.net> wrote:
>>>> On Fri, Apr 13, 2012 at 10:30 AM, NightStrike <nightstrike@gmail.com> wrote:
>>>>> On Fri, Apr 13, 2012 at 11:22 AM, Gabriel Dos Reis
>>>>> <gdr@integrable-solutions.net> wrote:
>>>>>> On Fri, Apr 13, 2012 at 9:23 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>>>>>>
>>>>>>> Shooting down a potentially user friendly feature to wait until some blue
>>>>>>> sky redesign is implemented means it might never be implemented.
>>>>>>
>>>>>> This is a mischaracterization and you know it.
>>>>>>
>>>>>> -- Gaby
>>>>>
>>>>> It is and it isn't.  The guy willing to do the basic color stuff has
>>>>> no desire to do what you want.  Is there someone else lined up to do
>>>>> it?  If not, then forcing a wait on it effectively blocks the
>>>>> available developer.
>>>>
>>>> No. When you submit a patch to GCC (whether it is diagnostics or not
>>>> is immaterial), you expect that it will get reviewed and recommendations
>>>> will be made about the appropriate way to get it done.  Just have a look
>>>> at gcc-patches.  There is no thing new here.  If the submitter
>>>> refused to follow the recommendations, it is unfair it is being shut down
>>>> or blocked.
>>>
>>> Be that as it may, at the end of the day, we won't have color gcc if
>>> you insist on waiting for the better framework.
>>
>> Not necessarily.
>>
>> Would you or Jakub say that he is attempting to shoot down the switch to C++,
>> just  because he wants to see some components converted done first
>> (blue sky redesigned done first) even though he did not explicitly offer to
>> do that conversion himself, or would  you say that he is making a
>> recommendation
>> of what he considers to be in  the best long term interest. I would
>> say the latter.
>> Orange and apple analogy aside.
>>
>>
>> -- Gaby
>
> Ok, fine, but then explain to me how color gcc happens if nobody wants
> to do the extra work you want?

when you said "Ok, fine", which of the two alternatives did you intend?

-- Gaby

Re: Updated GCC vs Clang diagnostics

[Lawrence Crowl]

On 4/12/12, Ian Lance Taylor <iant@google.com> wrote:
> Lawrence Crowl <crowl@google.com> writes:
> > On 4/12/12, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote:
> > > So given your ideal implementation, if the user-visible
> > > result was exactly like the one in Clang, will you be happy
> > > with any of the three things: ranges, color and fix-it hints?
> >
> > There are many issues with color.  Does your reader have
> > any color deficiencies?  Does your software address them?
> > Does the system software render colors well?  Is color contrast
> > sufficient?  Is greyscale contrast sufficient?  Color is low
> > on my list of desirables.
>
> It would be terrible if an error message could not be understood
> without color.  But nobody is suggesting that.

Agreed, no one is suggesting that.

However, without care, the message might be harder to understand
_with_ color.  At a minimum, one should be able to turn the
color off.  As I understand it, that option is in the plan.

> The question at hand is whether color can be used to enhance an
> error message that can be understood without color.  For example,
> whether color can be added to current error messages without any
> other changes.

Yes, color can enhance the messages.  I don't think we disagree
on that.  My point was that color is a harder problem that many
people understand.  For instance, there is no set of colors that
meet web contrast standards against both black and white backgrounds.

As I understand the plan, the colors will be user-configurable,
which goes a long way to addressing the problem because the user
can choose colors that work for them.  It would be nice if the
default configuration worked for a large set of folks.

> I personally think it would be an excellent idea.  Even clang's C++
> error messages can be long.  A simple use of color is an excellent
> way to draw the eye to the more important parts of the message.
> If the color is not available, then it doesn't help, but the
> error message can be understood without it.

Let me try to be clear.  I have no objection to the work as long as
I can turn it off.  If the issues I mention above are unaddressed,
it is likely that I will turn it off, which is why the feature is
low on my list of desirables.  If other folks desire it, I'm happy
to let them have it.  I'm even happy to add an environment variable
so that they can have it.  But, responding to the survey question,
for me color is not a priority.

-- 
Lawrence Crowl

Re: Updated GCC vs Clang diagnostics

[Marc Glisse]

On Fri, 13 Apr 2012, Lawrence Crowl wrote:

> Yes, color can enhance the messages.  I don't think we disagree
> on that.  My point was that color is a harder problem that many
> people understand.  For instance, there is no set of colors that
> meet web contrast standards against both black and white backgrounds.

If we output colored text to a terminal, the colors we will use there are 
those (usually 8 or 16) set up in the terminal. When you configure your 
terminal, setting an appropriate color palette is part of it, and when you 
change the background between light and dark, you also change the palette. 
Since other applications use colors, I would already be in trouble if they 
were not readable. So somehow I am not too scared.

> As I understand the plan, the colors will be user-configurable,
> which goes a long way to addressing the problem because the user
> can choose colors that work for them.  It would be nice if the
> default configuration worked for a large set of folks.

To confirm your point, clang managed to chose "bold black" as the default 
color for "note:", which is grey here but still not so visible on my black 
background :-(


With g++ that prints the context of an error first, I often have to 
carefully scroll many screens of messages until I find the first actual 
error, so some flashy color there could help.

The one thing I have found colors most useful for is coloring types that 
use a lot of templates. This has become less needed with g++ that uses 
intermediate types/typedefs to print a short type, but it was a great way 
to have the arguments at the same depth visible at a glance, and I still 
use it occasionally (also on the output of c++filt).


-- 
Marc Glisse