clayborg added a comment. In http://reviews.llvm.org/D12658#243953, @paulherman wrote:
> I believe that the approach of CompilerDeclContext::FindDecls could be > better. But then this kind of forces CompilerDeclContext to inherit > CompilerDecl (a function is both a DeclContext and a Decl) and I believe that > creating a class for each possible entity is an overkill. > > I started looking at SymbolFileDWARF. In order to not have "clang::___", I > believe that ParseVariableDIE and ParseFunctionBlocks should be moved to > DWARFASTParser. No they don't need to be. You just need to move the clang specific code into a function that is then passed through the TypeSystem interface. We don't need to make a CompilerDecl for a variable all the time, just when we ask the lldb_private::Variable class to get its CompilerDecl. So we could add method to Variable: CompilerDecl Variable::GetDecl(); It could always just call down to the symbol file and have the symbol file get the CompilerDecl for the variable. This would mean a new function on TypeSystem: CompilerDecl DeclGetDeclForVariable (const lldb::VariableSP &var_sp); And that would eventually get routed down through the DWARFASTParser class... > I don't really understand what Sean and Jim mean. I believe that > ClangASTSource implements the interface ExternalASTSource and > ClangExpressionDeclMap (which does the actual search) inherits > ClangASTSource, so it should be already alright...? Yes the lookups currently happen like this and we should just be making function calls with any using directives to help fill in the results of this call. > //**EDIT**// > I worked on fixing some of the things. However, I always encounter the need > to store a map from CompilerDecl to VariableSP since given a > CompilerDeclContext (using the solution above) we can get the CompilerDecl. > Where do you think it would be best to store this map? I thought about adding > it to SymbolFileDWARF and adding a method VariableSP > SymbolFileDWARF::GetVariableFromDecl(CompilerDecl decl). If these are all abstract items, we can store any maps in TypeSystem itself. > The other solution idea I have is to use StackFrame::GetInScopeVariableList > to get the list of variables and search through that list to see if a > variable has a decl in the list returned by > CompilerDeclContext::FindDeclsByName. This might be better since there > already is a call to StackFrame::GetInScopeVariableList so that the variable > dies are parsed (is there a better way of doing this?). Yes, this would involve asking each VariableSP for its Decl using Variable::GetDecl() as mentioned above. http://reviews.llvm.org/D12658 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
