Closed tri-adam closed 1 year ago
Hi!
The minimum Go version in the go.mod file only applies to dependencies that are used in the project being compiled. This program does not require features from Go newer than 1.13, even though it does look for features introduced in later Go versions.
While I do like the idea of using go.mod to enable/disable functionality, I can not spot a way to retrieve this info from the analyzer library that errorlint uses. So having a flag or reserved syntax as proposed in #36 are the next best options I think.
Hi @polyfloyd , thanks for the quick response.
While I do like the idea of using go.mod to enable/disable functionality, I can not spot a way to retrieve this info from the analyzer library that errorlint uses. So having a flag or reserved syntax as proposed in #36 are the next best options I think.
That makes sense. In the absence of a way to retrieve that info, a flag or reserved syntax seems like a good option.
Thanks again, really appreciate you work!
I have implemented a solution, see my last comment on #36
Thank you for the great linter!
I have an issue related to multiple
%w
verbs that is similar to but different than #36. When the minimum version specified ingo.mod
(ref) is <1.20, the linter will give anon-wrapping format verb for fmt.Errorf. Use '%w' to format errors
recommendation when encountering code such as the following:Following the recommendation, one would replace
"%v: %w"
with"%w: %w"
, which works fine with Go 1.20, but is incorrect with Go <1.20. For an example, with this code in the playground:With Go 1.19, the modified code does run but does not behave as expected, outputting:
With Go 1.20, it behaves as expected:
I'm wondering if
go-errorlint
could/should consider the minimum Go version specified ingo.mod
before making recommendations to wrap multiple errors?