[cfe-dev] Type matcher madness

[Matthieu Monrocq]

On Wed, Aug 1, 2012 at 4:01 PM, 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")))
>
> 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
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>


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:

inline auto qualType(StringRef s) -> decltype(qualType(asString(s))) {
return qualType(asString(s)); }

inline auto hasElement(StringRef s) -> decltype(hasElement(qualType(s))) {
return hasElement(qualType(s)); }

inline auto arrayType(StringRef s) -> decltype(arrayType(hasElement(s))) {
return arrayType(hasElement(s)); }

would trivially expand    arrayType("int")    into
arrayType(hasElement(qualType(asString(StringRef("int")))))
auto-magically. And it's much nicer for the user/reader.


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

... even though it might be simpler to just have    arrayType    return a
bindable "QualType" directly, would it not ?


-- Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120801/0d28c515/attachment.html>