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

[David Blaikie via cfe-dev]

On Tue, Apr 28, 2020 at 3:09 AM Artem Dergachev via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> 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.
>

What functionality do you picture the scan-build-like tool having that
couldn't be supported if that tool instead built a compilation database &
the CTU/CSA was powered by the database? (that would separate concerns:
build command discovery from execution, and make scan-build-like tool more
general purpose, rather than specific only to the CSA)


>
> 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
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200428/3d217d69/attachment.html>