<p dir="ltr">I was pretty sure all of this already worked outside of the captured this? The captured this was the only problem. GCC deals with this by calling the captured this 'this' and the anonymous this as '__this' IIRC. Could be wrong though, example?</p>

<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Figured I'd start the discussion here, while it's on my mind/I've<br>
built up some state.<br>
<br>
The theory is that, at a bare minimum, we need to describe the<br>
location of the captured "this" variable (so the lambda's own "this"<br>
doesn't hide it).<br>
<br>
1) Counterpoint: Clang correctly describes the member variable as<br>
being named "this". Perhaps we could argue that the debugger, upon<br>
seeing a member variable called "this" should treat that as what the<br>
user means when they say "this". But that's probably not actually a<br>
reasonable thing to do - the lambda's "this" is in a closer scope (an<br>
implicit argument to the member function) and should probably override<br>
(though clearly the compiler has to treat the object pointer as<br>
special in some way... )<br>
<br>
ooh, that gets me thinking: what if we just didn't provide a name for<br>
the object pointer? Since we want "this" to refer to the member<br>
variable, it seems like it should be possible to remove the name and<br>
then the debugger should fall back to finding the member variable<br>
'this' instead.<br>
<br>
Hacking up LLVM's IR to do this produced the expected debug info, but<br>
it did not produce the expected debugger behavior, "ptype this" still<br>
found the lambda's "this" rather than the capture. I'm inclined to<br>
file that as a gdb bug. Thoughts?<br>
<br>
2) If we wanted to be pedantically correct, we should actually create<br>
special variables to describe the location of all reference captures -<br>
currently with both Clang and GCC, the type of a reference capture is<br>
T&, but arguably we should have a variable of type "T" (that was the<br>
actual type in the user's code after all, right?) and we could do this<br>
by introducing a DW_TAG_variable for each captured variable that<br>
indirects through the lambda's this pointer to the member and<br>
indirects again through the pointer that lives there. But this is<br>
perhaps a bit more than is valuable.<br>
<br>
But if we do end up needing to describe the location of captured<br>
"this" rather than using my suggestion above, that would probably mean<br>
introducing a sufficiently generic location expression system into<br>
Clang that we could address (2) too.<br>
<br>
The main thing I think we need is the ability to do "indirect +<br>
offset" (currently for C++ non-trivial pass by value parameters we<br>
have "indirect", and if the captured this were always the first member<br>
of the lambda, that feature alone would be sufficient (I haven't<br>
tested this, but might) - just use the same location for captured<br>
"this" as for the lambda's "this", but add the indirect flag... -<br>
except we need an offset as well - and that might fall outside the<br>
sort of stuff we want to stuff in the DW_TAG_auto_variable metadata,<br>
and instead incline us towards generalizing the dbg.declare intrinsic<br>
to describe more complex location information?)<br>
<br>
Any other thoughts/ideas?<br>
</div>