[cfe-dev] Type matcher madness

[Richard Smith]

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/20120801/c19a6989/attachment.html>