On Thu, Apr 18, 2013 at 3:49 PM, Thompson, John < [email protected]> wrote:
> 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. > That seems reasonable. See clang::Preprocessor::addPPCallbacks and the PPCallbacks class itself < http://clang.llvm.org/doxygen/classclang_1_1PPCallbacks.html>. > 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?) > You could use PPCallbacks to turn the transitory preprocessor callback events into a fixed data structure ("AST") representing the structure of preprocessor directives. I can think of many other places where a "PPAST" like that could be useful. Once that structure is obtained, then the association can be made by looking at the SourceLocation's/SourceRange's that Clang so religiously stores for the AST nodes. Source range intersection and subrange inclusion tests can be done efficiently using e.g. an augmented red-black tree (we might have something in ADT up to the job since these kinds of range/interval operations are reminiscent of the needs of register allocators (maybe ADT/IntervalMap.h?)). > When modularize finds its “not always provided” items, it could look up > the association and display the preprocessor conditionals involved.**** > > ** > That would be nice. > ** > > 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.**** > > ** > I think it's a good idea if it translates to significantly improved usability of the tool. > ** > > 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. > I really like this idea. -- Sean Silva
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
