This is the mail archive of the
mailing list for the GCC project.
Re: RFC: color diagnostics markers
- From: Manuel López-Ibáñez <lopezibanez at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Gabriel Dos Reis <gdr at integrable-solutions dot net>, "Joseph S. Myers" <joseph at codesourcery dot com>, Gcc Patch List <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 10 Apr 2013 19:54:28 +0200
- Subject: Re: RFC: color diagnostics markers
- References: <CAESRpQCG6VX4JTEXLhrV2LDCLENYB7i8ad-3jj=K6FGeuK5+Ug at mail dot gmail dot com> <20130402091449 dot GE20616 at tucnak dot redhat dot com> <CAESRpQAiDrn-9T7Zxvs2ZQVT9hE9_X=gnEyDkS7Y4b-vOiz3Cg at mail dot gmail dot com> <20130408132301 dot GO20334 at tucnak dot redhat dot com> <CAESRpQAz45k2SYVcEDn_oVkUuLVtGqChHRdgS0NQW5dVgrveLw at mail dot gmail dot com> <20130408144359 dot GP20334 at tucnak dot redhat dot com> <CAESRpQBXecse09cZ55_EhDzQno4K5Tid+N5beMG0JdOBLmLGJQ at mail dot gmail dot com> <20130408190620 dot GQ20334 at tucnak dot redhat dot com>
On 8 April 2013 21:06, Jakub Jelinek <email@example.com> wrote:
> On Mon, Apr 08, 2013 at 07:54:18PM +0200, Manuel López-Ibáñez wrote:
>> > can be right now a single call, while you would need several. Also, if you
>> > eventually want to colorize something in say error_at, warning_at and
>> > similar format strings. For those you really don't have the printer at
>> Do we really want to allow that much flexibility? Then the color_dict
>> needs to be dynamic or the caller is restricted to re-using existing
> Yes, I think we want that flexibility, it certainly isn't that much
> difficult to support it (a few lines of code, will try to code the %r/%R
> variant tomorrow), and from time to time it can be useful.
I am still not convinced by the %r/%R. My two concerns are that:
1) %r/%R rather than explicit function calls make the code harder to
understand. But I guess this is a matter of taste.
2) It makes harder to decouple the diagnostics machinery from the
actual formatting. The color should be something handled by the
pretty-printer and transparent to the diagnostics machinery interface.
(perhaps it should be pretty-printer-color.h instead of
diagnostics-color.h). I generally agree with the ideas of Gabriel
exposed here: http://gcc.gnu.org/ml/gcc/2012-04/msg00558.html. The
difference (and perhaps I misunderstood Gabriel's position in that
thread) is that I think that hiding the color stuff behind the
diagnostics machinery interface does not move us farther away from
those ideas, even thought it does not move us closer either. And we
don't need an internal IL to do that. However, letting the FEs add
arbitrary colors to diagnostics does move us farther. Yes, it is a
nice flexibility, but on the other hand, I don't really see the need
and I am afraid it will be misused. As Gabriel says: "it would be
really terrible idea if the intelligibility of a diagnostic -requires-
colors.". So if the color is not required, the FE should be oblivious
to whether there is a specific color there or not.
Nonetheless, I am pragmatic. Since you already did the work (and
improved significantly my original patch), I am fine with your patch
(for what is worth). Thanks for working on it.