[cfe-commits] cfe-commits Digest, Vol 50, Issue 246

[Matthieu Monrocq]

>
> Date: Tue, 30 Aug 2011 07:13:21 -0700
> From: Douglas Gregor <dgregor at apple.com>
> Subject: Re: [cfe-commits] Request feedback for new diagnostic feature
>        - template type diffing
> To: Chandler Carruth <chandlerc at google.com>
> Cc: llvm cfe <cfe-commits at cs.uiuc.edu>
> Message-ID: <CD5010A7-59BE-4D63-AF60-8732DD79811C at apple.com>
> Content-Type: text/plain; charset="windows-1252"
>
> > My problem is this: thus far, Clang's colors, bold, and other markup of
> the textual output don't add any information, they just make the information
> displayed easier to read. I like that distinction, because we have a lot of
> users who will at some points not have color or bold available when looking
> at the text. This happens either due to disabilities, deficient terminals,
> terminal preferences, ssh silliness, or because the diagnostics have gone
> through a layer of textual logging that tried to strip escape codes. Lots of
> different reasons this can happen.
>
> This is a good point.
>
> > As a result, I've found it very important that the user can usually get
> the full benefit of the improved diagnostic even w/o these nice-to-have
> markups. This is the first time (I think) that we're adding a really
> significant amount of logic to convey information that would be lost without
> the colors / markup. (Another interesting example is that we break the
> underlining of source ranges into ~s on a separate line in ascii art rather
> than using the underlining escape codes.)
> >
> > Can you think up a way to not have to make this compromise? That is,
> could we present this information in a way that didn't require colors or
> other special terminal features *and* didn't have the downside of notes
> (searching, etc)? I haven't been able to, but that would be my preference.
> While I would love to take advantage of a more rich medium when available
> (*cough* IDEs make this easy *cough*), I'd like to get as much of this
> benefit into the plain-old-text output as possible, with the understanding
> that we have a lot of users which will loose some or all of the markup we
> apply to the text...
>
> We could consider some kind of substitution scheme, e.g.,
>
> >> type-diff.cc:23:6: note: candidate function not viable: no known
> conversion from 'A<B<#1> >, B<#2>' to
> >> >       'A<B<#3>, B<#4> >' for 1st argument; [with #1 = C<D<int>, #2 =
> C<const double> >, #3 = C<D<const int> >, #4 = C<D<const double> >]
>
> It's not beautiful, but it does a decent job of showing the common
> structure while isolating the parts that differ.
>
>        - Doug
>

Hello,

Having issues of color-blindness, I am wary of encoding information into
colors (though I do see most of them).

I think that the substitution scheme works quite good actually, however for
ease of use I would change the names and order to group more clearly those
groups that were supposed to be equal.

>> type-diff.cc:23:6: note: candidate function not viable: no known
conversion from 'A<B<#a0> >, B<#b0>' to
>> >       'A<B<#a1>, B<#b1> >' for 1st argument; [with #a0 = C<D<int>, #a1
= C<D<const int> , #b0 = C<const double> >>, #b1 = C<D<const double> >]

I would also suggest that in case of multi-line diagnostic we might be
willing to help the printer by inserting line-break hints within the line:

> [with #a0 = C<short, const short, int, const int, unsigned, const
unsigned, double, const double, float, const float>, #a1 = C<short, const
short, int, const int, unsigned, unsigned, double, const double, float,
const float>]

does not help much, but:

> [with #a0 = C<short, const short, int, const int, unsigned, const
unsigned, double, const double, float, const float>,
   _____#a1 = C<short, const short, int, const int, unsigned, unsigned,
double, const double, float, const float>]

does.

(crossing my fingers hoping this won't get mangled so much as making my
point unreadable...)

I believe it should be possible to pass "alignment" hints in the message, to
be used by the printer when the text of the diagnostic goes multi-line
(though admittedly I didn't thought one iota about *how* to pass such
information).

-- Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110830/e1ce591c/attachment.html>