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



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to