We could also say that with optimized binaries we do not correlate closure bodies with their parent in the debugger, or that we do a best effort thing and occasionally get it wrong (I suspect actually keeping track of .closureptr could have negative performance effects).
(also reproduces on tip)
Given this sample program using range-over-func the DIE emitted for
main.PrintAllElements[go.shape.string]-range1
when optimizations are enabled is:No entries for
.closureptr
are generated, presumably because all the stores related to.closureptr
are optimized away.Originally reported as https://github.com/go-delve/delve/issues/3806 (where it triggers other related delve bugs).
We could also say that with optimized binaries we do not correlate closure bodies with their parent in the debugger, or that we do a best effort thing and occasionally get it wrong (I suspect actually keeping track of .closureptr could have negative performance effects).
cc @dr2chase