You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Does this issue reproduce with the latest release?
What did you do?
go clean -n -gcflags=-S
What did you expect to see?
I expected the go command to reject the -gcflags flag because it makes no sense for that subcommand.
What did you see instead?
It quietly succeeded.
Many of the go subcommands are sensitive not just to which packages match the package pattern, but the specific set of source files selected for a build configuration. These call work.AddBuildFlags to register the flags that affect source selection, but this function also registers many flags that only affect actual compilation and linking.
The clean command is sensitive to source file selection because it finds all source files in the a package that have a correspondingly named binary in the directory (but are not part of package main) to delete the binaries.
The fix command uses work.AddBuildFlags, but appears not to be sensitive to any build flags, because it uses pkg.InternalAllGoFiles() to list source files, which should returns all source files regardless of source file selection.
The generate command only searches for go:generate directives in matched source files.
The full set of build flags makes sense for build, install, get, run, test, vet, and list because they all build source files (vet and list -export both invoke the toolchain to create up-to-date export files).
Yes some of the flags are unnecessary, but I am not sure we want to tease apart exactly which ones.
In theory any command that loads packages should support flags like -compiler and -tags, because, like GOOS and GOARCH, those can change which packages a particular wildcard like all matches (if you have packages that only contain //go:build-restricted files for a specific configuration).
Fix uses AddBuildFlags because I added it in https://go.dev/cl/240611. I didn't document why but since it was the buildtag fix I think it was to be able to run the fix on packages that only exist in certain configurations. Or maybe I just wanted -n and -x.