cmd/compile: //go:uintptrescapes doesn't work with anonymous parameters

[mdempsky]

If you remove the a parameter name from F1 and F2 in uintptrescapes2.go (i.e., change them to func F1(uintptr) {} and func F2(...uintptr) {}), the test fails.

I suspect in practice this particular issue doesn't matter in practice, but looking at the code, I can't obviously see why the parameter names should be relevant in either (*EscState).esctag or ordercall. It makes me worry that escape analysis / pragma tags might not be working correctly in some other more realistic scenarios.

/cc @ianlancetaylor

[cherrymui]

In esctag, the escape tag is overwritten by the loop at the end which is for special handling of unnamed parameters, https://go.googlesource.com/go/+/fdf3ceafc61c0cf9b7b7bd6757f0c51393a7a83c/src/cmd/compile/internal/gc/esc.go#2262.

Making that loop not overwrite those tags fixes the problem. CL coming.

[gopherbot]

Change https://golang.org/cl/82775 mentions this issue: cmd/compile: fix go:uintptrescapes tag for unnamed parameters

[mdempsky]

@cherrymui Thanks for pointing that out. That settles my worries.

Perhaps this is working as intended then. Since //go:uintptrescapes only applies to functions implemented in Go (as opposed to assembly), and you can't refer to anonymous parameters, there's no need for their arguments to escape or be kept alive?

[ianlancetaylor]

//go:uintptrescapes really only exists as a patch for syscall.(*Proc).Call and syscall.(*LazyProc).Call to permit them to take uintptr arguments without breaking the Go 1 guarantee. The uintptrescapes directive is not documented and it's not especially important how it is implemented as long as those two methods (and the corresponding ones in golang.org/x/sys/windows) continue to work correctly. See #16035.

That said, theoretically, I think it shouldn't matter whether the parameter is anonymous or not. Either way the object should remain live and should not move. I can imagine cases where one parameter would be the address of a field of another parameter, and that second parameter should remain live even if it happens to be unnamed.