[PATCH] D62131: [ASTImporter] Remove NonEquivalentDecls from ASTImporter

martong added a comment. > ... it is highly probable that if some pairs were ever non-equivalent they > will stay non-equivalent. This may not be true in case of LLDB, because usually they do a minimal import, and in a later phase they do a normal import which imports e.g. the members of a cla

[PATCH] D62131: [ASTImporter] Remove NonEquivalentDecls from ASTImporter

martong abandoned this revision. martong added a comment. @a_sidorin Alexei, With Balazs we had a long discussion and I think we reached a consensus and common understanding. Now I try to summarize it. It turned out that this patch essentially renders the `NonEquivalentDecls` cache to be compl

[PATCH] D62131: [ASTImporter] Remove NonEquivalentDecls from ASTImporter

martong marked an inline comment as done. martong added a comment. In D62131#1639168 , @balazske wrote: > Example about how to get wrong things into `NonEquivalentDecls`: > We want to compare `class C` for structural equivalence in the following > codes:

[PATCH] D62131: [ASTImporter] Remove NonEquivalentDecls from ASTImporter

balazske added a comment. A "quick fix" for the problem: https://reviews.llvm.org/D66538 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62131/new/ https://reviews.llvm.org/D62131 ___ cfe-commits mailing

[PATCH] D62131: [ASTImporter] Remove NonEquivalentDecls from ASTImporter

balazske added a comment. 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

[PATCH] D62131: [ASTImporter] Remove NonEquivalentDecls from ASTImporter

a_sidorin added a comment. > The following happened: During the analysis we compared two Decls which > turned out to be inequivalent, so we cached them. Later during the analysis, > however, we added a new node to the redecl chain of one of these Decls which > we previously compared. Then anoth

[PATCH] D62131: [ASTImporter] Remove NonEquivalentDecls from ASTImporter

martong marked 2 inline comments as done. martong added a comment. In D62131#1517634 , @a_sidorin wrote: > Hi Gabor, > Could you provide an example of an import sequence leading to this behavior? > It's hard for me to imagine such a situation. Alexei,

[PATCH] D62131: [ASTImporter] Remove NonEquivalentDecls from ASTImporter

a_sidorin added a comment. Hi Gabor, Could you provide an example of an import sequence leading to this behavior? It's hard for me to imagine such a situation. Comment at: clang/test/ASTMerge/struct/test.c:37 // CHECK: struct2.c:53:37: note: field 'f' has type 'float' here -/

[PATCH] D62131: [ASTImporter] Remove NonEquivalentDecls from ASTImporter

martong created this revision. martong added a reviewer: a_sidorin. Herald added subscribers: cfe-commits, gamesh411, Szelethus, dkrupp, rnkovacs. Herald added a reviewer: a.sidorin. Herald added a reviewer: shafik. Herald added a project: clang. Currently ASTImporter::NonEquivalentDecls member ke