[cfe-dev] Type matcher madness

[Michael Diamond]

It seems to me that the distinction between QualType and Type is an
implementation detail that we shouldn't bother users with. If we make
everything a QualType, the users will have the same functionality in a more
easily readable format. I don't really see any disadvantages to this
approach. You mentioned that this would "kill the type safety for the
matchers"--what did you mean exactly?


On Wed, Aug 22, 2012 at 10:16 AM, Manuel Klimek <klimek at google.com> wrote:

> +mdiamond, who is interested in contributing here
>
> On Wed, Aug 1, 2012 at 12:21 PM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> > On Wed, Aug 1, 2012 at 7:01 AM, Manuel Klimek <klimek at google.com> wrote:
> >>
> >> Given Sam's open review, I've been pondering how to implement a type
> >> matcher (so far we've punted on that).
> >> The obvious idea would be to have a type() function that returns a
> >> Matcher<QualType>. Apart from some technical hoops to jump through I
> >> have a patch ready for that.
> >>
> >> This leads to a different design decision, though. We'll want type()
> >> to return a BindableMatcher, and for that we need to implement type
> >> binding. This is not quite straight forward, as types are split into
> >> QualType and Type nodes in the AST, and only the Type nodes model the
> >> inheritance hierarchy. My understanding is that this is for
> >> performance reasons, so that every Type* exists only once, and
> >> equality on types can be implemented by a pointer comparison.
> >>
> >> The question is: how much of that do we want to express in the matcher
> >> language.
> >> I see two main options:
> >> 1. Fully model that relationship. When somebody writes matchers for
> >> types, they will look like this:
> >> qualType(arrayType(hasElementType(qualType(asString("int"))))
> >>
> >> 2. Model QualTypes in the matchers, and allow going "through" to the
> >> underlying type; this will kill the type safety for the matchers, but
> >> will make the matcher expressions more concise:
> >> arrayType(hasElementType(asString("int")))
> >
> >
> > Is there a fundamental reason why we can't have the best of both? That
> is, a
> > matcher which matches Type *or* QualType, and constrains its inner
> matchers
> > to match ArrayType.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120822/928f62ce/attachment.html>