<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 29, 2011, at 8:13 PM, Chandler Carruth wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Mon, Aug 29, 2011 at 6:59 PM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><br><div><div><div></div><div class="h5"><div>On Aug 29, 2011, at 6:30 PM, Chandler Carruth wrote:</div><br><blockquote type="cite"><div class="gmail_quote">On Mon, Aug 29, 2011 at 6:10 PM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
<div><div></div><div><br>
On Aug 23, 2011, at 9:45 PM, Richard Trieu wrote:<br>
<br>
> I have been working on a new feature for diagnostic messages.  When a diagnostic contains two template types, give additional notes to show which part of the template is different.  For large templates, this will help users more quickly determine what is wrong with the template.<br>


><br>
> For example:<br>
><br>
> template <typename T1, typename T2> class A {};<br>
> template <typename T1> class B {};<br>
> template <typename T1> class C {};<br>
> template <typename T1> class D {};<br>
><br>
> void foo(A<B<C<D<const int> > >, B<C<D<const double> > > > F) {}<br>
><br>
> void bar() {<br>
>   foo(A<B<C<D<int> > >, B<C<const double> > >());;<br>
> }<br>
><br>
> would give the error:<br>
><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 'A<B<C<D<int> > >, B<C<const double> > >' to<br>
>       'A<B<C<D<const int> > >, B<C<D<const double> > > >' for 1st argument;<br>
> void foo(A<B<C<D<const int> > >, B<C<D<const double> > > > F) {}<br>
>      ^<br>
><br>
> It's hard to see exactly what's different from 'A<B<C<D<int> > >, B<C<const double> > >' and 'A<B<C<D<const int> > >, B<C<D<const double> > > >'<br>


><br>
> With template type diffing, additional notes are emitted to show the difference.  It now becomes:<br>
><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 'A<B<C<D<int> > >, B<C<const double> > >' to<br>
>       'A<B<C<D<const int> > >, B<C<D<const double> > > >' for 1st argument;<br>
> void foo(A<B<C<D<const int> > >, B<C<D<const double> > > > F) {}<br>
>      ^<br>
> type-diff.cc:23:6: note: Type 'C<const double>' is different from type 'C<D< >>'<br>
> type-diff.cc:23:6: note: Type 'D<int>' is different from type 'D<const int>'<br>
><br>
> I have attached a patch with an early prototype of this feature and would appreciate any feedback.  Currently, the extra notes are only displayed for this one note, but should be easy enough to extend to other places.  There's also a test case included to show some other examples of this feature.  Let me know what you think about it.<br>


<br>
</div></div>Interesting. I like the general idea, but I'm very worried that displaying this information via extra notes is going to introduce a significant amount of console spew. Especially when we're dealing with displayed candidate sets, where we already have a large number of notes.<br>


<br>
What we really want is to draw the user's eye to the differences between two similar types. Could we take advantage of the colorized console messages to highlight the differences between two similar types within the message text itself, so it doesn't cost us any more screen real estate?</blockquote>

<div><br></div><div>Several people mentioned this idea... I'm not sure it really works for all use cases though.</div><div><br></div><div>One of the common problems cited is that the template names are so long that they wrap across multiple lines. I think drawing the users eye to the two pieces that are different is going to be hard even with underlining or bolding or other formatting.</div>
</div></blockquote><div><br></div></div></div><div>With the current, note-based scheme, I need to first look at the types mentioned as different and then search for where they occur in the long, wrapped diagnostic text above. They may even occur multiple times in the diagnostic text, so I need to figure out which occurrences the warning is talking about. If we annotate the diagnostic text directly with bold or color, we get all of this information in one place, and there's no hunting.</div>
<div class="im"><br><blockquote type="cite"><div class="gmail_quote"><div>The other interesting aspect is that these notes don't add as much screen real estate as many others -- they're essentially guaranteed to not show the code snippet, and to be very short, so they don't line wrap a lot.</div>
</div></blockquote><div><br></div></div><div>I agree they aren't as bad as full-length notes, but I maintain that it's still a lot of information to add to an already-verbose diagnostic… and I think coloring (when it's available) is actively better.</div>
<div class="im"><br><blockquote type="cite"><div class="gmail_quote"><div>Finally, nothing says we have to do one or the other. We could do both, and allow people to enable or disable them. This seems particularly appealing to me, as for non-console users, there are much more intuitive ways to display this information. </div>

</div>
</blockquote></div></div><div><br></div><div>Well, sure. We can represent this information in some way that allows coloring or bold when available on the console (which I still think is preferable), and provide some other markup (possibly including multiple notes) for non-console output.</div>
</div></blockquote><div><br></div><div>I'm really uncomfortable with this direction, despite not disagreeing with any of your points here. I completely agree about the drawbacks of separate notes, and why colors can be very nice, just so we're on the same page.</div>
<div><br></div><div>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.</div></div></blockquote><div><br></div><div>This is a good point.</div><br><blockquote type="cite"><div class="gmail_quote"><div>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.)</div>
<div><br></div><div>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...</div>
</div></blockquote></div><br><div>We could consider some kind of substitution scheme, e.g.,</div><div><br></div><div><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; "><div style="word-wrap: break-word; "><div><div><div class="h5"><blockquote type="cite"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div><div>type-diff.cc:23:6: note: candidate function not viable: no known conversion from 'A<B<#1> >, B<#2>' to<br>>       '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> >]</div></div></blockquote></div></blockquote></div></div></div></div></blockquote></div></blockquote><br></div><div>It's not beautiful, but it does a decent job of showing the common structure while isolating the parts that differ.</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>- Doug</div></body></html>