[cfe-dev] Matching bools

[Matthieu Monrocq]

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