Repository navigation
config: compare files against GOCACHE, not the user cache dir - #1849
Open
CloudCorpRecords wants to merge 1 commit into
Open
CloudCorpRecords wants to merge 1 commit into
CloudCorpRecords wants to merge 1 commit into
Conversation
Dir skipped every file below os.UserCacheDir, taking it for a file in Go's build cache. That silently ignored the staticcheck.conf of any package living below the user cache directory (such as git worktrees kept in ~/.cache), as well as packages below paths that merely share a string prefix with it, and it missed the build cache whenever GOCACHE pointed elsewhere. Compare against the actual build cache instead: the GOCACHE environment variable, then `go env GOCACHE` (which also accounts for the go/env file), falling back to the default location below the user cache directory. Membership is now tested on a path boundary instead of a string prefix. Fixes dominikh#1847 Signed-off-by: Rene Turcios <95189389+CloudCorpRecords@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1847.
config.Dirskipped every file whose path started withos.UserCacheDir(), taking it for a file in Go's build cache. A package whose files all live below the user cache directory (for example a git worktree kept in~/.cache) therefore ended up withDefaultConfig, itsstaticcheck.confsilently ignored. The string-prefix test also caught paths that merely share a prefix with the cache directory (such as~/.cache-like), and it missed the build cache wheneverGOCACHEwas set to a directory outside the user cache directory.This change compares against Go's build cache itself, as suggested in the issue:
GOCACHEenvironment variable first, thengo env GOCACHE(which also accounts forGOCACHEset in the go/env file), falling back to the default location (go-buildbelow the user cache directory) if neither works.GOCACHE=offdisables the skipping.filepath.Rel, i.e. on a path boundary, instead ofstrings.HasPrefix. This also resolves the FIXME that was next to the old test.The guard itself is preserved: a package consisting only of files in the build cache (such as the test main package synthesized by
go list -test) still yields no configuration directory.Tests
New
config/config_test.gocovers the directory logic directly (the package previously had no tests): a package below the user cache dir, packages sharing a string prefix with the user cache dir and with the build cache, packages consisting only of build-cache files, mixed file lists, and an empty build cache.Verified on Windows (the same code path reads
%LocalAppData%there), Go 1.27.3:DirAPI with the realos.UserCacheDir()failed both bug cases:Dirreturned""for a package below the user cache dir and for one below a-likeprefix sibling. After the fix it passes, including the build-cache-only guard case.go test ./config/ -count=1passes (9 table cases + the public-API test);go vet ./config/is clean;go build ./...passes.staticcheckbinaries built from pristine master and from this branch, on the issue's repro project (checks = ["inherit", "-ST1005"]and a capitalized error string) placed under the user cache dir: pristine master reportsrepro.go:5:12: error strings should not be capitalized (ST1005), the fixed binary reports nothing. Controls: the fixed binary still reports ST1005 for the same project without astaticcheck.conf, and both binaries honour the config for a project outside the cache dir. The result is the same when the project has a test file, i.e. when a synthesized test main package lives in the build cache.