Related Issues

• affected/package: go install not working #52294 (closed)
• x/tools/godoc: TestCommandLine failed #23192 (closed)
• cmd/go get doesn't validate module arguments #71437 (closed)
• cmd/go: -x flag doesn't print executable output if cgo is used #21427 (closed)
• cmd/go: work use silently ignores nonexistent target #51965
• cmd/go: failed to build if the testdata contains broken symlinks #53305 (closed)
• build: the build of go bootstrap in case of compilation errors does not stop cleanly #45410 (closed)
• x/tools/gopls: make go.mod diagnostics on mismatched requirements available when go.work is used #48920
• cmd/go doesn't recognize forward go directive when tool section is present in go.mod #70949 (closed)

Related Code Changes

• cmd/go: use os.Executable to find GOROOT

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

seems like when it builds a tool it prints the location of it in the temporary work directory, rather than the final location in the build cache

CC @matloob @samthanawalla

I figured out the cause on the bug. would u mind if i take this issue up and propose a PR

Change https://go.dev/cl/658395 mentions this issue: cmd/go: respect -n flag in 'go tool' command

The behavior in your repro log doesn't match what I'd expect: specifically my expectation is that we return the temp file location the first time we run go tool (where the tool is not yet cached) and the location to the cached path afterwards. Here's a log from my repro:

matloob@matloob-mac Desktop % mkdir repro
matloob@matloob-mac Desktop % go mod init example.com/repro
go: creating new go.mod: module example.com/repro
go: to add module requirements and sums:
	go mod tidy
matloob@matloob-mac Desktop % go get -tool github.com/iwahbe/helpmakego
go: downloading github.com/iwahbe/helpmakego v0.1.0
go: added github.com/inconshreveable/mousetrap v1.1.0
go: added github.com/iwahbe/helpmakego v0.1.0
go: added github.com/spf13/cobra v1.8.1
go: added github.com/spf13/pflag v1.0.5
go: added golang.org/x/mod v0.22.0
matloob@matloob-mac Desktop % go tool -n github.com/iwahbe/helpmakego
/var/folders/k3/3s_zz9nx1ms089s9vjb70xw8004_sl/T/go-build1617190989/b001/exe/helpmakego

matloob@matloob-mac Desktop % 
matloob@matloob-mac Desktop % go tool -n github.com/iwahbe/helpmakego
/Users/matloob/Library/Caches/go-build/11/1102170b7a6b4ae7d914933cb74aac17d22032c6b28f695dfdafa976774e1f5c-d/helpmakego
matloob@matloob-mac Desktop % rm /Users/matloob/Library/Caches/go-build/11/1102170b7a6b4ae7d914933cb74aac17d22032c6b28f695dfdafa976774e1f5c-d/helpmakego

matloob@matloob-mac Desktop % go tool -n github.com/iwahbe/helpmakego
/var/folders/k3/3s_zz9nx1ms089s9vjb70xw8004_sl/T/go-build3727914114/b001/exe/helpmakego
matloob@matloob-mac Desktop % /var/folders/k3/3s_zz9nx1ms089s9vjb70xw8004_sl/T/go-build3727914114/b001/exe/helpmakego
zsh: no such file or directory: /var/folders/k3/3s_zz9nx1ms089s9vjb70xw8004_sl/T/go-build3727914114/b001/exe/helpmakego

What's happening is that the first time we build the binary, we build the executable to a temporary directory and then execute the command from the built location. (This is what go run did before executable caching was added) Every subsequent time, we fetch the executable from the cache and run it from there. If we decide to, we can make the example work by setting the 'built' field to be the cache location of the executable in the last condition in cmd/go/internal/work.(*Builder).updateBuildID.

I'm a bit unsure of doing this because the cache is supposed to be an implementation detail of the go command and it might not be a good idea for tools to depend on the path of the file in the cache. It is better to run go build -o to fetch the binary from the cache to a location controlled by the user, and then run the binary from there.

Of course if we decide that the file returned by -n isn't always available, we should update the documentation to indicate that the tool may not necessarily be available from the location returned by go tool -n.

@matloob I wanted to propose the same change considering a different implementation (behind the -n flag), to point the fresh cache to a.built, and poison the target. Another workaround I can propose is that we can print out an error if the cache misses, as it will be futile to try and run the build that doesn't exist. This way we can isolate the implementation in go tool.

Also in my opinion, with the -n flag, that output is not usable when run without a cache. I would propose to keep the implementation of -n similar to the other go commands, which would make it consistent and easier to work with.