[PATCH] D75665: [analyzer] On-demand parsing capability for CTU

[Gabor Marton via Phabricator via cfe-commits]

martong added a comment.

In D75665#1971440 <https://reviews.llvm.org/D75665#1971440>, @gamesh411 wrote:

> In D75665#1907914 <https://reviews.llvm.org/D75665#1907914>, @martong wrote:
>
> > The warning below suggests that we parse the ctu-other.c file (and presumably every file) as a C++ file, even if it should be parsed as a C file. Perhaps the invocation of the parser is missing some setting? Also, could this be the reason why on-the-fly and pch driven ctu gives different statistics?
> >
> >   warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]
> >   /mnt/disks/ssd0/agent/workspace/amd64_debian_testing_clang8/clang/test/Analysis/Inputs/ctu-other.c:47:26: error: 'DataType' cannot be defined in a parameter type
> >   int structInProto(struct DataType {int a;int b; } * d) {
> >                            ^
> >   1 error generated.
> >   Error while processing /mnt/disks/ssd0/agent/workspace/amd64_debian_testing_clang8/clang/test/Analysis/Inputs/ctu-other.c.
> >  
> >
>
>
> I have investigated the issue, and the compiler flags were looked up using the heuristic implemented in tooling.
>  This heuristic looks for the suitable compilation database in an upward ascending fashion inside the directory tree startin from the input source file.
>  By copying both the source file and the compilation database to the test directory this heuristic does the right thing now. (up until now the found compile_commands.json was the one used for llvm-project itself, and picked up a c++ specific compilation).
>
> This issue is solved, however the ASTImporter still cannot import the inline definition of the struct, and emits an error.
>  Right now I am debugging the master branch that uses the AST-dumps wheter I also encounter this error inside the ASTImporter (just to see if I am operating on sane assumptions).


I've been looking into this and the ASTImporter indeed does not (cannot) import the definition of `structInProto()`. But that's just fine, that is why we have a branching for the call expression (TRUE/FALSE) below in ctu-main.c . All other functions whose definition were imported gives only the TRUE branch.

  clang_analyzer_eval(structInProto(&d) == 0); // expected-warning{{TRUE}} expected-warning{{FALSE}}


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75665/new/

https://reviews.llvm.org/D75665