<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 20, 2012, at 11:14 AM, Daniel Jasper <<a href="mailto:djasper@google.com">djasper@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Not making a statement about whether we could improve the error messages in this case, but just some additional information. I changed this as part of the TypeLoc-matcher patch I am writing now. The problem does not just relate to error messages.</blockquote><div><br></div>Okay.</div><div><br><blockquote type="cite"><div>With the former implementation, it is basically possible to implicitly convert any matcher into any other matcher. The only thing that prevents "wrong" conversions to compile is that for wrong conversions, the call to From.matches in ImplicitCastMatcher.matches() fails. This has three downsides:</div>
<div>- Bad error message. Maybe possible to fix, but I am not sure, how.</div><div>- The error is found after ambiguity resolution. So if I write two functions with the same name accepting different matchers, that will always result in an ambiguity error, as at that point, C++ thinks I can use any matcher for either of these functions.</div>
<div>- For type matchers, I want two different conversions: I want to be able to implicitly turn any Matcher<Type> into a Matcher<derived-from-Type> as well as into a Matcher<QualType> using different approaches (see the patch I have just sent out). I don't know how to make this work with the conversion operator (and not using C++11 features).</div>
<div><br></div><div>I have separated this patch from the rest of the TypeLoc-matching, as it stands for its own and both patches are complicated enough. Probably my description could have included some of these aspects..</div></blockquote><div><br></div>Okay, I see that this is a good general fix to the matchers rather than simply a workaround. My apologies for the knee-jerk reaction to what looked like working around a Clang QoI problem :)</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div><div><br><blockquote type="cite"><div>Cheers,</div><div>Daniel</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Sep 20, 2012 at 7:51 PM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</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 Thu, Sep 20, 2012 at 7:32 PM, Doug Gregor<br>
<<a href="mailto:reviews@llvm-reviews.chandlerc.com">reviews@llvm-reviews.chandlerc.com</a>> wrote:<br>
><br>
> Hate to ask, but... why are we changing the way we use C++ to improve the error messages, rather than making Clang produce better error messages in the first place? The latter has far more value.<br>
<br>
</div>It seems to me like this is an inherent problem of how template<br>
instantiation works, but I might be wrong:<br>
previously we would always have a conversion operator, but the<br>
instantiation of it was able to fail - thus, how do you decide whether<br>
to show the programmer the error of at which exact point the<br>
instantiation failed (in this case inside an instantiation that<br>
triggers an instantiation that would call a method that the user isn't<br>
even aware is called anywhere), or to show that there's no possible<br>
conversion?<br>
<br>
Now because of SFINAE, using the higher level meta-programming<br>
abstractions the programmer tells the compiler: this is actually<br>
intended to fail at this specific point - no need to dig further for<br>
error causes.<br>
<br>
Thoughts?<br>
<span class="HOEnZb"><font color="#888888">/Manuel<br>
</font></span></blockquote></div><br></div>
</blockquote></div><br></body></html>