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.

Thanks for the fixes!

Hi Gabor,
Sorry, missed the patch. It looks mostly good, but do we have any test for this?

Hi Gabor,
The patch looks OK overall but I have some comments inline.

Hi Gabor,
I don't see any problems with the patch. Thanks! I think it will be good to get Shafik's approval as well.

Hi Tom,
Thanks for the fixes! The patch looks good to me now. I have only a small nit inline.

Hi Tom,

Hi Tom,
The change looks reasonable but the tests need some improvements.

Thanks for the changes! The patch looks completely fine to me now.

Hi Gabor,
This patch LGTM with a minor nit.

Hi Gabor,

Hi Gabor,
Please find my comments inline.

LGTM!

Looks good, thanks!

There are never enough tests :) Thank you!

Oh, I remember how much pain have debug mode-only assertions caused.

LGTM, thank you!
I'm sorry if the change I requested doesn't look good, but I think the correctness is our priority.

Hi Shafik,
Please find my answers inline.

Hi Artem,
This looks perfect, just some stylish issues.

Hi Rafael,
The change looks mostly fine but I have some comments inline.

Hello Gabor,

Hi Gabor,
Yes, this looks good. Thanks!

Hello Endre.
I agree that it doesn't make sense to have 'errors' in AST merging tools, and the changes for ASTImporter part are welcome. However, I don't feel so positive to modules support changes and I don't think we are allowed to change this. @aaron.ballman, @rsmith what do you think?
@bruno, you're the original author of the related Sema code. What do you think, should this be a warning or an error in Sema?