This is the mail archive of the
mailing list for the GCC project.
Re: RFC: color diagnostics markers
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: Manuel López-Ibáñez <lopezibanez at gmail dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Gcc Patch List <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 10 Apr 2013 21:04:06 -0500
- 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> <CAESRpQBKcq+7UmPN-TXWwQfz6WG-R+M1X-41fWjYfzgLUUOW2Q at mail dot gmail dot com>
On Wed, Apr 10, 2013 at 12:54 PM, Manuel López-Ibáñez
> 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.
We might be saying the same thing using different languages.
I was the %r/%R markers are ways of implementing the IL language
I suggested in that message. So, as such I do not object to it.
Having an explicit call makes the FE makes a "colorful" formatting
decision way too early -- a FE shouldn't be concerned about color matters.
That decision should be left to the device doing the formatting. Separation
of concerns here isn't just taste; it is good engineering practice.