Matching bools

+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

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

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.

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

+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

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.

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.

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

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.

Yep. Replacing “const int” with “int const” really seems like a task for sed.