martong added a comment. In D59485#1439570 <https://reviews.llvm.org/D59485#1439570>, @martong wrote:
> In D59485#1439390 <https://reviews.llvm.org/D59485#1439390>, @teemperor wrote: > > > > Well, I still don't understand how LLDB synthesis the AST. > > > So you have a C++ module in a .pcm file. This means you could create an > > > AST from that with ASTReader from it's .clang_ast section, right? In that > > > case the AST should be complete with all type information. If this was > > > the case then I don't see why it is not possible to use > > > clang::ASTImporter to import templates and specializations, since we do > > > exactly that in CTU. > > > > > > Or do you guys create the AST from the debug info, from the .debug_info > > > section of .pcm module file? And this is why AST is incomplete? I've got > > > this from > > > https://youtu.be/EgkZ8PTNSHQ?list=PL85Cf-ok7HpppFWlp2wX_-A1dkyFVlaEB&t=1565 > > > If this is the case, then comes my naiive quiestion: Why don't you use > > > the ASTReader? > > > > There are no C++ modules involved in our use case beside the generic `std` > > module. No user-written code is read from a module and we don't have any > > PCM file beside the `std` module we build for the expression evaluator. > > > > We use the ASTReader to directly read the `std` module contents into the > > expression evaluation ASTContext, but this doesn't give us the decls for > > the instantiations the user has made (e.g. `std::vector<Foo>`). We only > > have these user instantiations in the 'normal' debug info where we have a > > rather minimal AST (again, no modules are not involved in building this > > debug info AST). The `InternalImport` in the LLDB patch just stitches the > > module AST and the debug info AST together when we import something that we > > also have (in better quality from the C++ module) in the target ASTContext. > > > Thank you for the explanation. > Now I understand you directly create specializations from the std module and > intercept the import to avoid importing broken specializations from the debug > info, this makes sense. Really, just one last question to see the whole picture: If clang::ASTImporter were capable of handling a specialization/instantiation with missing info then we could use that. So the reason for this interception is that clang::ASTImporter::VisitClassTemplateSpecializationDecl cannot handle the specialization it receives because that or its dependent nodes has too many missing data, right? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59485/new/ https://reviews.llvm.org/D59485 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
