[Lldb-commits] [PATCH] D12658: Search variables based on clang::DeclContext and clang::Decl tree

[Greg Clayton via lldb-commits]

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