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
In the past, the '-go' flag defaulted to the version of Go that
Staticcheck was built with. This wasn't a great default as it was
usually too aggressive, suggesting new language features right away,
despite most people wanting to support the last N versions of Go.
Go modules themselves specify a Go version to support. This version
restricts the set of Go language features that can be used in a
module. This maps quite well to our '-go' flag, which similarly
suppresses suggestions that would depend on a newer version of Go.
The mapping isn't perfect, in particular because we conflate language
features and the version of the standard library (a Go module
targeting Go 1.0 can't use newer language features, but it can still
use parts of the stdlib that were introduced in later versions), but
it is better than our previous default.
The user is still able to override the default if needed.
Due to the design of flags in go/analysis, we can't easily specify
different versions for different packages. In theory, this should not
be a problem, as the Go build system only allows operating on one
module at a time. We may still see a mix of packages where some have a
module and others don't – this is because the synthetic "foo.test"
packages are not part of the module. We can skip those. Should we ever
see more than one module, we fall back to the old default and emit a
warning.
If the user isn't operating in module mode, we fall back to the old
default.
Closesgh-853
0 commit comments