[PATCH] D108283: [flang][driver] Add documentation for Plugins

Peter Klausler via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 13 14:01:15 PDT 2021


klausler added a comment.

In D108283#2998414 <https://reviews.llvm.org/D108283#2998414>, @kiranchandramohan wrote:

> Can it be made to look like the RecursiveASTVisitor of Clang?
>
>   class FindNamedClassVisitor
>     : public RecursiveASTVisitor<FindNamedClassVisitor> {
>   public:
>     explicit FindNamedClassVisitor(ASTContext *Context) : Context(Context) {}
>   
>     bool VisitCXXRecordDecl(CXXRecordDecl *Declaration) {
>       return true;
>     }
>   
>   private:
>     ASTContext *Context;
>   };

Yes, although I've used the more idiomatic `operator()` as the member function for better composability with the STL, and recommend it again here, if you choose to replace Pre()/Post().

> I guess it is OK to proceed with warnings and caveats either in this patch or an immediate follow-up patch. Something like the following based on @klausler's points.
> Plugin writers should note the following,
> -> The traversal API will change in the immediate future.
> -> The parse-tree classes and enums will change as Flang development progresses. 
> -> The current parse-tree structure is not suitable for modifications. Also, the copy constructors are not available and hence duplicating code might not be trivial.
> -> If parse-tree modifications are performed, then it might be necessary to re-analyze expressions and modify scope or symbols.

Note that it seems straightforward to add some preprocessing shenanigans to parse-tree.h that could be used to not disable copy constructors when parse-tree.h is included in plug-ins.

You could also consider extending Semantics with an API that scrubs the parse tree of all its decorations, so that it could be used as input to a fresh instantiation of Semantics so that the whole source file could be re-analyzed after parse tree modifications.

(It won't be surprising to users of clang plug-ins, but people experienced in Fortran might not be expecting f18 to work on whole source files at once instead of the traditional Fortran approach of compiling each program unit independently.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108283/new/

https://reviews.llvm.org/D108283



More information about the llvm-commits mailing list