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
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
