[cfe-dev] Type matcher madness

[Manuel Klimek]

On Wed, Aug 22, 2012 at 3:43 PM, Michael Diamond <mdiamond at google.com> wrote:
> 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?

The question is specifically: how do we intend to do the binding, and
what types will the matchers have.

One possibility:

BindableMatcher<QualType> type(Matcher<QualType>...)

Then we implement all things that match on a specific type to go
through QualType. But, to get type safety, we'll want to have matchers
that actually break compilation if you use them in a wrong context,
like:

Matcher<RecordType> hasConstFields();

If we only use QualType, as far as I can tell we cannot do that.

Thoughts?
/Manuel

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