Hello Raphael! Nice patch, thank you for this refactoring!

Hello Shafik!
The patch looks good, I only have a few stylish nits.

Hi, 19n07u5!
It's neat that my research gained some value for community members. Unfortunately, my initial work had a number of design problems that prevented me from upstreaming it. And the first one was module dependencies. The whole dependency picture for graph matchers looks like this:

1. ASTTypeTraits should depend on Static Analyzer (not an option!) because graph types are trying to mimic common DynTypedNodes. This was done to make matchers for graph and AST nodes operate seamlessly but what was good for PoC was not good for upstreaming.
2. ASTMatchers should depend on Static Analyzer (requires massive refactoring). One of the problems here is that Clang can be built without CSA so ASTMatcherInternals.h have to become full of preprocessor guards.
3. ASTMatchers should depend on GraphMatchers and vice versa. While the backward dependency is fine, the direct is required to make matchers like functionDecl(hasPath(....)) work. This is not a problem for this patch, however.

Hello Balazs,
This look almost good to me except some comments inline.

LGTM!

Nice solution!

The patch looks good. Thanks! I would prefer to see more tests for other TypeLoc cases, but I think they could be added in the following patches.
@shafik Shafik, do you have any suggestions for this patch?

LGTM, thanks!

Hi Gabor,
I have an inline comment for the patch. Otherwise, looks good.

Finally, this FIXME is addressed. Thanks! Are you going to add any tests in the following patches?
It looks almost good to me, but I have a question inline.

Hi Gabor,
This patch looks mostly good to me. Thanks!

LGTM, thanks!
Let's wait for Shafik's comments before committing this.

Hello Gabor,
That's an interesting case, thank for fixing this!

Ouch! Sorry, Gabor -_\\

Hello Balasz,
In my opinion, importing and setting the attributes should be handled by the stuff used in InitializeImportedDecl(). Can we extend it or reuse the code? It will allow us not to miss the required actions while importing a new function too.

Looks good!

Thank you!

Looks good, thank you for addressing the comments!

LGTM.

LGTM++

Hello Balasz,
I have some comments inline.

Hi Artem!
The patch looks very promising for CSA, thanks for working on this!

Hello Gabor,
This doc will become extremely useful for new developers. Thank you for dumping this sacred knowledge!

Hello Gabor!
I think it's a correct solution for the analyzer: usually, we cannot import a lambda until we have to import some enclosing expression - which means that the lambdas are actually not the same. But I'm not so sure about how it can affect the LLDB logic. @shafik Shafik, could you please take a look?

That's incredible. Thank you!

Hi Balazs,
The change looks good. I think it can be committed after an unrelated part is removed.

LGTM, thanks!

Hello Balazs,
The patch looks good in general.

Hello Balazs,
Do I understand correctly that it was unset ToFunction->setLexicalDeclContext(LexicalDC); that caused lookup problems?

LGTM, thanks!

Hi Artem,
The patch looks good to me. I prefer a fully qualified name, however, but it is a matter of taste.

Hi Gabor,
Thank you again for working on this patch. I think it can be committed after minor stylish issues are fixed.

Looks good! Sorry for the delay :(

Hi Gabor,
This looks fine, but could you please add a test showing how decl shadowing is handled? I.e. if we have Arg in one TU and both Arg and N::Arg in another TU.

Hello Gabor,
This patch looks good to me.
Regarding the related patch: can we use getLambdaManglingNumber() for the comparison?

Post-LGTM :)

LGTM!

Hi Gabor,
The patch looks good, but it looks to me that it has a relation to https://reviews.llvm.org/D64078 that is kind of questionable to me. Let's delay landing this patch until the fix direction is clear.

Hi Gabor,
it is a nice design question if source locations can participate in structural match or not. The comparison tells us that the same code written in different files is not structurally equivalent and I cannot agree with it. They can be not the same, but their structure is the same. The question is: why do we get to this comparison? Do we find a non-equivalent decl by lookup? I guess there can be another way to resolve this issue, and I'll be happy to help if you share what is the problem behind the patch.

Hello Gabor,
There is an inline question about tests; other code looks fine.

Hello Gabor,
This looks mostly good but I have a question inline.

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 another structural equivalent check followed for the two Decls. And this time they should have been considered structurally equivalent, but the cache already contained them as nonequivalent. This resulted in a false positive NameConflict error.

Should we reset the non-equivalence relation after a decl is imported for this decl and its redecls?

LGTM, thanks for the fixes!

Hi Gabor,
The patch looks good. Thanks!

Thanks for the explanation!
It will be good if someone else takes a look at this patch.

Hello Gabor,
Thank you for the explanation. I got the idea of this patch anyway, but it will be definitely useful for anyone digging into the code. Should we make it a comment for ImportPathTy?

Thanks!

LGTM!

Hi Artem,
Looks mostly good, but I have some comments inline.

Hi Gabor!
I haven't find the import sequence examples we try to fix these ways in any of the three patches these change consists of. Could you please provide some (or point if I missed them)?

Hi Gabor,
Could you please provide any test for the import itself?

Hi Gabor,
The idea looks fine to me, but I have some questions inline.

Hello Gabor,
I have a few questions inline.

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.

Cool!

Hi Gabor,
This looks fine, but I have a question inline.

The conversion operator indeed looks non-evident.

Wow, this is a cool idea!

Thank you for digging into this! Feel free to ask me if you encounter any problems with the patch.

Hi Gabor,
I like this change! LGTM, just a few nits.

👍

Looks good!

LGTM, thanks!

Hello Gabor!
This looks good to me, but let's wait for LLDB guys to take a look at the patch. Thanks!

Looks good, thanks!

Hello Shafik!
The patch itself is fine, but, as other reviewers pointed, tests are appreciated. I suggest to add a test into ASTImporterTests.cpp - you will find several ways to write tests of different complexity here. I think this change can be tested even with the simplest testImport() facility.

Mmm, what are the pros and cons?

Hi Artem,
This looks good to me. However, it seems to me that the correct solution is to synthesize a shining new function and include it into the redeclaration chain. This requires much more work, however.

Hi Artem,
There are some comments inline, but looks promising!

I like the test even more than the change itself!

LGTM.

LGTM.

Hello Raphael,
I think we should accept this change. I don't see an easy way to merge the LLDB stuff into ASTImporter; also, this patch provides a good extension point for ASTImporter since it is designed to be a parent class. @martong @shafik Gabor, Shafik, what do you think?

Yes, I think this is fine. Thanks!

Thanks!

Post-LGTM with some stylish nits.

Hi Shafik,
Thank you for the explanation, it is much more clear to me now. But, as I see, D59692 is going to discard the changes this patch introduces. @martong Gabor, do you expect the changes of this patch to be merged into yours, or should this patch be abandoned?

Thanks for the fixes! I'd like to clarify one moment, however.

Hi Balazs,

Hi Balasz,

Hello Raphael,

Hi Gabor,

Hi Shafik,

Hi Gabor,
This patch LGTM mostly, but there is a comment inline.

Thanks!

Looks good!

Hi Gabor,
Thanks for the patch! It looks good to me except some stylish nits.

Hi Gabor,
The patch looks almost good bu I have some comments inline.