[cfe-dev] Matching bools

Manuel Klimek klimek at google.com
Mon Oct 8 05:17:33 PDT 2012


On Mon, Oct 8, 2012 at 2:12 PM, Daniel Jasper <djasper at google.com> wrote:
> +cfe-dev
>
> The const-case was just an example. You have similar problems with
> arrays, pointers, references (where to put [], * and &? where to put
> spaces?), types with typedefs, ...
>
> I am working on a sensible way to match types (see
> http://llvm-reviews.chandlerc.com/D47), which will enable better Type
> matching. The AST-matcher language is a good way to describe patterns
> in the AST and we don't want a second language based on strings. Thus,
> I am  against extending the functionality of asString in any way.

That about sums up what I think, too. Perhaps we should give asString
a name that makes it clear that we're basically relying on a volatile
concept? asDebugString? asInternalStringDump?

Cheers,
/Manuel

>
> On Mon, Oct 8, 2012 at 2:06 PM, Gábor Horváth <xazax.hun at gmail.com> wrote:
>> What about forcing asString to only match unqualified types, and force users
>> to use isConstqualified and other matchers for qualifiers together with
>> asString? If asString would match both the cannonical types and typedefs,
>> and ignored qualifiers, would it cause any problem? It sounds considerably
>> user friendly for me.
>>
>>
>> On 8 October 2012 10:31, Daniel Jasper <djasper at google.com> wrote:
>>>
>>> We actually had a longish discussion whether we wanted to have the
>>> asString-matcher at all. The problem is that there is no canonical way
>>> to convert a Type to a string. As an easy example, you could write in
>>> the code "const int a;" or "int const a;" and asString() would always
>>> give you "const int" (or the other, but where can you look that up?).
>>> We decided on including it simply wrapping QualType::asString() just
>>> because it is very convenient in some places. I don't see an easy way
>>> of making this a good general purpose user interface.
>>>
>>> On Sun, Oct 7, 2012 at 10:38 PM, Gábor Horváth <xazax.hun at gmail.com>
>>> wrote:
>>> > Hi!
>>> >
>>> > With "_Bool" it works flawlessly thanks. I wonder if isBoolean is an
>>> > user
>>> > friendly solution, as one might except to use asString with any type.
>>> > However I admint, making asString matcher able to match everything might
>>> > add
>>> > unnecessary complexity.
>>> >
>>> > Thanks,
>>> > Gábor
>>> >
>>> >
>>> > On 7 October 2012 22:21, Daniel Jasper <djasper at google.com> wrote:
>>> >>
>>> >> +cfe-dev
>>> >>
>>> >> Hi Gábor,
>>> >>
>>> >> I think the AST-internal-name of the type bool is '_Bool'. Can you try
>>> >> that with the asString-matcher? However, I think the right solution
>>> >> would be to write a matcher like:
>>> >>
>>> >> AST_MATCHER(QualType, isBoolean) {
>>> >>   return Node->isBooleanType();
>>> >> }
>>> >>
>>> >> Cheers,
>>> >> Daniel
>>> >>
>>> >> On Sun, Oct 7, 2012 at 10:06 PM, Gábor Horváth <xazax.hun at gmail.com>
>>> >> wrote:
>>> >> > Hi!
>>> >> >
>>> >> > I can't figure out how can I match bool types.
>>> >> >
>>> >> > First of all, I had a matcher like this:
>>> >> >
>>> >> >
>>> >> > classTemplateSpecializationDecl(hasAnyTemplateArgument(refersToType(asString("bool"))))
>>> >> >
>>> >> > but asString("bool") did not give me any match, however using any
>>> >> > other
>>> >> > types would. First of all, I thought, maybe bool is a typedef, and
>>> >> > that
>>> >> > can
>>> >> > cause the problem, so I alstered the asString matcher, to also check
>>> >> > the
>>> >> > name of the cannonical type.
>>> >> >
>>> >> > It looks now like this one:
>>> >> > AST_MATCHER_P(QualType, asString, std::string, Name) {
>>> >> >   return Name == Node.getAsString() || Name ==
>>> >> > Node.getCanonicalType().getAsString();
>>> >> > }
>>> >> >
>>> >> > However I still has no success.
>>> >> >
>>> >> > Thanks for your answer in advance,
>>> >> > Gábor
>>> >
>>> >
>>
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev




More information about the cfe-dev mailing list