This is an archive of the discontinued LLVM Phabricator instance.

[clang][AST] Added some missing setter methods
AbandonedPublic

Authored by strimo378 on Aug 16 2023, 12:22 AM.

Details

Reviewers
aaron.ballman

Diff Detail

Event Timeline

strimo378 created this revision.Aug 16 2023, 12:22 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 16 2023, 12:22 AM
strimo378 requested review of this revision.Aug 16 2023, 12:22 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 16 2023, 12:22 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

I added some missing (simple) setter methods to Decl and Expr classes. I did not comment them since typically simple setter methods are uncommented.

We typically only add these sorts of functions when we need them; do you have a need to add setters? (Oftentimes, we don't want setters because we want the AST nodes to be created in the correct state when possible; we do add some setters because of AST deserialization where we need to create an empty shell AST node and fill it out piecewise as we deserialize.)

strimo378 added a comment.EditedAug 17 2023, 3:01 AM

Yes, I have a need for these setters :) but I cannot decide if the LLVM project in general or other people could profit from it.

I am working on a C++-to-C transpiler based on clang. Other clang-based tool typically modify the intput file based on FileLocation information. In contrast, I follow a constructive approach with AST print. The transpiler is organized in many small passes that transform the clang AST until at the end I can output the C code via AST print. Some notable passes are

  • Remove unused AST decls (simplifies AST for non-trivial input)
  • Resolve templates (is also useful standalone to remove templates from a C++ program)
  • Resolve namespaces
  • Move nested records
  • Convert methods to functions
  • etc.

For transforming the AST, I often need to replace Types and regenerate the corresponding TypeLoc. I tried for over one year to recreate AST nodes when a setter methods was missing but that caused a lot of work and instabilities for maintaining cross references. For that reason, I now insert a new setter method when needed and until now surprising less setter methods are missing.

For me it takes 5-10 min per version upgrade to port the changes, so it is not a big deal for me if you refuse them. I have some other AST modification in place for removing templates information but nothing complex...

Yes, I have a need for these setters :) but I cannot decide if the LLVM project in general or other people could profit from it.

I am working on a C++-to-C transpiler based on clang. Other clang-based tool typically modify the intput file based on FileLocation information. In contrast, I follow a constructive approach with AST print. The transpiler is organized in many small passes that transform the clang AST until at the end I can output the C code via AST print. Some notable passes are

  • Remove unused AST decls (simplifies AST for non-trivial input)
  • Resolve templates (is also useful standalone to remove templates from a C++ program)
  • Resolve namespaces
  • Move nested records
  • Convert methods to functions
  • etc.

For transforming the AST, I often need to replace Types and regenerate the corresponding TypeLoc. I tried for over one year to recreate AST nodes when a setter methods was missing but that caused a lot of work and instabilities for maintaining cross references. For that reason, I now insert a new setter method when needed and until now surprising less setter methods are missing.

For me it takes 5-10 min per version upgrade to port the changes, so it is not a big deal for me if you refuse them. I have some other AST modification in place for removing templates information but nothing complex...

Thank you for the detailed explanation! I think we should probably skip adding these until there's an in-tree need for them. Given that we don't want the AST to be mutable once it's been constructed, I think adding setters gives the wrong impression and we should continue to use friend to give limited access to interfaces that need the mutability.

strimo378 abandoned this revision.Aug 17 2023, 3:14 PM

Alright, thank you for the review...