Made some more updates to this feature.  There's now a flag, -fdiagnostic-template-diff-limit=, that can be used to turn on the feature.  The limit is the maximum notes it emits at a time.  Support for several more kinds of parameters are included.  Let me know if you find any problems in the patch.<br>
<br><div class="gmail_quote">On Tue, Aug 30, 2011 at 12:02 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, August 30, 2011 05:05, Chandler Carruth wrote:<br>
> On Mon, Aug 29, 2011 at 8:56 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
>> For the current issue at hand - I'm with Doug on this. I think visual<br>
>> highlighting could add a lot of value over any solution that tries to be<br>
>> terminal coloring agnostic.<br>
><br>
> Again, I'm not suggesting that color doesn't have value. I'm suggesting that<br>
> we shouldn't encode *information* in color that isn't otherwise present in the<br>
> text. That's very different from the color making the information more<br>
> valuable (often through improved clarity).<br>
<br>
</div>The pedant in me wants to point out that we wouldn't be encoding information<br>
in formatting that isn't otherwise present -- the difference between the<br>
template-ids would be reconstructible from the types as written in the<br>
diagnostic (we'd need to unwrap enough of the type in the 'aka' to show this<br>
anyway, in order for the highlighting to be useful).<br>
<div class="im"><br>
>> That's not to say that we can't provide some degraded experience to<br>
>> non-colored users, but I think it will be inherently worse than highlighting.<br>
><br>
</div><div class="im">> The problem is *how* you provide the degraded experience. Sure, in some<br>
> cases, the clang driver detects whether or not we have a terminal available<br>
> that can render colors. However, there are many cases where *after* that<br>
> detection occurs, the colors are then stripped out by various pieces of<br>
> software. This can happen with screen, ssh, log processing, some defective<br>
> terminals, etc. That means that we don't have the opportunity to generate more<br>
> text at the moment the color gets stripped. The worst case scenario for me are<br>
> problems of colorblindness. ;]<br>
<br>
</div>We could use ^/~~~ markers on the line after the diagnostic for indicating<br>
which parts of the type differed (instead of / in addition to the formatting):<br>
<div class="im"><br>
type-diff.cc:26:3: error: no matching function for call to 'foo'<br>
  foo(A<B<C<D<int> > >, B<C<const double> > >());;<br>
  ^~~<br>
type-diff.cc:23:6: note: candidate function not viable: no known conversion from<br>
      'A<B<C<D<int> > >, B<C<const double> > >' to 'A<B<C<D<const int> > >,<br>
               ^             ~~~~~~~~~~~~                   ~~~~~<br>
      B<C<D<const double> > > >' for 1st argument;<br>
          ~~~~~~~~~~~~~~~<br>
void foo(A<B<C<D<const int> > >, B<C<D<const double> > > > F) {}<br>
     ^<br>
<br>
</div>Whatever we fall back on, I don't think it should be a separate note: this<br>
particular diagnostic is already too noisy, and as can be seen in the diff for<br>
test/Misc/diag-aka-types.cpp, the extra diagnostic will often be essentially<br>
redundant.<br>
<br>
As I've mentioned separately to Richard T, the patch will need to be amended<br>
to correctly handle alias templates (where I don't think we can do much better<br>
than to punt and not show the differences).<br>
<br>
Richard<br>
<br>
_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
</blockquote></div><br>