This change is obsolete in the current code. Casting related changes do not look important (and should be a new patch anyway).

A "quick fix" for the problem:
https://reviews.llvm.org/D66538

Example about how to get wrong things into NonEquivalentDecls:
We want to compare class C for structural equivalence in the following codes:

class A {}; class B {int i;}; void x(A *); void y(A *); class C { friend void x(A *); friend void y(A *); };

and

class A {}; class B {int i;}; void x(A *); void y(B *); class C { friend void x(A *); friend void y(B *); };

The result is false for C but the NonEquivalentDecls will contain after the compare a void x(A*)<->void x(A*) pair.

LLDB probably does the import in other way. CTU test fails without the fix:

FAIL: Clang :: Analysis/ctu-main.cpp (540 of 15341)
******************** TEST 'Clang :: Analysis/ctu-main.cpp' FAILED ********************
Script:
--
: 'RUN: at line 1';   rm -rf build/Release/tools/clang/test/Analysis/Output/ctu-main.cpp.tmp && mkdir build/Release/tools/clang/test/Analysis/Output/ctu-main.cpp.tmp
: 'RUN: at line 2';   mkdir -p build/Release/tools/clang/test/Analysis/Output/ctu-main.cpp.tmp/ctudir
: 'RUN: at line 3';   build/Release/bin/clang -cc1 -internal-isystem build/Release/lib/clang/10.0.0/include -nostdsysteminc -triple x86_64-pc-linux-gnu    -emit-pch -o build/Release/tools/clang/test/Analysis/Output/ctu-main.cpp.tmp/ctudir/ctu-other.cpp.ast llvm-project/clang/test/Analysis/Inputs/ctu-other.cpp
: 'RUN: at line 5';   build/Release/bin/clang -cc1 -internal-isystem build/Release/lib/clang/10.0.0/include -nostdsysteminc -triple x86_64-pc-linux-gnu    -emit-pch -o build/Release/tools/clang/test/Analysis/Output/ctu-main.cpp.tmp/ctudir/ctu-chain.cpp.ast llvm-project/clang/test/Analysis/Inputs/ctu-chain.cpp
: 'RUN: at line 7';   cp llvm-project/clang/test/Analysis/Inputs/ctu-other.cpp.externalDefMap.txt build/Release/tools/clang/test/Analysis/Output/ctu-main.cpp.tmp/ctudir/externalDefMap.txt
: 'RUN: at line 8';   build/Release/bin/clang -cc1 -internal-isystem build/Release/lib/clang/10.0.0/include -nostdsysteminc -analyze -analyzer-constraints=range -triple x86_64-pc-linux-gnu    -analyzer-checker=core,debug.ExprInspection    -analyzer-config experimental-enable-naive-ctu-analysis=true    -analyzer-config ctu-dir=build/Release/tools/clang/test/Analysis/Output/ctu-main.cpp.tmp/ctudir    -verify llvm-project/clang/test/Analysis/ctu-main.cpp
: 'RUN: at line 13';   build/Release/bin/clang -cc1 -internal-isystem build/Release/lib/clang/10.0.0/include -nostdsysteminc -analyze -analyzer-constraints=range -triple x86_64-pc-linux-gnu    -analyzer-checker=core,debug.ExprInspection    -analyzer-config experimental-enable-naive-ctu-analysis=true    -analyzer-config ctu-dir=build/Release/tools/clang/test/Analysis/Output/ctu-main.cpp.tmp/ctudir    -analyzer-config display-ctu-progress=true 2>&1 llvm-project/clang/test/Analysis/ctu-main.cpp | build/Release/bin/FileCheck llvm-project/clang/test/Analysis/ctu-main.cpp
--
Exit Code: 134

• Moved 'ctor initializer' import before import of body.

• Moved SVEBuiltins test instantiation to non-different position.

• Using StringRef, added comment.

In this case the problem was that some of the flags of the already created and inserted ToFunction are not initialized. During the import of some "ctor initializers" this non-complete ToFunction may be accessed somehow (by structural equivalence or other code) and an assert comes because invalid value. (Maybe in the test code the second constructor is imported as "ctor initializer" during the import of the first.)

