Question: Preprocessor conditionals and the AST, with respect to modularize
silvas at purdue.edu
Thu Apr 18 16:43:09 PDT 2013
On Thu, Apr 18, 2013 at 3:49 PM, Thompson, John <
John_Thompson at playstation.sony.com> 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.
> ** **
> 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 <
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits