match OffsetOfExpr

Anyone know how to match OffsetOfExpr?

-FunctionDecl 0x2484fff0298 <line:9:1, line:12:1> line:9:13 used f1 ‘void ()’ static
-CompoundStmt 0x2484fff03c8 <line:10:1, line:12:1> -OffsetOfExpr 0x2484fff0390 <C:\Program Files\LLVM\lib\clang\10.0.0\include\stddef.h:104:24, col:47> ‘unsigned long long’

In clang-query if I type: m offsetOfExpr() is says: matcher not found.

Anyone know how to match OffsetOfExpr?

>-FunctionDecl 0x2484fff0298 <line:9:1, line:12:1> line:9:13 used f1 'void ()' static
> `-CompoundStmt 0x2484fff03c8 <line:10:1, line:12:1>
> `-OffsetOfExpr 0x2484fff0390 <C:\Program Files\LLVM\lib\clang\10.0.0\include\stddef.h:104:24, col:47> 'unsigned long long'

In clang-query if I type: m offsetOfExpr() is says: matcher not found.

We don't currently expose a matcher for it, so that's why it's not
found. It wouldn't be difficult to add a matcher for it, however (feel
free to add me as a review if you decide to author a patch for this).

~Aaron

Hi,

I don’t know how it should be matched, using classOf, dyn_cast, or isa.

I tried:

namespace
{
AST_MATCHER(clang::Stmt, isOffsetOf) { return clang::isaclang::OffsetOfExpr(&Node); }
}

and still doesn’t match.

You can use a VariadicDynCastAllOfMatcher<Stmt, OffsetOfExpr> like the other matchers
for statements/expressions. That said, why are we manually adding matchers for each nodes?
It seems to me that they could be auto-generated from the statement/declaration/type databases.

~Bruno

> Hi,
>
> I don't know how it should be matched, using classOf, dyn_cast, or isa.
>
> I tried:
>
> namespace
> {
> AST_MATCHER(clang::Stmt, isOffsetOf) { return clang::isa<clang::OffsetOfExpr>(&Node); }
> }
>
> and still doesn't match.
>

You can use a VariadicDynCastAllOfMatcher<Stmt, OffsetOfExpr> like the other matchers
for statements/expressions. That said, why are we manually adding matchers for each nodes?
It seems to me that they could be auto-generated from the statement/declaration/type databases.

Each matcher we add increases the compile time overhead due to the
template instantiations involved, so we typically only add global
matchers where there's an expressed need for one rather than try to
add matchers for the entire AST automatically. That said, for node
matchers, I wonder how far off we are from supporting all node types
already (like, do we need 10 matchers? 100?). If we're only missing a
handful, then it might sense to consider auto-generating them all at
this point (and shifting the concern to traversal or narrowing
matchers), depending on how many we're missing.

~Aaron

You can use a VariadicDynCastAllOfMatcher<Stmt, OffsetOfExpr> like the other matchers
for statements/expressions. That said, why are we manually adding matchers for each nodes?
It seems to me that they could be auto-generated from the statement/declaration/type databases.

Each matcher we add increases the compile time overhead due to the
template instantiations involved, so we typically only add global
matchers where there's an expressed need for one rather than try to
add matchers for the entire AST automatically. That said, for node
matchers, I wonder how far off we are from supporting all node types
already (like, do we need 10 matchers? 100?). If we're only missing a
handful, then it might sense to consider auto-generating them all at
this point (and shifting the concern to traversal or narrowing
matchers), depending on how many we're missing.

~Aaron

For types we have 32/59
For decls we have 47/94
For stmts we have 92/227, or 91/168 excluding the OpenMP nodes.

But note that the above count also includes abstract nodes.

~Bruno

>>
>> You can use a VariadicDynCastAllOfMatcher<Stmt, OffsetOfExpr> like the other matchers
>> for statements/expressions. That said, why are we manually adding matchers for each nodes?
>> It seems to me that they could be auto-generated from the statement/declaration/type databases.
>
> Each matcher we add increases the compile time overhead due to the
> template instantiations involved, so we typically only add global
> matchers where there's an expressed need for one rather than try to
> add matchers for the entire AST automatically. That said, for node
> matchers, I wonder how far off we are from supporting all node types
> already (like, do we need 10 matchers? 100?). If we're only missing a
> handful, then it might sense to consider auto-generating them all at
> this point (and shifting the concern to traversal or narrowing
> matchers), depending on how many we're missing.
>
> ~Aaron
>
For types we have 32/59
For decls we have 47/94
For stmts we have 92/227, or 91/168 excluding the OpenMP nodes.

But note that the above count also includes abstract nodes.

Given those counts, I'd say we're probably not to the point where it
makes sense to generate node matchers automatically.

~Aaron

Just an update on this:
This matcher works fine in Linux.
When I said it didn’t work, that was on Windows.

Just an update on this:
This matcher works fine in Linux.
When I said it didn't work, that was on Windows.

An OffsetOfExpr is only generated when parsing __builtin_offsetof, so
my guess is that the macro for offsetof is expanding to address
arithmetic for you rather than a call to __builtin_offsetof.

~Aaron

> Just an update on this:
> This matcher works fine in Linux.
> When I said it didn't work, that was on Windows.

An OffsetOfExpr is only generated when parsing __builtin_offsetof, so
my guess is that the macro for offsetof is expanding to address
arithmetic for you rather than a call to __builtin_offsetof.

~Aaron

In cases where offsetof expands to the arithmetic, this will not match.
That is probably reason in itself to not make a matcher for this.
It would just result in confusing users wondering why offsetOfExpr
isn't matching offsetof in their source code.

~Nathan