labath added a comment. Thanks for the explanation. This makes things a lot clearer (though it doesn't convince me that this is the right approach).
I still think that the piecemeal addition of member functions is a problem. While I don't think that changing the parsing order in `Module::ParseAllDebugSymbols` would be a problem (that function is only called from lldb-test), I think that would only hide the problem. Looking at what happens in the DWARF case, I /think/ (the code is fairly messy, so I could be wrong) that we don't create a clang ast representation for the function in `ParseFunctions`. We only create an lldb_private::Function (in `DWARFASTParserClang::ParseFunctionFromDWARF`). The ast entity only gets created in `SymbolFileDWARF::ParseTypes` (->ParseType->DWARFASTParserClang->ParseTypeFromDWARF). This kinda makes sense since we only need the ast representation of the method when we start dealing its class. So I have a feeling that the real solution here is to avoid creating an ast entry for the function in the first phase. Then you should be able to create the full class declaration in the second phase, as you will have complete information there. Does that make sense? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D113930/new/ https://reviews.llvm.org/D113930 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
