<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Issue</th>
<td>
<a href=https://github.com/llvm/llvm-project/issues/54475>54475</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>
lldb fails to display a local var when its type defined in a lexical block
</td>
</tr>
<tr>
<th>Labels</th>
<td>
lldb
</td>
</tr>
<tr>
<th>Assignees</th>
<td>
</td>
</tr>
<tr>
<th>Reporter</th>
<td>
chbessonova
</td>
</tr>
</table>
<pre>
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](https://reviews.llvm.org/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](https://reviews.llvm.org/)), but a proper fix is still needed.
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJy1Vslu4zgQ_Rr5QrQhUVt88MGJk0Zug-405mhQFGWzmxI1JOXl76eKWp1OMIMBRpDjmCzW8upVFQtd3rZPurGyFIa4kyCVVkpfZHMk4srqVgkS0Aeu61YqUZLiRo6ck0Jw1llBuGIgWGphm4DmjohaOsK1MYI7YrluUR_ovbXCElmhgRspRSUb0CUbwogSV8mZIoXS_FdAn4jt2lYb58_16oP0cR9FcZ7EQboHZ07OtTaIdwF9gdeIsxQXu1bqXK-1OcLSKE03-IJguA_CXZCFw-t_EohrBw4ZwUr4N47QeMNqiDfew0LO1rpz8O2dcrolIGl147etEy3RZ2FGXfhUxp-mcQg2SXgNpycJoygqSa8xCyutIQwGisDohjBHnLDuoFRZrHnbwukUPhFdKI_I9MgGwUEN-B9DDUH-uJCl8AnCDXm3HI_LxOcDsuBVvTYuiJdyySwHewTyAunBoNlC7ksQP5N0ljTCdabphe_VZbM3-8Vy3i_fLz7MqXlANDC2dlA67AhjtEF8xbU1wloJGamY56bTpGXGiinjC-kgfkKF5GJY2wLT4WwlrxAEbCaINuQfxBpNalEXIIBMQF7kvXWaI11x0baMY5aBF8nB5-zgRQ5nsI3LC0Z0FuvoQ0HwMd59ANfwBPnzf3_T54_ih3o1S9TCPvpo-BCsZ12RrikF1J3BAi1F42Ql4dwCiFH3Ii2TxXc15iGfswNlfw8pICFZAS3GE5JcpDu9bwlTt0AR5MXIXeQt3ax7Q2_QuGQNGZPMQVdiQyzuJKHtWNvBroVfUGl9S5l9krXvNl5yUP1Zx_DReG5eH7JDlvja9SUN6O3_3H172X1_-wMZaJ7QSp9jv_AGml-Mrr0Uaihl32fGLpGH2GYQ-QN312GLpuGGF-EoP8qmad_ZwObhbff1MCKybF4enRzl_tn177e60OoFEPHu9W5_E1ars3f8x-v-M5d_82E2_b_Z3WQLuwWz4jBQI5e_W37qB5chwIxjo62TfE7vvWCnyn6IjZQArejmj2YYSaLEQelMx91nR2Hi3YDBI69hrWcVdlrtx6vvUMZvAFvgQOPE1X3It57UaBm7yIUNM9Z2nAscxXczeNru60kvo0BOo8HRGDDtcpL8hEXBuOuYUuj1I9bbHiiIqA_HcQrP69JOCClRQ3MQJSorOjeWGkxGqRQo-6uDkYZtxmFLBXu3MWVDeR_68kYXrNUcC3fqAJPFucL7v6_kxM4CJC7a_GJGQ7PqLxhzoYPvVojh0pDSPP-Xl4bhtjCEw2BCaBwUMCXmsBrAXZTrVbmNy028YSsnnRLbqc1ZjLaUtlUMAe1HJ5ABwhcNkW4gw-cXoFVn1Pbe1SNA0sG9QNfwA_0dvr6Agz_hmgU_feAwe17SJMnT1WkL9x9KWZbwMqO8iktwm1Z5VPIwgtsOpSvFCqHsFkAKKO0nLQWcVnJLQ0rDmMJ9hYZRuo6ysEjopsrKLM2ipAiSUNQQ6YTcymy9N0V3tLCppHUzrCtIrTwCat4S6GedO2mz5acChpBu9JmtvPNb7_nfUnkwsQ">