[cfe-commits] [PATCH] Provide better error messages for incorrect matchers

[Daniel Jasper]

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.

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

Cheers,
Daniel


On Thu, Sep 20, 2012 at 7:51 PM, Manuel Klimek <klimek at google.com> wrote:

> On Thu, Sep 20, 2012 at 7:32 PM, Doug Gregor
> <reviews at llvm-reviews.chandlerc.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120920/e6dc0d85/attachment.html>