[cfe-dev] Type matcher madness

[Manuel Klimek]

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