Our application uses clang to parse a program, build the corresponding AST and then visit the AST so as to collect many kinds of info. Our visitors typically exploit functionality provided by clang AST nodes.
However, sooner or later, we face the need to collect and cache additional info which is of interest for our visitors only: being ad-hoc, this info cannot be arbitrarily stored in clang AST nodes; on the other hand, storing it in the clang AST nodes would result in maximum efficiency, since we would avoid the need to maintain and query (potentially huge) data structures whose only purpose is to map a clang AST node into the corresponding additional info.
For the reasons above, we would like to propose a minor modification to the definition of the classes at the root of the clang AST hierarchy that, when enabled via a suitable configuration option, would let clients add arbitrary info to the clang AST nodes.
The basic idea is to have a new header file defining a suitable macro (e.g., CLANG_CLIENT_CUSTOM_INFO): the name of the header file will be fixed, but its content will be controlled by a clang configuration option. All the root classes for AST nodes (i.e., Decl, Stmt, Type) will include such a header file and will invoke the macro in their public section.
By default, when the customization mechanism is disabled, the macro will expand to no text at all, so as to incur zero overhead:
When customization is enabled, the macro will instead expand to whatever data the client might need; for instance:
#define CLANG_CLIENT_CUSTOM_INFO void* my_data;
Clearly, the client will be responsible of all the problems related with the management of customly allocated resources.
Does this approach sound reasonable?
Do you foresee better alternatives?