Bug 45850 - support color diagnostics
Summary: support color diagnostics
Status: RESOLVED DUPLICATE of bug 36150
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: unknown
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-01 00:39 UTC by Manuel López-Ibáñez
Modified: 2010-10-03 13:09 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Manuel López-Ibáñez 2010-10-01 00:39:47 UTC
Support using color output to mark warnings/errors/notes.

Basically, clang's

-f[no-]color-diagnostics:
    This option, which defaults to on when a color-capable terminal is detected, controls whether or not Clang prints diagnostics in color. When this option is enabled, Clang will use colors to highlight specific parts of the diagnostic.


Basis for implementation may be either diff or grep. It should be implemented either in diagnostics.c or pretty-print.c (probably, diagnostics.c calling pretty-print.c to enable/disable specific colors).
Comment 1 Manuel López-Ibáñez 2010-10-02 16:59:28 UTC
I would personally like to have this. I know most people that want this use a wrapper around gcc (or have moved to clang), but the output of gcc is not designed to be machine readable, so I think there is a benefit on implementing this in GCC.

Since gcc doesn't have caret or fix-it hints, my proposal is quite modest, just  color the diagnostic markers:

error: (bold red)
warning: (magenta)
note: (blue? green?)

I would follow the very simple implementation used by grep.

It will default to off of course, I don't plan to implement automatic detection of capabilities or anything like that.

So before I waste my time, would such a thing be ever accepted in GCC?
Comment 2 Andrew Pinski 2010-10-02 17:03:33 UTC
This is a dup of bug 36150.

*** This bug has been marked as a duplicate of bug 36150 ***
Comment 3 Gabriel Dos Reis 2010-10-02 17:30:05 UTC
On Sat, Oct 2, 2010 at 11:59 AM, manu at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850
>
> Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                 CC|                            |gdr@integrable-solutions.ne
>                   |                            |t
>
> --- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2010-10-02 16:59:28 UTC ---
> I would personally like to have this. I know most people that want this use a
> wrapper around gcc (or have moved to clang), but the output of gcc is not
> designed to be machine readable,

I believe different people have different take on this.  I've seen
people argue and get stuff in on the basis that the output should
be machine readable.  I would suggest restraint from sweeping
statements, in the quest for consensus.

> so I think there is a benefit on implementing
> this in GCC.
>
> Since gcc doesn't have caret or fix-it hints, my proposal is quite modest, just
>  color the diagnostic markers:
>
> error: (bold red)
> warning: (magenta)
> note: (blue? green?)

my copy of GCC (under openSUSE) colors the output and let me
customize the colors.  That is quite system dependent.  Getting
the same stuff under non-Unix like system require more constraints
on the environment.  How far should we go to emulate an IDE?
Comment 4 Gabriel Dos Reis 2010-10-02 17:32:08 UTC
On Sat, Oct 2, 2010 at 11:59 AM, manu at gcc dot gnu.org
> Since gcc doesn't have caret or fix-it hints, my proposal is quite modest, just
>  color the diagnostic markers:
>
> error: (bold red)
> warning: (magenta)
> note: (blue? green?)
>
> I would follow the very simple implementation used by grep.

IDEs let users get the colors they want -if they ever wanted.

(the above is certainly a wrong default for me -- the background
of my terminal is always dark. :-)
Comment 5 Manuel López-Ibáñez 2010-10-02 18:04:00 UTC
> my copy of GCC (under openSUSE) colors the output and let me
> customize the colors.  That is quite system dependent.  Getting
> the same stuff under non-Unix like system require more constraints
> on the environment.  How far should we go to emulate an IDE?

So how does it work in openSUSE? Do they have patches that FSF GCC doesn't have?

I really don't care about non-unix environments. Not all features of GCC work on all operating systems.

