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