Template parameters are created in ASTImporter with the translation unit as DeclContext.
The DeclContext is later updated (by the create function of template classes).
ASTImporterLookupTable was not updated after these changes of the DC. The patch
adds update of the DeclContext in ASTImporterLookupTable.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/AST/ASTImporter.cpp | ||
---|---|---|
6049 | Is this case covered in the tests? |
clang/lib/AST/ASTImporter.cpp | ||
---|---|---|
6049 | This test was left out but added now. But test CTADImplicit does fail if the import of FunctionTemplateDecl is handled similarly as the other cases. |
clang/unittests/AST/ASTImporterTest.cpp | ||
---|---|---|
4482 | This should not have been reformatted. |
clang/lib/AST/ASTImporter.cpp | ||
---|---|---|
6005–6006 | Do you think that the alternative approach that is used with TypedefNameDecl could work here? // Do not import the DeclContext, we will import it once the TypedefNameDecl // is created. if (Error Err = ImportDeclParts(D, Name, ToD, Loc)) return std::move(Err); With that perhaps we could avoid the hassle with the update. Could you please investigate that? | |
6055 | typo: is is -> it is |
clang/lib/AST/ASTImporter.cpp | ||
---|---|---|
6005–6006 | The problem is not with the DC of the FunctionTemplateDecl, it is with the template parameters. It looks not safe to pass nullptr as DeclContext for these, this is only possible if the import is done. (Probably the solution in TypedefNameDecl is not perfect: If something exists already in the "To TU" that was not imported, specially a namespace that contains a typedef with same name, it may not be found before the import.) |
Do you think that the alternative approach that is used with TypedefNameDecl could work here?
With that perhaps we could avoid the hassle with the update. Could you please investigate that?