[PATCH][RFC] diagnostics: Add support for Unicode drawing characters
Wed Aug 5 20:00:30 GMT 2020
On Fri, Jul 24, 2020 at 02:49:36PM +0100, Richard Sandiford wrote:
> Lewis Hyatt via Gcc-patches <firstname.lastname@example.org> writes:
> > On Thu, Jul 23, 2020 at 05:47:28PM -0400, David Malcolm wrote:
> >> On Thu, 2020-07-23 at 12:28 -0400, Lewis Hyatt via Gcc-patches wrote:
> >> > Hello-
> >> >
> >> > The attached patch is complete including docs, but I tagged as RFC
> >> > because I am not sure if anyone will like it, or if the general
> >> > reaction may
> >> > be closer to recoiling in horror :). Would appreciate your thoughts,
> >> > please...
> >> Thanks for working on this. I'm interested in other people's thoughts
> >> on this. Various comments inline throughout below.
> +1 in favour FWIW.
Thanks for the feedback!
> > […]
> > By the way, I was wondering separately what you think about adding an option
> > like -fplain-diagnostics or something, which would achieve basically the same
> > thing you get in the testsuite right now (-fno-diagnostics-show-caret
> > -fno-diagnostics-show-line-numbers -fdiagnostics-color=never
> > -fdiagnostics-urls=never) but would change as necessary whenever diagnostics
> > evolve. It seems rather involved currently to add a new option like
> > -fdiagnostics-unicode-drawing but keep the testsuite working, in addition to
> > adding to prune.exp and to the libstdc++.exp, you also need to update the
> > compat.exp so that it can figure out to pass the option only to sufficiently
> > new compilers. With -fplain-diagnostics, this could just be part of the code
> > change and the testsuite could stay the same; this may also make it easier on
> > IDE type utilities since they could rely on a more stable format for the
> > diagnostics, assuming they don't already use JSON format.
> Also agree that this would be a nice feature to have. I guess it would
> act as an alias for all the -fno-* options at the point that it occurs
> on the command line, so that it would be possible to use:
> -fplain-diagnostics -fthe-diagnostic-feature-i-like
Yes, that's what I was thinking. Currently the option -fdiagnostics-color
requires special handling because it applies even before it appears in the
command line (so that, say, a wrong option which appears earlier can still get a
colorized diagnostic). I was thinking the way to go would be to expand
-fplain-diagnostics into its constituents around the same place that this
special handling is done. I'll go ahead and submit a patch separately for this
sometime soon, in case it is found useful.
> > […]
> >> * maybe have a different character for separating the line numbers as
> >> opposed to those for labels and for showing interprocedural paths.
> > Something like that would be easy to add, sure, perhaps a double vertical line
> > instead:
> > diagnostic-ranges.c:196:28: warning: field width specifier ‘*’ expects argument of type ‘int’, but argument 3 has type ‘long int’ [-Wformat=]
> > 196 ║ __builtin_sprintf (d, " %*ld ", foo + bar, foo);
> > ║ ═∧══ ════╤════
> > ║ │ │
> > ║ int long int
> Guess it's just personal taste, but that seems a bit too busy to me.
> Most diagnostics don't have interprocedural paths, and on its own,
> there doesn't seem to be a specific reason to have a double line
> on the left.
I tend to agree with this assessment as well.
More information about the Gcc-patches