We discussed this offline a bit, and we basically came to the conclusion that we should support both Type and QualType with auto-conversions from Matcher<Type> to Matcher<QualType>. We will only support binding QualTypes, but this shouldn't be a big deal since every Type is wrapped by a QualType. Are there any objections to this approach?<div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Aug 22, 2012 at 6:25 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">
<div class="im">On Wed, Aug 22, 2012 at 3:43 PM, Michael Diamond <<a href="mailto:mdiamond@google.com">mdiamond@google.com</a>> wrote:<br>
> It seems to me that the distinction between QualType and Type is an<br>
> implementation detail that we shouldn't bother users with. If we make<br>
> everything a QualType, the users will have the same functionality in a more<br>
> easily readable format. I don't really see any disadvantages to this<br>
> approach. You mentioned that this would "kill the type safety for the<br>
> matchers"--what did you mean exactly?<br>
<br>
</div>The question is specifically: how do we intend to do the binding, and<br>
what types will the matchers have.<br>
<br>
One possibility:<br>
<br>
BindableMatcher<QualType> type(Matcher<QualType>...)<br>
<br>
Then we implement all things that match on a specific type to go<br>
through QualType. But, to get type safety, we'll want to have matchers<br>
that actually break compilation if you use them in a wrong context,<br>
like:<br>
<br>
Matcher<RecordType> hasConstFields();<br>
<br>
If we only use QualType, as far as I can tell we cannot do that.<br>
<br>
Thoughts?<br>
<span class="HOEnZb"><font color="#888888">/Manuel<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> On Wed, Aug 22, 2012 at 10:16 AM, Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:<br>
>><br>
>> +mdiamond, who is interested in contributing here<br>
>><br>
>> On Wed, Aug 1, 2012 at 12:21 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>><br>
>> wrote:<br>
>> > On Wed, Aug 1, 2012 at 7:01 AM, Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:<br>
>> >><br>
>> >> 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<br>
>> >> 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>
>> ><br>
>> > Is there a fundamental reason why we can't have the best of both? That<br>
>> > is, a<br>
>> > matcher which matches Type *or* QualType, and constrains its inner<br>
>> > matchers<br>
>> > to match ArrayType.<br>
><br>
><br>
</div></div></blockquote></div><br></div>