[cfe-dev] Matching bools

[Daniel Jasper]

I think, that is the exact thing you CANNOT do. AFAIK, asString()
gives you a string representation of the type as the AST sees fit, not
as you have written it in the source.

On Mon, Oct 8, 2012 at 8:29 PM, Matthieu Monrocq
<matthieu.monrocq at gmail.com> wrote:
> Actually, I would say there is value in asString. I could write a pass
> to rewrite all "const int" as "int const" using it for example,
> precisely because it matches text.
>
> On the other hand, it might be worth using a regex here, or at least
> get rid of whitespace sensitivity (compressing all blanks to a single
> space), if it is really to be used that way.
>
> -- Matthieu
>
> On Mon, Oct 8, 2012 at 2:52 PM, Daniel Jasper <djasper at google.com> wrote:
>> I think we should not change the name. We are trying to model the
>> matchers as closely as possible to original AST methods and this case
>> is no exception. We can put a warning into the comment but I don't
>> know, how much good this will do.
>>
>> I am not sure what you are referring to with "autotest". I think that
>> test cases are a very good example of where using asString makes
>> sense. It makes them more readable and with the well-controlled
>> environment you are quite sure that asString matches what you think it
>> should match.
>>
>>
>> On Mon, Oct 8, 2012 at 2:29 PM, Gábor Horváth <xazax.hun at gmail.com> wrote:
>>> It would be great, to mark it as a temporary or internal solution. However
>>> for example there are several autotest using asString, in this case it would
>>> be great, to use it as little as possible.
>>>
>>>
>>> On 8 October 2012 14:17, Manuel Klimek <klimek at google.com> wrote:
>>>>
>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev