Use go.mod "go" version stenza to inject go version in linters

[didrocks]

Your feature request related to a problem? Please describe.

Some linters have different behavior based on the go version we use.

For instance, staticcheck disable SA3000 (os.Exit(m.Run()) required) from go 1.15+ as now upstream golang is storing the return code internally and this is not needed anymore.

However, golangci-lint assumes go 1.13 by default, (seen in https://golangci-lint.run/usage/configuration/):

  staticcheck:
    # Select the Go version to target. The default is '1.13'.
    go: "1.15"
    # https://staticcheck.io/docs/options#checks
    checks: [ "all" ]

making the some users confused: dominikh/go-tools#708 (comment).

In addition, multiple linters are in that situation and repeating the version in different places don’t seem optimal.

Describe the solution you'd like.

golangci-lint could extract from go.mod the go version used and inject on all those linters which expects a go version to follow it.

The config file could still set different go version by impacted linters to override this default.

Describe alternatives you've considered.

The other alternative is to specify on the golangci-lint command line a go version to inject, but it seems that removing one step and aligning the project on base go.mod could be a better user experience.

Nothing prevents an command line override the automated go.mod version detection though.

Additional context.

No response

[boring-cyborg]

Hey, thank you for opening your first Issue ! 🙂 If you would like to contribute we have a guide for contributors.

[ldez]

Can be linked to #2158

[ldez]

We planned to change the default in the v2:

golangci-lint/pkg/golinters/staticcheck_common.go

Lines 27 to 28 in 813ba7d

	// TODO: uses "1.13" for backward compatibility, but in the future (v2) must be set by using build.Default.ReleaseTags like staticcheck.
	return "1.13"

[dominikh]

but in the future (v2) must be set by using build.Default.ReleaseTags like staticcheck

You might be interested in dominikh/go-tools@c5ce990

[bunyk]

@dominikh So, what you are saying that it's better not to use build.Default.ReleaseTags, or did I misunderstand your commit?

I've checked, and ReleaseTags contains a list of versions from 1.1 to 1.17 (according to documentation "the list of Go releases the current release is compatible with."), and completely ignores the value in go.mod. So it is not a good fit to implement this feature because it will make go version with which golangci-lint is built the default one, while I have projects that use different versions of go ranging from 1.15 to 1.17, as declared in go.mod.

This approach is probably the way, but do we have packages loaded somewhere when we execute NewStaticCheck?

Or we should just try to parse go.mod in the folder from which we run linter, and treat it as an additional config?

Asking, because I was recently annoyed by SA3000 warning from staticcheck, almost created a bug ticket for it, and was not aware that I have to configure go version for each linter, so having this would be very useful.

[ldez]

close by #2913