cmd/go: go1.19beta1 fails whenever it sees an Emacs lock file

[bradfitz]

go1.19beta1 is nearly unusable with a default Emacs config. (Not looking for Emacs or git clean help)

Go 1.18.3 runs tests fine:

bradfitz@tsdev:~/src/tailscale.com/util/deephash$ ~/go/bin/go1.18.3 test 
PASS
ok      tailscale.com/util/deephash     0.441s

But Go 1.19beta1 fails to run the tests in the util/deephash directory because of an Emacs lock file (a dangling symlink):

bradfitz@tsdev:~/src/tailscale.com/util/deephash$ ~/go/bin/go1.19beta1 test 
stat /home/bradfitz/src/tailscale.com/cmd/tailscaled/.#tailscaled.go: no such file or directory
bradfitz@tsdev:~/src/tailscale.com/util/deephash$ ls -l /home/bradfitz/src/tailscale.com/cmd/tailscaled/.#tailscaled.go
lrwxrwxrwx 1 bradfitz bradfitz 33 Jun 15 14:51 /home/bradfitz/src/tailscale.com/cmd/tailscaled/.#tailscaled.go -> bradfitz@tsdev.1002020:1653778856

Particularly offensive is that the symlink isn't even in the package I'm testing, and isn't even a transitive dep of the package being tested:

bradfitz@tsdev:~/src/tailscale.com/util/deephash$ go list -f {{.Deps}} . | grep tailscaled | wc -l
0

Okay, let's delete that file and carry on:

bradfitz@tsdev:~/src/tailscale.com/util/deephash$ rm /home/bradfitz/src/tailscale.com/cmd/tailscaled/.#tailscaled.go
bradfitz@tsdev:~/src/tailscale.com/util/deephash$ ~/go/bin/go1.19beta1 test 
stat /home/bradfitz/src/tailscale.com/net/netstat/.#tcptable_windows.go: no such file or directory
bradfitz@tsdev:~/src/tailscale.com/util/deephash$ ls -l /home/bradfitz/src/tailscale.com/net/netstat/.#tcptable_windows.go
lrwxrwxrwx 1 bradfitz bradfitz 30 Sep 10  2020 /home/bradfitz/src/tailscale.com/net/netstat/.#tcptable_windows.go -> bradfitz@tsdev.6860:1592416003
bradfitz@tsdev:~/src/tailscale.com/util/deephash$ rm /home/bradfitz/src/tailscale.com/net/netstat/.#tcptable_windows.go
bradfitz@tsdev:~/src/tailscale.com/util/deephash$ ~/go/bin/go1.19beta1 test 
stat /home/bradfitz/src/tailscale.com/tsnet/.#tslib.go: no such file or directory

more, more, more.

I see nothing in https://tip.golang.org/doc/go1.19 talking about this new behavior if it's intentional and I see no open issues about this, so I'm assuming it's not a known feature or bug.

[seankhliao]

maybe #53387 ?

[bradfitz]

@seankhliao, thanks! Yup, that looks like the same. Closing this one.