And you say that you have colored output but you don't want FSF GCC to have it? Am I misunderstanding you?
Comment 6 Manuel López-Ibáñez 2010-10-02 18:30:45 UTC
(In reply to comment #4)
> On Sat, Oct 2, 2010 at 11:59 AM, manu at gcc dot gnu.org
> 
> IDEs let users get the colors they want -if they ever wanted.

The output of GCC is not designed to be parsed by IDEs:

http://gcc.gnu.org/PR19165

nor is GCC designed to be tightly integrated with an IDE.

> (the above is certainly a wrong default for me -- the background
> of my terminal is always dark. :-)

It is readable in my black background. It also looks nice here:

http://fseek.me/2010/03/how-to-convince-any-c-developer-to-dump-gcc-and-use-clang/

and in the examples here:

http://llvm.org/devmtg/2009-10/StateOfClang.pdf

Those colors are also readable in a white background. But feel free to suggest defaults, and I will be happy with them. Of course, customization, like grep, and ls, could be added later.
Comment 7 Gabriel Dos Reis 2010-10-02 18:35:26 UTC
On Sat, Oct 2, 2010 at 1:04 PM, manu at gcc dot gnu.org he
environment.  How far should we go to emulate an IDE?
>
> So how does it work in openSUSE? Do they have patches that FSF GCC doesn't
> have?

I did not look into their pacthes GC -- every vendor patches GCC in one
way or the other.

> I really don't care about non-unix environments. Not all features of GCC work
> on all operating systems.

I think that it a problem.


>
> And you say that you have colored output but you don't want FSF GCC to have it?
> Am I misunderstanding you?

I think you are.  I don't know if it is on purpose.
Comment 8 Gabriel Dos Reis 2010-10-02 18:41:28 UTC
On Sat, Oct 2, 2010 at 1:30 PM, manu at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45850
>
> --- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2010-10-02 18:30:45 UTC ---
> (In reply to comment #4)
>> On Sat, Oct 2, 2010 at 11:59 AM, manu at gcc dot gnu.org
>>
>> IDEs let users get the colors they want -if they ever wanted.
>
> The output of GCC is not designed to be parsed by IDEs:
>
> http://gcc.gnu.org/PR19165
>
> nor is GCC designed to be tightly integrated with an IDE.

that PR is a proof of what?

One reason we have standardized on 'warning: ', 'error: ', etc.
prefixes is precisely so that IDEs or other tools can differentiate
them.  The fact that we have not succeeded in many other areas
is more of a shortcoming than a design goal.

>> (the above is certainly a wrong default for me -- the background
>> of my terminal is always dark. :-)
>
> It is readable in my black background. It also looks nice here:

I think we may just have found two sets of people who disagree
on what is readable with a dark background.  Which is precisely
the point of my original message.
Comment 9 Manuel López-Ibáñez 2010-10-02 19:46:31 UTC
(In reply to comment #7)
> On Sat, Oct 2, 2010 at 1:04 PM, manu at gcc dot gnu.org he
> environment.  How far should we go to emulate an IDE?
> >
> > So how does it work in openSUSE? Do they have patches that FSF GCC doesn't
> > have?
> 
> I did not look into their pacthes GC -- every vendor patches GCC in one
> way or the other.

I did. They don't have a patch for this so I really wonder how this is possible. Are you sure you didn't install some wrapper around gcc?

Anyway, it is clear that is not something widely available. The fact that you have it enabled and openSUSE supports this is an indication that it is a desirable feature, at least for a subset of users.

> > I really don't care about non-unix environments. Not all features of GCC work
> > on all operating systems.
> 
> I think that it a problem.

Why? It only seems to work on openSUSE right now, definitely not in Ubuntu, so extending it to all unix supported by FSF GCC seems an improvement to me.

> > And you say that you have colored output but you don't want FSF GCC to have it?
> > Am I misunderstanding you?
> 
> I think you are.  I don't know if it is on purpose.

I want to add a feature to the FSF GCC. You are the one that can allow it, but you seem not in favour of it, despite using this feature in a customized version of GCC. So it is definitely in my best interest to understand why this is so, to try to address your concerns, or otherwise realize that this is not possible at all and give up.
Comment 10 Gabriel Dos Reis 2010-10-02 22:35:12 UTC
On Sat, Oct 2, 2010 at 2:46 PM, manu at gcc dot gnu.org
>> > And you say that you have colored output but you don't want FSF GCC to have it?
>> > Am I misunderstanding you?
>>
>> I think you are.  I don't know if it is on purpose.
>
> I want to add a feature to the FSF GCC. You are the one that can allow it, but
> you seem not in favour of it,

You seem to equate `discussing the technical problems (because there
are) associated with this' with 'seem not to favour' to the point of
attributing claims I have not made to me.  That makes it difficult to
discern when you are discussing technical problem as opposed
anything else. It makes hard to listen to what you are saying.


> despite using this feature in a customized
> version of GCC. So it is definitely in my best interest to understand why this
> is so, to try to address your concerns, or otherwise realize that this is not
> possible at all and give up.

There is a difference between `asking question in order to understand'
and `making a claim and attributing it to me'.
Comment 11 Jonathan Wakely 2010-10-03 09:50:06 UTC
(In reply to comment #6)
> 
> The output of GCC is not designed to be parsed by IDEs:
> 
> http://gcc.gnu.org/��0��

As an aside, what happened to that URL?
It looks fine here:
http://gcc.gnu.org/ml/gcc-bugs/2010-10/msg00243.html

Is this a bugzilla bug?
Comment 12 Manuel López-Ibáñez 2010-10-03 10:11:26 UTC
The output of GCC is not designed to be parsed by IDEs:

http://gcc.gnu.org/PR19165

nor is GCC designed to be tightly integrated with an IDE.
Comment 13 Manuel López-Ibáñez 2010-10-03 10:12:27 UTC
(In reply to comment #11)
> 
> Is this a bugzilla bug?

It seems so, since I can make it happen again.
Comment 14 Jonathan Wakely 2010-10-03 10:24:00 UTC
Frédéric, do you know what happened to the mangled URLs in this PR?
Comment 15 Frédéric Buclin 2010-10-03 13:09:08 UTC
(In reply to comment #14)
> Frédéric, do you know what happened to the mangled URLs in this PR?

Yes, this string has been linkified twice. First because the GCC extension detected the "PR....." string, and second because Bugzilla detected the "http://..." string. This is now fixed.