[cfe-dev] Feature proposal: adding optional custom info to clang AST nodes.

[Enea Zaffanella]

Hello.

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:

#define CLANG_CLIENT_CUSTOM_INFO

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?

Cheers,
Enea Zaffanella.