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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
