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

[Abramo Bagnara]

Mike Stump ha scritto:
> On Aug 15, 2009, at 6:57 AM, Enea Zaffanella wrote:
>> 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.
> 
> I too don't think you should go that direction.  Imagine you have  
> clang libraries on the system as shared libraries used by 20 tools.   
> Do we want 20 copies of them or just 1.  That answer is just 1.  To do  
> that, each app that uses clang has to do so with the same unmodified  
> clang.  So, so achieve this, you'd want a hash or a map on the side  
> and put your data in it.

It's definitely clear that a shared library version of clang should
always use clang with the custom data macro defined to nothing.

This stated, it is nonetheless clear that the ability to attach
arbitrary data to AST nodes (for specifically compiled versions of the
library) is of great usefulness.

The library is less general but using a map it would be much less efficient.

Note that the reason to request this macro is the consideration that the
unconditional insertion of a void* in these nodes would be unacceptable
for those applications that does not need that.

The three vertices of the tradeoff triangle are efficiency vs.
generality vs. memory usage. Implementing the mechanism described in the
proposal we let the client decide what matters most for its own needs.