cmd/compile: incorrect stack trace for nil dereference in inlined function #27201
I believe that the stack trace for panics that occur when computing arguments to an inlined function are incorrectly attributed to the inlined function. I'm not sure if this is a known / expected consequence of inlining, but it caused a lot of confusion to see a line identified where a nil dereference is impossible.
What version of Go are you using (
I see what is happening now.
My last comment was incorrect, the MOVLQSX is indeed marked at line 14.
What's happening here is that two instructions are being merged, and the choice of line number is pretty arbitrary:
gets merged to
Note that the load is line 10 and the sign extension is line 14. That's correct. The merged instruction ends up at line 14. That's not incorrect, but maybe not super helpful. In particular, I think the line number of the load (or any possibly faulting instruction really) should supercede the line number of the sign extension.