Recombining AST Nodes

I'm in the process of debugging (again) issues with anonymous struct
decls. I have the following basic structures located in a C source
file that I'm attempting to transform. I want to preserve the layout
of the structs.

  int A;

  int B;
    int C;

When I use my AST visitors, I can pick up the RecordDecl for the
struct definitions and the VarDecl for the variable definitions, but
the transformed code is outputted as:
  int A;
struct (anonymous) S;

I can view the RecordDecl as as TagDecl and save off a reference to it
if it is !isFreeStanding(), but how does one go about recombining the
declaration of "S" and the original TagDecl?

For the VarDecl ("S" in this case), I can determine whether or not its
an "ElaboratedType", but I'm not sure how to utilize the saved
reference to the RecordDecl:

if(isa<ElaboratedType>(SemaRef.Context.getBaseElementType(MyVarDecl))) {
   /// how do i recombine the VarDecl and the RecordDecl/TagDecl?

Hi John,

IIUC you are creating a new RecordDecl, manually replacing the old one with the new one in its DeclContext, and then printing it. As you seem to recognize this is the problematic line (recall this is from that DeclPrinter code I referenced the last time):

You need the FieldDecl (which should be the very next Decl* in the DeclContext after the old RecordDecl *) to have an elaborated type whose owned tag decl is the new RecordDecl you have created (which will be Decls[0] in that code); if it is thus, and if the RecordDecl you created is marked as !isFreeStanding(), it should print as you expect, I think.

To create that type, use the ASTContext::getElaboratedType(…) method, which accepts the OwnedTagDecl as an arg. (ASTContext manages the types to ensure there are not multiple copies of the same Type* floating around, IIUC.)

Then, I would probably also replace the existing FieldDecl with a newly Created one, in the same manner you replaced the RecordDecl *, only now Create it with the new type.

Hope that works — good luck,


David, thanks for the response. Please excuse my ignorance, but I'm a
bit confused as to the order this needs to occur. I'll try to
reiterate what you said as follows:

1. If a TagDecl that is !isFreeStanding() is found, create a new
RecordDecl to represent it and add it to the DeclContext
2. Save a reference to the newly created RecordDecl
3. The next FieldDecl whose TagDecl matches the new RecordDecl should
be found; at this point create a new ElaboratedType using that TagDecl
4. Create a new FieldDecl with the new ElaboratedType as the type

Is this the general process?

No that is not a general process — I assumed you had modified the AST by replacing the existing RecordDecl with a new one, and were printing the whole AST, due to the behavior you are getting, and given your description of your visitors as "transforming" the code, which RecursiveASTVisitors don’t do by default — they just visit it, not modifying anything. (Unless you're overriding TreeTransformer instead?)

But you might also be getting this behavior if you are manually printing each Decl you want, in a RecursiveASTVisitor. If this is the case, remember, struct { int i } s; is two distinct Decls, and that loop in DeclPrinter::VisitDeclContext that I linked to is necessary to get the proper printing behavior for such cases.

There’s not quite enough information to know exactly what you need to do, but let’s start with the advice that that if you are manually printing individual Decls (e.g. D->print(OS)), that won’t work for your case — you need to instead handle a DeclContext as a whole and perhaps just copy and paste the important parts of DeclPrinter::VisitDeclContext and other parts of DeclPrinter. If you’re still confused share a few more details — are you using RecursiveASTVisitor, are you printing from it, do you just want to print an output file etc.

Good luck,


David, thanks again for the response. We are indeed transforming the
AST using combinations of new Decl's via Create* and tree transforms.
This is code we're helping to maintain (not the original authors), so
its a bit disjunct.

The original code is here if you're interested:

Basically, in the FieldDecl iterator loop, the RecordDecl's for the
struct definition are stored in the new DeclContext, but the
FieldDecl's are recreated. I'm curious whether we check for an
ElaboratedType and if it exists for the target FieldDecl, utilize the
existing Decl for the new DeclContext.



John I think you’ve identified a bug: ElaboratedTypes are not being rebuilt with any OwnedTagDecl in TreeTransform.

The last arg to getElaboratedType is the OwnedTagDecl which defaults to nullptr — and that default is being passed here:

Perhaps you can try fixing that so RebuildElaboratedType requires an NewOwnedTagDecl arg, and pass it the transformed version of the old OwnedTagDecl, and see if that gets it to print properly.

  • Dave

David, for reference, the code we're porting (referenced above) is
being merged up to Clang 9.0.1 (pre mono-repo). The original
transform functions worked in Clang 3.9.0, so this may be a

That being said, I'm not sure I follow your potential solution.
Apologies for the naive response. I don't usually work in the AST.


  1. Go to your local lib/Sema/TreeTransform.h
  2. Add an OwnedTagDecl param to RebuildElaboratedType; i.e. is changed to:
QualType RebuildElaboratedType(SourceLocation KeywordLoc,
ElaboratedTypeKeyword Keyword,
NestedNameSpecifierLoc QualifierLoc,
QualType Named,
TagDecl *OwnedTagDecl) {
return SemaRef.Context.getElaboratedType(Keyword,
  1. Pass the proper arg in TransformElaboratedType, i.e. change to
TagDecl *NewOwnedTagDecl = T->getOwnedTagDecl() ? TransformDecl(SourceLocation(), T->getOwnedTagDecl()) : nullptr;
Result = getDerived().RebuildElaboratedType(TL.getElaboratedKeywordLoc(),
QualifierLoc, NamedT,

See if that works.

David, thanks again for helping debug this. Your fix required some
additional work to the template definitions for RebuildElaboratedType,
but this was otherwise successful! If anyone is interested in the
patch, we have a single commit on our (modified) Clang 9.0.1 repo

The patch is simple enough that it can easily be merged into vanilla
Clang 9.0.1 repos.

David, I sincerely appreciate your ongoing help in debugging this.