cmd/go/internal/tool: include dynamically buildable tools in go tool …
…output
Fixes #75960
This PR will be imported into Gerrit with the title and first
comment (this text) used to generate the subject and body of
the Gerrit change.
**Please ensure you adhere to every item in this list.**
More info can be found at https://github.com/golang/go/wiki/CommitMessage
+ The PR title is formatted as follows: `net/http: frob the quux before blarfing`
+ The package name goes before the colon
+ The part after the colon uses the verb tense + phrase that completes the blank in,
"This change modifies Go to ___________"
+ Lowercase verb after the colon
+ No trailing period
+ Keep the title as short as possible. ideally under 76 characters or shorter
+ No Markdown
+ The first PR comment (this one) is wrapped at 76 characters, unless it's
really needed (ASCII art, table, or long link)
+ If there is a corresponding issue, add either `Fixes #1234` or `Updates #1234`
(the latter if this is not a complete fix) to this comment
+ If referring to a repo other than `golang/go` you can use the
`owner/repo#issue_number` syntax: `Fixes golang/tools#1234`
+ We do not use Signed-off-by lines in Go. Please don't add them.
Our Gerrit server & GitHub bots enforce CLA compliance instead.
+ Delete these instructions once you have read and applied them
diff --git a/src/cmd/go/internal/tool/tool.go b/src/cmd/go/internal/tool/tool.go
index 75a8fab..8483961 100644
--- a/src/cmd/go/internal/tool/tool.go
+++ b/src/cmd/go/internal/tool/tool.go
@@ -19,6 +19,7 @@
"os/exec"
"os/signal"
"path"
+ "path/filepath"
"slices"
"sort"
"strings"
@@ -147,6 +148,8 @@
return
}
+ toolSet := make(map[string]bool)
+
sort.Strings(names)
for _, name := range names {
// Unify presentation by going to lower case.
@@ -158,9 +161,36 @@
if cfg.BuildToolchainName == "gccgo" && !isGccgoTool(name) {
continue
}
+ toolSet[name] = true
fmt.Println(name)
}
+ // Also list builtin tools that can be built on demand.
+ // These are packages in cmd/ that would be installed to the tool directory.
+ cmdDir := filepath.Join(cfg.GOROOT, "src", "cmd")
+ entries, err := os.ReadDir(cmdDir)
+ if err == nil {
+ for _, entry := range entries {
+ if !entry.IsDir() {
+ continue
+ }
+ toolName := entry.Name()
+ // Skip packages that are not tools.
+ if toolName == "internal" || toolName == "vendor" {
+ continue
+ }
+ // Check if this tool is already in the tool directory.
+ if toolSet[toolName] {
+ continue
+ }
+ // Check if it's a valid builtin tool.
+ if tool := loadBuiltinTool(toolName); tool != "" {
+ toolSet[toolName] = true
+ fmt.Println(toolName)
+ }
+ }
+ }
+
modload.InitWorkfile(loaderstate)
modload.LoadModFile(loaderstate, ctx)
modTools := slices.Sorted(maps.Keys(loaderstate.MainModules.Tools()))
diff --git a/src/cmd/go/internal/tool/tool_test.go b/src/cmd/go/internal/tool/tool_test.go
new file mode 100644
index 0000000..d4a9186
--- /dev/null
+++ b/src/cmd/go/internal/tool/tool_test.go
@@ -0,0 +1,124 @@
+// Copyright 2025 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+package tool
+
+import (
+ "os"
+ "path/filepath"
+ "testing"
+)
+
+func TestListToolsBuiltinDiscovery(t *testing.T) {
+ // Test the directory scanning logic that was added to listTools
+ // This tests that we correctly identify directories and skip non-directories
+
+ // Create a temporary directory structure to simulate cmd/ directory
+ tempDir := t.TempDir()
+ cmdDir := filepath.Join(tempDir, "cmd")
+ if err := os.MkdirAll(cmdDir, 0755); err != nil {
+ t.Fatal(err)
+ }
+
+ // Create some tool directories
+ tools := []string{"vet", "cgo", "cover", "fix", "godoc"}
+ for _, tool := range tools {
+ toolDir := filepath.Join(cmdDir, tool)
+ if err := os.MkdirAll(toolDir, 0755); err != nil {
+ t.Fatal(err)
+ }
+ }
+
+ // Create some non-tool directories that should be skipped
+ nonTools := []string{"internal", "vendor"}
+ for _, nonTool := range nonTools {
+ nonToolDir := filepath.Join(cmdDir, nonTool)
+ if err := os.MkdirAll(nonToolDir, 0755); err != nil {
+ t.Fatal(err)
+ }
+ }
+
+ // Create a regular file (should be skipped)
+ filePath := filepath.Join(cmdDir, "not-a-directory.txt")
+ if err := os.WriteFile(filePath, []byte("test"), 0644); err != nil {
+ t.Fatal(err)
+ }
+
+ // Test directory reading logic (simulating the logic from listTools)
+ entries, err := os.ReadDir(cmdDir)
+ if err != nil {
+ t.Fatal(err)
+ }
+
+ var foundTools []string
+ for _, entry := range entries {
+ // Skip non-directories (this is the logic we added)
+ if !entry.IsDir() {
+ continue
+ }
+
+ toolName := entry.Name()
+ // Skip packages that are not tools (this is the logic we added)
+ if toolName == "internal" || toolName == "vendor" {
+ continue
+ }
+
+ foundTools = append(foundTools, toolName)
+ }
+
+ // Sort for consistent comparison
+ // (In the real code, this happens via the toolSet map and final output)
+ for i := 0; i < len(foundTools)-1; i++ {
+ for j := i + 1; j < len(foundTools); j++ {
+ if foundTools[i] > foundTools[j] {
+ foundTools[i], foundTools[j] = foundTools[j], foundTools[i]
+ }
+ }
+ }
+
+ // Verify we found the expected tools
+ expectedTools := []string{"cgo", "cover", "fix", "godoc", "vet"}
+ if len(foundTools) != len(expectedTools) {
+ t.Errorf("Found %d tools, expected %d: %v", len(foundTools), len(expectedTools), foundTools)
+ }
+
+ for i, expected := range expectedTools {
+ if i >= len(foundTools) || foundTools[i] != expected {
+ t.Errorf("Expected tool %q at position %d, got %q", expected, i, foundTools[i])
+ }
+ }
+}
+
+func TestToolSetTracking(t *testing.T) {
+ // Test the toolSet map logic that prevents duplicates
+ // This tests part of the new functionality in listTools
+
+ // Simulate the toolSet map logic
+ toolSet := make(map[string]bool)
+
+ // Add some tools to the set (simulating tools found in tool directory)
+ existingTools := []string{"vet", "cgo"}
+ for _, tool := range existingTools {
+ toolSet[tool] = true
+ }
+
+ // Test that existing tools are marked as present
+ for _, tool := range existingTools {
+ if !toolSet[tool] {
+ t.Errorf("Expected tool %q to be in toolSet", tool)
+ }
+ }
+
+ // Test that new tools can be added and checked
+ newTools := []string{"cover", "fix"}
+ for _, tool := range newTools {
+ if toolSet[tool] {
+ t.Errorf("Expected new tool %q to not be in toolSet initially", tool)
+ }
+ toolSet[tool] = true
+ if !toolSet[tool] {
+ t.Errorf("Expected tool %q to be in toolSet after adding", tool)
+ }
+ }
+}
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
I spotted some possible problems with your PR:
1. Do you still have the GitHub PR instructions in your commit message text? The PR instructions should be deleted once you have applied them.
2. It looks like you have a properly formated bug reference, but the convention is to put bug references at the bottom of the commit message, even if a bug is also mentioned in the body of the message.
Please address any problems by updating the GitHub PR.
When complete, mark this comment as 'Done' and click the [blue 'Reply' button](https://go.dev/wiki/GerritBot#i-left-a-reply-to-a-comment-in-gerrit-but-no-one-but-me-can-see-it) above. These findings are based on heuristics; if a finding does not apply, briefly reply here saying so.
To update the commit title or commit message body shown here in Gerrit, you must edit the GitHub PR title and PR description (the first comment) in the GitHub web interface using the 'Edit' button or 'Edit' menu entry there. Note: pushing a new commit to the PR will not automatically update the commit message used by Gerrit.
For more details, see:
(In general for Gerrit code reviews, the change author is expected to [log in to Gerrit](https://go-review.googlesource.com/login/) with a Gmail or other Google account and then close out each piece of feedback by marking it as 'Done' if implemented as suggested or otherwise reply to each review comment. See the [Review](https://go.dev/doc/contribute#review) section of the Contributing Guide for details.)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
I spotted some possible problems with your PR:
1. Do you still have the GitHub PR instructions in your commit message text? The PR instructions should be deleted once you have applied them.
2. It looks like you have a properly formated bug reference, but the convention is to put bug references at the bottom of the commit message, even if a bug is also mentioned in the body of the message.Please address any problems by updating the GitHub PR.
When complete, mark this comment as 'Done' and click the [blue 'Reply' button](https://go.dev/wiki/GerritBot#i-left-a-reply-to-a-comment-in-gerrit-but-no-one-but-me-can-see-it) above. These findings are based on heuristics; if a finding does not apply, briefly reply here saying so.
To update the commit title or commit message body shown here in Gerrit, you must edit the GitHub PR title and PR description (the first comment) in the GitHub web interface using the 'Edit' button or 'Edit' menu entry there. Note: pushing a new commit to the PR will not automatically update the commit message used by Gerrit.
For more details, see:
- [how to update commit messages](https://go.dev/wiki/GerritBot/#how-does-gerritbot-determine-the-final-commit-message) for PRs imported into Gerrit.
- the Go project's [conventions for commit messages](https://go.dev/doc/contribute#commit_messages) that you should follow.
(In general for Gerrit code reviews, the change author is expected to [log in to Gerrit](https://go-review.googlesource.com/login/) with a Gmail or other Google account and then close out each piece of feedback by marking it as 'Done' if implemented as suggested or otherwise reply to each review comment. See the [Review](https://go.dev/doc/contribute#review) section of the Contributing Guide for details.)
Hi could you take a look at these?
fmt.Println(name)we should print the cmd/ tool names in the same sorted list as the tools that exist in the tool directory.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Michael MatloobI spotted some possible problems with your PR:
1. Do you still have the GitHub PR instructions in your commit message text? The PR instructions should be deleted once you have applied them.
2. It looks like you have a properly formated bug reference, but the convention is to put bug references at the bottom of the commit message, even if a bug is also mentioned in the body of the message.Please address any problems by updating the GitHub PR.
When complete, mark this comment as 'Done' and click the [blue 'Reply' button](https://go.dev/wiki/GerritBot#i-left-a-reply-to-a-comment-in-gerrit-but-no-one-but-me-can-see-it) above. These findings are based on heuristics; if a finding does not apply, briefly reply here saying so.
To update the commit title or commit message body shown here in Gerrit, you must edit the GitHub PR title and PR description (the first comment) in the GitHub web interface using the 'Edit' button or 'Edit' menu entry there. Note: pushing a new commit to the PR will not automatically update the commit message used by Gerrit.
For more details, see:
- [how to update commit messages](https://go.dev/wiki/GerritBot/#how-does-gerritbot-determine-the-final-commit-message) for PRs imported into Gerrit.
- the Go project's [conventions for commit messages](https://go.dev/doc/contribute#commit_messages) that you should follow.
(In general for Gerrit code reviews, the change author is expected to [log in to Gerrit](https://go-review.googlesource.com/login/) with a Gmail or other Google account and then close out each piece of feedback by marking it as 'Done' if implemented as suggested or otherwise reply to each review comment. See the [Review](https://go.dev/doc/contribute#review) section of the Contributing Guide for details.)
Hi could you take a look at these?
Hi Michael, Actually Geerit bot owns the change set, I made the same mistake of adding a PR to github than gerrit. let me add a patcset over there and see if can update it or not.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Michael MatloobI spotted some possible problems with your PR:
1. Do you still have the GitHub PR instructions in your commit message text? The PR instructions should be deleted once you have applied them.
2. It looks like you have a properly formated bug reference, but the convention is to put bug references at the bottom of the commit message, even if a bug is also mentioned in the body of the message.Please address any problems by updating the GitHub PR.
When complete, mark this comment as 'Done' and click the [blue 'Reply' button](https://go.dev/wiki/GerritBot#i-left-a-reply-to-a-comment-in-gerrit-but-no-one-but-me-can-see-it) above. These findings are based on heuristics; if a finding does not apply, briefly reply here saying so.
To update the commit title or commit message body shown here in Gerrit, you must edit the GitHub PR title and PR description (the first comment) in the GitHub web interface using the 'Edit' button or 'Edit' menu entry there. Note: pushing a new commit to the PR will not automatically update the commit message used by Gerrit.
For more details, see:
- [how to update commit messages](https://go.dev/wiki/GerritBot/#how-does-gerritbot-determine-the-final-commit-message) for PRs imported into Gerrit.
- the Go project's [conventions for commit messages](https://go.dev/doc/contribute#commit_messages) that you should follow.
(In general for Gerrit code reviews, the change author is expected to [log in to Gerrit](https://go-review.googlesource.com/login/) with a Gmail or other Google account and then close out each piece of feedback by marking it as 'Done' if implemented as suggested or otherwise reply to each review comment. See the [Review](https://go.dev/doc/contribute#review) section of the Contributing Guide for details.)
Prince RoshanHi could you take a look at these?
Hi Michael, Actually Geerit bot owns the change set, I made the same mistake of adding a PR to github than gerrit. let me add a patcset over there and see if can update it or not.
sorry for the grammatical mistakes.
fmt.Println(name)we should print the cmd/ tool names in the same sorted list as the tools that exist in the tool directory.
```
/Users/proshan/langs/go/bin/go tool
addr2line
api
asm
buildid
cgo
compile
covdata
cover
dist
distpack
fix
link
nm
objdump
pack
pprof
preprofile
relnote
test2json
tools
trace
vet
```
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
toolSet := make(map[string]bool)
var toolNames []string
addTool := func(name string) {
if toolSet[name] {
return
}
toolSet[name] = true
toolNames = append(toolNames, name)
}it seems like we should just add things to the map instead of using addTool? then we can just get the map keys and sort them?
if err == nil {we should handle this error similar to on line 147
if toolName == "internal" || toolName == "vendor" {
continue
}could we remove this check this? loadBuiltinTool should return "" if it's not an actual too?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |