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

[steve naroff]

On Aug 15, 2009, at 9:57 AM, Enea Zaffanella wrote:

> 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?
>

Why not use a map that associates the original AST with 'my_data'?

snaroff

> Cheers,
> Enea Zaffanella.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev