> > Date: Tue, 30 Aug 2011 07:13:21 -0700 > From: Douglas Gregor <dgre...@apple.com> > Subject: Re: [cfe-commits] Request feedback for new diagnostic feature > - template type diffing > To: Chandler Carruth <chandl...@google.com> > Cc: llvm cfe <cfe-commits@cs.uiuc.edu> > Message-ID: <cd5010a7-59be-4d63-af60-8732dd798...@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
_______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