• [CrossTU] Fix problem with CrossTU AST load limit and progress messages.
• Reformat.

Rename of variables and reformat.

I discovered that there are problems with this change. The number of loaded AST units is not incremented correctly and the "CTU loaded AST file" is displayed for every access to a AST unit (even if it was got from cache). The problem is that the counting and print of AST loads does not handle the case when the load returned a cached result (and no real loading happened). This causes "annoying" messages and the AST unit limit is not handled correctly.

Yes importing the parameters should be doable after the create of the function. I am not sure if it fixes this problem, the parameter that has the default expression can still be encountered without the default expression set in it.

Rebase.

Small but important fix.

A new kind of solution, the previous does not work always.
Still no test for this new problem case (circular dependency between a ParmVarDecl and function of it and a CXXDefaultArgExpr that references to the function probably by UsedContext).

Rebase and add a new testing case.

Probably this is a problem case too but only if the f or i has an initializer expression and really no USR is generated for f or i. But what I have found is that there is a VarDecl for a "invisible" variable whose type is the anonymous union and it has a (default) initializer too. If the search reaches DC of the f it will try to get the USR for this variable.

It looks like that the problem can happen when the anonymous union is in any DeclContext and for CTU import the import of a variable is requested and that variable is in a related DeclContext (it can be at upper or lower level). (See code of findDefInDeclContext: If used for variables, it goes through every DeclContext and computes USR for specific VarDecls until the one is found. If we have luck it may be found before the union. An anonymous union can not be imported because we get no USR for it so it is OK to ignore these.) So the test can be written in many other forms but this case (the code of f) was encountered in protobuf code.

Added missing test fixture, removed not a related change.

Problem should be fixed now (r367013).

Added clangFrontend to CMakeLists.txt.

The Frontend is needed because "ASTUnit.h" is added now into PlistDiagnostics.cpp. The ASTUnit object is used to pass information out from getImportedFromSourceLocation. The StaticAnalyzerCore library uses CrossTU library, and CrossTU uses Frontend, so I think it may be not a problem if StaticAnalyzerCore will use directly Frontend. Otherwise the getImportedFromSourceLocation can return the Preprocessor (and ASTContext) (in a tuple) instead of an ASTUnit and use of ASTUnit is not needed. (Patch in D65064 contains a test that does work only if the TranslationUnitDecl of the imported-from AST is known, to get this value an ASTUnit or ASTContext must be returned from getImportedFromSourceLocation.)

Update diff to one commit with all changes.

Maybe CrossTU should not use the Frontend library? (Now the StaticAnalyzerCore is using CrossTU and CrossTU is using Frontend, in this way StaticAnalyzerCore could use Frontend too.)

It is possible to use the Preprocessor instead of ASTUnit in getImportedFromSourceLocation. But this will contain less useful (even if currently not used) information. The test extension in D65064 is not possible to do if not ASTUnit is used. (Or a tuple must be used that contains Preprocessor and TranslationUnitDecl and maybe other objects that are stored in the ASTUnit.)

Removed ASTImporter from "callback" function.

New patch:
https://reviews.llvm.org/D65064

@ilya-biryukov Please check if it is acceptable to use ASTUnit in PlistDiagnostic.cpp.

Commit was reverted because we were not aware of that clangAST library can not use clangFrontend library. So a different solution is needed, probably pass a SourceLocation import callback to ASTImporter. (A Preprocessor that can be used in place of ASTUnit here can not be get from a SourceManager or ASTContext.) And then no ImportedFileIDs is needed in ASTImporterSharedState, instead in CrossTranslationUnitContext.

• Renamed 'Unit', changed constructors.

I do not know how the AST import is relevant in this case, the 'implicit' function is not imported here. The test does something similar as the mentioned one, only the reported problem is after the imported function.

In D64477#1585092, @martong wrote:

Does it really matter if it is CXX11 or CXX14, in the child patch we use a CXX11 using directive. Anyway, CXX14 is more future proof.

• Change to Lang_CXX14.