- User Since
- Oct 10 2017, 8:01 AM (79 w, 3 d)
Tue, Apr 16
Wed, Apr 10
- Put back the call to GetOriginalDecl
Wed, Apr 3
Tue, Apr 2
Mon, Apr 1
Fri, Mar 29
Thu, Mar 28
Wed, Mar 27
Tue, Mar 26
There is a lookup failure within the
ASTImporter during the expression evaluation. The clang::ASTImporter cannot
lookup previously created declarations thus it creates duplicated and redundant
declarations. These duplicated declarations then later can cause different
- Add braces around else
- Remove falsely duplicated push_back
- Use Expected<T> in HandleNameConflict
Looks good for me now, but we should make a similar change in VisitRecordDecl too.
Mon, Mar 25
Fri, Mar 22
I am aware of similar errors like this with other AST nodes. We had a patch in our fork to fix that in January (https://github.com/Ericsson/clang/pull/569/files) I am going to prepare a patch from that cause I see now this affects you guys in LLDB too.
@shafik, @a_sidorin Ping. Could you please take a look?
Guys, this and its child patch are very important patches, because without it the error handling of ASTImporter is not completed. This means we may encounter a nullptr DeclContext in the middle of the import process, etc...
@martong It's not related to lookup or anything like that, it's just that we don't have enough information in our debug info AST to allow people to use meta programming. The custom logic we have in LLDB looks into the std C++ module to fill out these gaps in the AST by hand when they are used in an expression.
The remark about the alternative being slow just means that fixing all the templates we have in our debug info AST seems like a costly approach. I'm also not sure how well it would work, as I never tried mixing a C++ module in an ASTContext that isn't currently being parsed by Clang.
Wed, Mar 20
Mar 19 2019
- Rebase to master
We can't reliable import templates with the ASTImporter, so actually reconstructing the template in the debug info AST and then importing it doesn't work.
Could you please elaborate how the import of templates fails in ASTImporter? Is it because the AST you build from the DWARF is incomplete? Or is there a lookup problem? Is there an assertion in one of the CodeGen functions once the import is finished?
If we could fix that error in the ASTImporter then other clients of it (like CTU) could benefit from the fix too. Perhaps, the best would be to have a test which reproduces the template import related errors, maybe a lit test with clang-import-test?
Mar 14 2019
Mar 8 2019
@a_sidorin Aleksei, If you don't mind, I am going to investigate this further with macOS/LLDB and try to answer Adrian's comments too.
Rebase to master.
There was a conflict in the tests, in ASTImporterTest.cpp.
Mar 7 2019
This patch is the next in the series of patches to finish the proper error handling (i.e. using Error and Expected<T>). Please see the "Stack" column above.
Ping. This patch is the next in the series of patches to finish the proper error handling (i.e. using Error and Expected<T>). Please see the "Stack" column above.
- Add asserts
Mar 5 2019
Mar 4 2019
Alexei, thanks for the review!
- Fix some comments
- Add FindAndMapDefinition as member fun
- Refactor CheckPreviousDecl
Alexei, thanks for the review!