[cfe-dev] [analyzer][tooling] Architectural questions about Clang and ClangTooling

[Artem Dergachev via cfe-dev]

Hey!

1. I'm glad that we're finally trying to avoid dumping PCH-s on disk!

2. As far as I understand, dependencies are mostly about Clang binary 
size. I don't know for sure but that's what I had to consider when I was 
adding libASTMatchers into the Clang binary a few years ago.

3. I strongly disagree that JSON compilation database is "just right for 
this purpose". I don't mind having explicit improved support for it but 
I would definitely prefer not to hardcode it as the only possible 
option. Compilation databases are very limited and we cannot drop 
projects or entire build systems simply because they can't be 
represented accurately via a compilation database. So I believe that 
this is not the right solution for CTU in particular. Instead, an 
external tool like scan-build should be guiding CTU analysis and 
coordinate the work of different Clang instances so that to abstract 
Clang away from the build system.

On 4/28/20 11:31 AM, Endre Fülöp via cfe-dev wrote:
>
> Hi!
>
> Question:
>
> Why is the dependency on ClangTooling ill-advised inside ClangSA (also 
> meaning the Clang binary) itself ?
>
> Context:
>
> Currently I am working on an alternative way to import external TU 
> AST-s during analysis ( https://reviews.llvm.org/D75665 ).
>
> In order to produce AST-s, I use a compilation database to extract the 
> necessary flags, and finally use ClangTool::buildAST.
>
> I am aware that I have other options for this as well (like manually 
> coding the compdb handling for my specific case for the
>
> first step, and maybe even dumping ASTs as pch-s into an in-memory 
> buffer), but still consuming JSONCompilationDatabase
>
> is just too convenient. I would not want to introduce another format 
> when compilation database is just right for this purpose.
>
> Elaboration:
>
> While I understand that introducing dependencies has its downsides, 
> but not being able to reuse code from Tooling is also not ideal.
>
> I would very much like to be enlightened by someone more familiar with 
> architectural decision already made why this is the case,
>
> and optionally how I could proceed with my efforts so that I can come 
> up with the most fitting solution i.e. not a hack.
>
> Thanks,
>
> Endre Fülöp
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev