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.

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

@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?

//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.