[cfe-dev] ASTContext::getParents discussion

[Rafael·Stahl via cfe-dev]

Hi all,

while developing a custom checker I encountered the following issue 
related to the getParents member function of the ASTContext.

My checker was using ACtx->getParents in a callback and I noticed that 
sometimes parents were missing. After some debugging it turned out that 
this occurs when:

- Using the Clang Static Analyzer with Cross Translation Unit (CTU) analysis
- Checker callback is called once, getParent builds a Parent Map to 
cache this CPU heavy task
- The CTU uses the ASTImporter to import a function defined in another 
TU, this modifies the AST, introducing new parents.
- Checker callback is called again, now getParents will use the old 
Parent Map

My fix was to introduce ASTContext::invalidateParents which would be 
called by the ASTImporter on every AST mutation. That way, the Parent 
Map would only have to be rebuilt if it was invalidated before a 
getParents call. This is the patch: https://reviews.llvm.org/D46940

Richard expressed some concerns about this patch, to summarize (full: 
https://reviews.llvm.org/D46940#1147456 ):

- Other entities besides the ASTImporter could mutate the AST, so the 
responsibility of invalidation should lie with the consumer of the 
Parent Map
- The Parent Map should not be in the ASTContext at all, really in 
libTooling

While I understand these concerns, a solution like that does not solve 
my use-case described above. If I create a new Parent Map on every 
callback invocation, my checker becomes unusably slow. And if I cache 
it, I do not know when it is invalidated.

Another idea I had was to introduce invalidation callbacks to the 
Checker, Analyzer and ASTImporter interfaces, in order to carry the 
invalidation trigger up to a user defined checker. This doesn't seem 
very elegant though.

I wanted to start a discussion to find a solution to this. Do you have 
any ideas or input?

-Rafael


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5449 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190404/2cfa7b8d/attachment.bin>