[cfe-commits] Request feedback for new diagnostic feature - template type diffing

[Douglas Gregor]

On Aug 29, 2011, at 6:30 PM, Chandler Carruth wrote:

> On Mon, Aug 29, 2011 at 6:10 PM, Douglas Gregor <dgregor at apple.com> wrote:
> 
> On Aug 23, 2011, at 9:45 PM, Richard Trieu wrote:
> 
> > 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.
> >
> > For example:
> >
> > template <typename T1, typename T2> class A {};
> > template <typename T1> class B {};
> > template <typename T1> class C {};
> > template <typename T1> class D {};
> >
> > void foo(A<B<C<D<const int> > >, B<C<D<const double> > > > F) {}
> >
> > void bar() {
> >   foo(A<B<C<D<int> > >, B<C<const double> > >());;
> > }
> >
> > would give the error:
> >
> > type-diff.cc:26:3: error: no matching function for call to 'foo'
> >   foo(A<B<C<D<int> > >, B<C<const double> > >());;
> >   ^~~
> > type-diff.cc:23:6: note: candidate function not viable: no known conversion from 'A<B<C<D<int> > >, B<C<const double> > >' to
> >       'A<B<C<D<const int> > >, B<C<D<const double> > > >' for 1st argument;
> > void foo(A<B<C<D<const int> > >, B<C<D<const double> > > > F) {}
> >      ^
> >
> > 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> > > >'
> >
> > With template type diffing, additional notes are emitted to show the difference.  It now becomes:
> >
> > type-diff.cc:26:3: error: no matching function for call to 'foo'
> >   foo(A<B<C<D<int> > >, B<C<const double> > >());;
> >   ^~~
> > type-diff.cc:23:6: note: candidate function not viable: no known conversion from 'A<B<C<D<int> > >, B<C<const double> > >' to
> >       'A<B<C<D<const int> > >, B<C<D<const double> > > >' for 1st argument;
> > void foo(A<B<C<D<const int> > >, B<C<D<const double> > > > F) {}
> >      ^
> > type-diff.cc:23:6: note: Type 'C<const double>' is different from type 'C<D< >>'
> > type-diff.cc:23:6: note: Type 'D<int>' is different from type 'D<const int>'
> >
> > 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.
> 
> 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.
> 
> 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?
> 
> Several people mentioned this idea... I'm not sure it really works for all use cases though.
> 
> 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.

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.

> 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.

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.

> 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. 


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.

	- Doug

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