BindingDecl was added recently but the related DecompositionDecl is needed
to make C++17 structured bindings importable.
Import of BindingDecl was changed to avoid infinite import loop.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
clang/lib/AST/ASTImporter.cpp | ||
---|---|---|
2305–2309 | So, we moved the import of the binding before importing the decomposition decl to avoid an infinite recursion. But why can't we have an infinit recursion this way? Perhaps, it would be useful to have a test case that triggered the infinity in case of the original order of the import calls. |
clang/lib/AST/ASTImporter.cpp | ||
---|---|---|
2305–2309 | Yes, I agree, I would also like to understand better why this avoids the infinite recursion problem, a test case would be helpful as well as an explanation of the steps that leads us to the problem. |
clang/lib/AST/ASTImporter.cpp | ||
---|---|---|
2305–2309 | With the import at original place, in VisitVarDecl the bindings (which are BindingDecl) are imported before create of the DecompositionDecl instance, and in VisitBindingDecl the decomposition (a DecompositionDecl that is VarDecl) is imported before create of the BindingDecl instance. This causes the recursion with the most simple import of a DecompositionDecl. This is triggered by the existing simple test (actually I discovered the problem at the test failure). If the decomposition is imported after create of the BindingDecl the same BindingDecl is not imported again because it already exists. |
clang/lib/AST/ASTImporter.cpp | ||
---|---|---|
2305–2309 | Ok, thanks. |
So, we moved the import of the binding before importing the decomposition decl to avoid an infinite recursion. But why can't we have an infinit recursion this way?
Perhaps, it would be useful to have a test case that triggered the infinity in case of the original order of the import calls.