[cfe-dev] Type matcher madness

[Manuel Klimek]

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")))

The problem is that this means in (2):
type(hasElementType(asString("int")))
must be allowed by the type system, even though not every type is an array type

Thoughts?
/Manuel