[PATCH] D30691: [analyzer] Support for naive cross translational unit analysis

[Gábor Horváth via Phabricator via cfe-commits]

xazax.hun marked 2 inline comments as done.
xazax.hun added a comment.

In https://reviews.llvm.org/D30691#731617, @zaks.anna wrote:

> I agree that scan-build or scan-build-py integration is an important issue to resolve here. What I envision is that users will just call scan-build and pass -whole-project as an option to it. Everything else will happen automagically:)


We contacted Laszlo and we have a pull request into scan-build that is under review. He is very helpful and supports the idea of scan-build-py supporting CTU analysis.

> I do not quite understand why AST serialization is needed at all. Can we instead recompile the translation units on demand into a separate ASTContext and then ASTImport?

We did a prototype implementation of on-demand reparsing. On the C projects we tested, the runtime is increased by 10-30% compared to dumping the ASTs. Note that, it is relatively fast to parse C, I would expect a much bigger delta in case of C++ projects. Unfortunately, we weren't able to test that setting due to the ASTImporter limitations.



================
Comment at: include/clang/AST/Mangle.h:59
+  // the static analyzer.
+  bool ShouldForceMangleProto;
 
----------------
xazax.hun wrote:
> dcoughlin wrote:
> > I'm pretty worried about using C++ mangling for C functions. It doesn't ever seem appropriate to do so and it sounds like it is papering over problems with the design.
> > 
> > Some questions:
> > - How do you handle when two translation units have different C functions with the same type signatures? Is there a collision? This can arise because of two-level namespacing or when building multiple targets with the same CTU directory.
> > - How do you handle when a C function has the same signature as a C++ function. Is there a collision when you mangle the C function?
> I agree that using C++ mangling for C+ is not the nicest solution, and I had to circumvent a problem in the name mangler for C prototypes.
> 
> In case a mangled name is found in multiple source files, it will not be imported. This is the way how collisions handled regardless of being C or C++ functions. 
> The target arch is appended to the mangled name to support the cross compilation scenario. Currently we do not add the full triple, but this could be done.
> 
> An alternative solution would be to use USRs instead of mangled names but we did not explore this option in depth yet. 
Note that the newest version of this patch does not use name mangling, it uses USRs instead. This turned out to be a perfectly viable alternative and we did not see any behavioral changes on the project we tested after the transition.


https://reviews.llvm.org/D30691