[PATCH] D153536: [Clang] Implement P2169 A nice placeholder with no name

David Blaikie via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Jul 5 16:18:08 PDT 2023


dblaikie added a comment.

In D153536#4475308 <https://reviews.llvm.org/D153536#4475308>, @cor3ntin wrote:

> In D153536#4475240 <https://reviews.llvm.org/D153536#4475240>, @dblaikie wrote:
>
>> In D153536#4475199 <https://reviews.llvm.org/D153536#4475199>, @cor3ntin wrote:
>>
>>> In D153536#4474733 <https://reviews.llvm.org/D153536#4474733>, @dblaikie wrote:
>>>
>>>> Maybe try testing with more different values, to demonstrate which entities the debugger is finding?
>>>>
>>>>   int _ = 1;
>>>>   int _ = 2;
>>>>   {
>>>>     int _ = 3;
>>>>     int _ = 7;
>>>>   }
>>>>
>>>> Or something like that. But, honestly, if the point is that these variables should be unnameable - perhaps we shouldn't generate any DWARF for them?
>>>
>>> The variables should still be inspectable, ideally. It's true it makes no sense to be able to use them in expressions, and maybe if lldb use clang to evaluate expressions that would just work?
>>
>> I think that's going to be tricky - because we don't emit DWARF to say where one variable's lifetime starts compared to another in the same scope - so likely a debugger would just always show the first or last variable with the same name in a given scope (so in the above example you could probably only print {1,3} or {2,7}) - and getting it wrong is more likely and more problematic than existing cases of shadowed variables. If we can't get this right, which I don't think we can, practically speaking, at the moment (the DWARF feature we'd have to support to do this better would probably be `DW_AT_start_scope` to say at what instruction the lifetime of a variable starts) - it may be best not to include it at all?
>
> It doesn't seems to be confused on simple examples
>
>   cpp
>   * thread #1, name = 'placeholder', stop reason = step in
>       frame #0: 0x0000555555555157 placeholder`main at debug_placeholder.cpp:8:13
>      5        {
>      6            int _ = 4;
>      7            int _ = 5;
>   -> 8            int _ = 6;
>      9        }
>      10   }
>   (lldb) frame variable
>   (int) _ = 1
>   (int) _ = 2
>   (int) _ = 3
>   (int) _ = 4
>   (int) _ = 5
>   (int) _ = -9432
>
> That being said, if you think it's more prudent, I would not mind

Huh, I guess maybe it's got some heuristics based on line number. Could probably thwart those by stamping this out with a macro (which would cause all code in the macro to be attributed to the line where the macro is named) - add some function calls in, so you can step back up from the call to get to more precise locations and you'd probably see some problems. That's probably a bit contrived (but maybe not - perhaps `_` would be more common in macros).

*shrug* maybe it's OK enough.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153536



More information about the cfe-commits mailing list