cmd/fix: `go fix -inline ./...` results in very large build cache

[connorszczepaniak-wk]

Go version

go version go1.26.1 darwin/arm64

Output of go env in your module/workspace:

❯ go env -changed
GOBIN='/Users/connorszczepaniak/go/bin'
GOPRIVATE='github.com/Workiva'

What did you do?

Ran go clean -cache, then ran go fix -inline ./... on a large Go repository.

What did you see happen?

An almost 100GB build cache:

❯ du -sh "$(go env GOCACHE)"
 98G    /Users/connorszczepaniak/Library/Caches/go-build

Furthermore, while the go fix was still running, total disk usage got closer to 200GB, but roughly 100GB was freed right before the command exited. This one is harder to show in a GitHub issue, but I observed by watching macOS's disk usage estimate. Often when running a go fix like this, I end up with many of the following errors:

mkdir /var/folders/14/dl88pgbs11766nqnslc5ry8h0000gs/T/go-build114066672/b14431/: no space left on device

I attempted a du -sh /var/folders/14/dl88pgbs11766nqnslc5ry8h0000gs/T during the go fix but the command hung.

What did you expect to see?

I'm not sure what I expect the Go build cache disk usage to look like, but 100GB seems high. The fact that there seems to be an (even more) ephemeral extra 100GB during the go fix was also surprising and means I need twice as much disk space available to run such a command.

[gabyhelp]

Related Issues

• build: significant build cache size increase on tip #71667 (closed)
• cmd/go: auto cache clean fail #31931 (closed)
• cmd/go: clean GOCACHE based on disk usage #29561
• Go builder caching policies might need another look #32578 (closed)
• cmd/go: size of go-build directory increasing rapidly #68872 (closed)
• all: repeatedly running all.bash in an unchanged tree grows the Go build cache without limit #61484
• cmd/go: DiskCache.Trim on macOS often blocks go command for >20 minutes #76314 (closed)
• cmd/compile: long symbol names for instantiated generics => large object files (though not executables) #50438
• cmd/fix: go fix duplicates `//go:fix inline` line #78196
• x/tools/gopls: `//go:fix inline` is very slow to compute fixes (excessive scans of Info.Uses and re-formatting/parsing of whole file) #75773 (closed)

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

[connorszczepaniak-wk]

If it's worth anything, go build ./... with a freshly cleaned cache is only 7.8GB:

❯ du -sh "$(go env GOCACHE)"
7.8G    /Users/connorszczepaniak/Library/Caches/go-build

Also: many of the above issues are about cache size in general, so probably related. I'm also specifically curious about the files in /var/... that seem to be doubling the cache size.

[adonovan]

Thanks for the bug report. I agree that is very high; we will investigate.

Curious: How many //go:fix inline annotations are there in your codebase? Is it on any huge functions (unlikely I know)?

[connorszczepaniak-wk]

As of filing this issue, I had 213 in a single file (all on constants) which is imported by several packages scattered across the codebase. Notable side note, go fix -inline ./... seemingly had no effect with this setup. Here's a sampling of the file in case I have the directives wrong:

	//go:fix inline
	ServerMsSinceEpoch = `serverMsSinceEpoch`
	//go:fix inline
	ClientMsSinceEpoch = `clientMsSinceEpoch`

[connorszczepaniak-wk]

Ah, I think my side-note above is answered by gopls and isn't because of this issue.

[adonovan]

I just ran go fix -diff over x/tools/gopls and observed that it creates a 533MB GOCACHE. The top 100 largest files (all >1MB) were all ar archives containing export data. Running without -diff, to create "fix archives", increased the cache by only a couple of percent. Running go build on the same target produced a GOCACHE of around 409MB, with fewer large ar archives (which I cannot yet explain). So the "fix" build and the regular build are commensurate in size, but fix also produces "facts", hence the increased size.

(Aside: if go fix could obtain type export data without generating object code it could be faster and its disk usage smaller. This aligns with an idea due to @cherrymui that we create a separate tool, not the compiler, for producing type export data for analysis tools.)

The gopls module doesn't make heavy use of //go:fix inline, and inline can produce large facts. So perhaps this issue is specific to that analyzer (as the issue title suggests).