<div class="gmail_quote">On Wed, Aug 1, 2012 at 7:01 AM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Given Sam's open review, I've been pondering how to implement a type<br>
matcher (so far we've punted on that).<br>
The obvious idea would be to have a type() function that returns a<br>
Matcher<QualType>. Apart from some technical hoops to jump through I<br>
have a patch ready for that.<br>
<br>
This leads to a different design decision, though. We'll want type()<br>
to return a BindableMatcher, and for that we need to implement type<br>
binding. This is not quite straight forward, as types are split into<br>
QualType and Type nodes in the AST, and only the Type nodes model the<br>
inheritance hierarchy. My understanding is that this is for<br>
performance reasons, so that every Type* exists only once, and<br>
equality on types can be implemented by a pointer comparison.<br>
<br>
The question is: how much of that do we want to express in the matcher language.<br>
I see two main options:<br>
1. Fully model that relationship. When somebody writes matchers for<br>
types, they will look like this:<br>
qualType(arrayType(hasElementType(qualType(asString("int"))))<br>
<br>
2. Model QualTypes in the matchers, and allow going "through" to the<br>
underlying type; this will kill the type safety for the matchers, but<br>
will make the matcher expressions more concise:<br>
arrayType(hasElementType(asString("int")))<br></blockquote><div><br></div><div>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.</div>
</div>