On Sep 20, 2012, at 11:14 AM, Daniel Jasper <[email protected]> wrote:
> 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.
Okay.
> 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:
> - Bad error message. Maybe possible to fix, but I am not sure, how.
> - 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.
> - 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).
>
> 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..
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 :)
- Doug
> Cheers,
> Daniel
>
>
> On Thu, Sep 20, 2012 at 7:51 PM, Manuel Klimek <[email protected]> wrote:
> On Thu, Sep 20, 2012 at 7:32 PM, Doug Gregor
> <[email protected]> wrote:
> >
> > 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.
>
> It seems to me like this is an inherent problem of how template
> instantiation works, but I might be wrong:
> previously we would always have a conversion operator, but the
> instantiation of it was able to fail - thus, how do you decide whether
> to show the programmer the error of at which exact point the
> instantiation failed (in this case inside an instantiation that
> triggers an instantiation that would call a method that the user isn't
> even aware is called anywhere), or to show that there's no possible
> conversion?
>
> Now because of SFINAE, using the higher level meta-programming
> abstractions the programmer tells the compiler: this is actually
> intended to fail at this specific point - no need to dig further for
> error causes.
>
> Thoughts?
> /Manuel
>
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
