- User Since
- Jun 24 2018, 6:54 AM (134 w, 4 d)
Sep 16 2020
Hello Raphael! Nice patch, thank you for this refactoring!
Apr 22 2020
The patch looks good, I only have a few stylish nits.
Apr 19 2020
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:
- 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.
- 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.
- 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.
Mar 8 2020
This look almost good to me except some comments inline.
Feb 13 2020
Jan 19 2020
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?
Dec 16 2019
Dec 15 2019
I have an inline comment for the patch. Otherwise, looks good.
Dec 7 2019
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.
This patch looks mostly good to me. Thanks!
Let's wait for Shafik's comments before committing this.
Nov 29 2019
That's an interesting case, thank for fixing this!
Oct 8 2019
Ouch! Sorry, Gabor -_\\
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.
Sep 12 2019
Sep 8 2019
Sep 2 2019
Looks good, thank you for addressing the comments!
Sep 1 2019
Aug 25 2019
I have some comments inline.
Aug 24 2019
Aug 18 2019
The patch looks very promising for CSA, thanks for working on this!
This doc will become extremely useful for new developers. Thank you for dumping this sacred knowledge!
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?
Aug 12 2019
That's incredible. Thank you!
The change looks good. I think it can be committed after an unrelated part is removed.
Aug 11 2019
The patch looks good in general.
Do I understand correctly that it was unset ToFunction->setLexicalDeclContext(LexicalDC); that caused lookup problems?
Aug 6 2019
Aug 5 2019
The patch looks good to me. I prefer a fully qualified name, however, but it is a matter of taste.
Jul 22 2019
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 :(
Jul 14 2019
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.
This patch looks good to me.
Regarding the related patch: can we use getLambdaManglingNumber() for the comparison?
Jul 7 2019
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.
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.
Jul 2 2019
There is an inline question about tests; other code looks fine.
This looks mostly good but I have a question inline.
Jun 30 2019
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!
The patch looks good. Thanks!
Thanks for the explanation!
It will be good if someone else takes a look at this patch.
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?
Jun 23 2019
Jun 3 2019
Looks mostly good, but I have some comments inline.
May 26 2019
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)?
Could you please provide any test for the import itself?
The idea looks fine to me, but I have some questions inline.
I have a few questions inline.
Could you provide an example of an import sequence leading to this behavior? It's hard for me to imagine such a situation.
May 19 2019
This looks fine, but I have a question inline.
May 11 2019
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.
I like this change! LGTM, just a few nits.
May 4 2019
This looks good to me, but let's wait for LLDB guys to take a look at the patch. Thanks!
Apr 25 2019
Looks good, thanks!
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.
Apr 22 2019
Mmm, what are the pros and cons?
Apr 20 2019
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.
Apr 16 2019
There are some comments inline, but looks promising!
I like the test even more than the change itself!
Apr 8 2019
Mar 28 2019
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!
Post-LGTM with some stylish nits.
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.
Mar 24 2019
Mar 21 2019
Mar 11 2019
This patch LGTM mostly, but there is a comment inline.
Mar 10 2019
Mar 3 2019
Thanks for the patch! It looks good to me except some stylish nits.
The patch looks almost good bu I have some comments inline.