Is there a way to find the association of an AST sub-tree with its enclosing preprocessor conditionals?
It seems there is not, and the conditional stack is transitory anyway. Any ideas on a not-too-painful way to do this from a tool (i.e. modularize)? Here's one idea. Set up a hook so that modularize could have a callback called whenever a preprocessor conditional block is entered or exited. This callback would record the state of the conditional stack such that the tool could give messages referring to conditional source locations. Also set up a hook so that a callback could be called whenever a declaration node is added to the AST. (Is there already any sort of callback mechanism for when AST nodes are added?) This callback would associate the declaration node with the conditional stack state. (This raises the question of how to make the association. Save it as an attribute? Maintain an external table?) When modularize finds its "not always provided" items, it could look up the association and display the preprocessor conditionals involved. Does it even make sense to attempt to something like this in modularize? This has arisen because while running modularize on a large group of headers, I found it a little difficult to manually inspect the code to find the involved conditionals. Or, maybe we don't need to involve the AST at all. Maybe for each header seen by modularize, just create a tree of the conditionals per file, linked with that of nested include files, and save the path through the enabled blocks, this through a callback mechanism. Then, add a check to modularize that checks whether the collected paths for individual headers are the same. If not, it can display the conflicting paths. Or, maybe we combine the two schemes, such that the "not always provided" messages could refer to the conflicting paths. Thanks. -John
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
