Consider the following example (compiled by gcc because clang doesn't emit correct scope for types if they defined in a lexical block, support for clang D113743):
* thread #1, name = 'a.out', stop reason = step over
frame #0: 0x000000000040111d a.out`foo(a=1) at test_lldb.cpp:5:12
1 int foo(int a) {
2 {
3 typedef int Int;
4 Int local = a;
-> 5 return local;
6 }
7 }
8
(lldb) p local
error: expression failed to parse:
error: <lldb wrapper prefix>:45:31: no member named 'local' in namespace '$__lldb_local_vars'
using $__lldb_local_vars::local;
~~~~~~~~~~~~~~~~~~~~^
error: <user expression 0>:1:1: use of undeclared identifier 'local'
local
^
lldb failed to find 'local' variable typed with a lexical block defined type (typedef Int).
The immediate cause of this issue is that clang failed to import this typedef:
lldb (x86_64) a.out: DWARFASTParserClang::ParseTypeFromDWARF (die = 0x00000070, decl_ctx = 0x2509cb0 (die 0x00000055)) DW_TAG_typedef name = 'Int')
lldb (x86_64) a.out: SymbolFileDWARF::ResolveTypeUID (die = 0x00000070) DW_TAG_typedef 'Int'
lldb (x86_64) a.out: SymbolFileDWARF::ResolveTypeUID (die = 0x00000096) DW_TAG_base_type 'int'
lldb Compiler diagnostic:
lldb Couldn't import type: UnsupportedConstruct
lldb Couldn't copy a variable's type into the parser's AST context
The importing wasn't succeed because clang wasn't able to import typedef's context, which is actually a BlockDecl (import for BlockDecl isn't implemented, but this is still a question to me why DW_TAG_lexical_block is associated with a BlockDecl).
I have a workaround for this issue (see D115277), but a proper fix is still needed.
Consider the following example (compiled by gcc because clang doesn't emit correct scope for types if they defined in a lexical block, support for clang D113743):
lldb failed to find 'local' variable typed with a lexical block defined type (typedef Int). The immediate cause of this issue is that clang failed to import this typedef:
The importing wasn't succeed because clang wasn't able to import typedef's context, which is actually a BlockDecl (import for BlockDecl isn't implemented, but this is still a question to me why DW_TAG_lexical_block is associated with a BlockDecl).
I have a workaround for this issue (see D115277), but a proper fix is still needed.