[cfe-dev] clang::Stmt, what's a child?

Eric Niebler eric at boostpro.com
Wed Feb 23 23:38:09 PST 2011

On 2/24/2011 2:26 PM, John McCall wrote:
> On Feb 23, 2011, at 11:02 PM, Eric Niebler wrote:
>> With my change, the AST for *both* will be stored under a new node type.
>> So, what should child_begin and child_end iterate over for this node
>> type? (My hunch is that only the rewritten node is really a child.)
> Yes, I think only the nodes that will actually be executed should be
> "children" in that sense;  thus the rewritten tree and any tree whose
> values will be bound to OpaqueValueExprs, but not the OVEs
> themselves.

Ah, interesting. Thanks, John. Let's take the example AST you posted in
a previous thread:

  (PropertyAccessOperator int
    # The original operand, for source fidelity
    (MemberExpr int lvalue property
      (DeclRefExpr "obj" Obj lvalue))
    # The opaque value expression
    (OpaqueValueExpr 0xabcdef Obj lvalue)
    # The expression whose result the OpaqueValueExpr will be bound to
    (DeclRefExpr "obj" Obj lvalue)
    # The expression to evaluate, expressed in terms of the OVE
    (CXXMemberCallExpr void
      (MemberExpr void(int) .setBase
        (OpaqueValueExpr 0xabcdef Obj lvalue))
      (CXXMemberCallExpr int
        (MemberExpr PropTy() .getBase
          (OpaqueValueExpr 0xabcdef Obj lvalue)))))

I was thinking that only the last subexpr of PAO (the "expression to
evaluate") should be a logical "child" of PAO. But you seem to be saying
that the third subexpr above (the "expression whose result the
OpaqueValueExpr will be bound to") should also be a logical child.

This seems reasonable, but I just want to make sure that's really what
you are suggesting.

Eric Niebler
BoostPro Computing

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 551 bytes
Desc: OpenPGP digital signature
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110224/e3feaab0/attachment.sig>

More information about the cfe-dev mailing list