Question: Preprocessor conditionals and the AST, with respect to modularize

[Sean Silva]

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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130418/cab6ec34/attachment.html>