<br><br><div class="gmail_quote">On Wed, Aug 1, 2012 at 4:01 PM, 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>
<br>
The problem is that this means in (2):<br>
type(hasElementType(asString("int")))<br>
must be allowed by the type system, even though not every type is an array type<br>
<br>
Thoughts?<br>
/Manuel<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br><br>I would have expected to be able to type    arrayType("int")    this seems possible with a bit of overloading and/or implicit conversions. For example:<br><div style="margin-left:40px">
<br>inline auto qualType(StringRef s) -> decltype(qualType(asString(s))) { return qualType(asString(s)); }<br><br>inline auto hasElement(StringRef s) -> decltype(hasElement(qualType(s))) { return hasElement(qualType(s)); }<br>
<br>inline auto arrayType(StringRef s) -> decltype(arrayType(hasElement(s))) { return arrayType(hasElement(s)); }<br></div><br>would trivially expand    arrayType("int")    into    arrayType(hasElement(qualType(asString(StringRef("int")))))    auto-magically. And it's much nicer for the user/reader.<br>
<br><br>On the other hand, if having a qualType for the array is necessary, then I am not opposed to    qualType(arrayType("int"))    and this should patch your hole whilst still providing a succinct interface...<br>
<br>... even though it might be simpler to just have    arrayType    return a bindable "QualType" directly, would it not ?<br><br><br>-- Matthieu<br>