[Lldb-commits] [PATCH] D156774: [lldb][DWARFASTParserClang] Resolve nested types when parsing structures

[Michael Buch via Phabricator via lldb-commits]

Michael137 added inline comments.


================
Comment at: lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp:3040
 
+    case DW_TAG_enumeration_type:
+    {
----------------
Endill wrote:
> Michael137 wrote:
> > Michael137 wrote:
> > > Michael137 wrote:
> > > > Michael137 wrote:
> > > > > At first glance this seems OK but I'll want to check why the type doesn't get resolved when `clang::Sema` asks LLDB for it by name
> > > > Checking locally and will report back
> > > Ok, so what happens for `expr Outer::Enum::var` is that LLDB will first resolve the `Outer` structure (and all its member fields, but not nested types). When clang looks for `Enum`, it wants to find it in a direct lookup into the `Outer` DeclContext. But that lookup will fail because we never created the decls for the nested type. There is no fallback to the external source in such a case unfortunately so LLDB never has the chance to correct this. See the `LookupQualifiedName` code path in `Sema::BuildCXXNestedNameSpecifier`.
> > > 
> > > So I think this proposed approach should be fine. But what I think could be better is if we just do the same for `DW_TAG_enumeration_type` and `DW_TAG_structure_type` as we do for `DW_TAG_subprogram`.
> > > 
> > > I.e., simply push back the type into `member_function_dies` (we should rename this) and then it will get resolved properly in `CompleteRecordType`.
> > Also `DW_TAG_union_type` while you're here :)
> I can look into doing things more lazily like `DW_TAG_subprogram`, if you can point me to code paths for this on LLDB side:
> > When clang looks for Enum, it wants to find it in a direct lookup into the Outer DeclContext. But that lookup will fail because we never created the decls for the nested type. There is no fallback to the external source in such a case unfortunately so LLDB never has the chance to correct this.
The `DW_TAG_subprogram` path is just above this one in the switch statement (line 3030). Search for `member_function_dies` in this file.

> if you can point me to code paths for this on LLDB side

Clang requests type completion by calling `FindExternalVisibleDeclsByName` (which LLDB implements). So if you break in that function you should be able to see what LLDB finds when it looks for the outer structure and the enum. But you don't necessarily need to do that. If we just fill up the `member_function_dies` vector with the nested enum/union/structure types like we do for `DW_TAG_subprogram` that is sufficient.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D156774/new/

https://reviews.llvm.org/D156774