bump github.com/kulti/thelper from 0.5.1 to 0.6.2

[kulti]

In this release, I've added fuzzing test support.

kulti/thelper@v0.5.1...v0.6.2

[kulti]

Well, as I understand go 1.18 required to pass golangci-lint for new version of linter. So, this PR should be postponed due fix of #2649.

[ldez]

I'll add some commits to your PR to try something, if it doesn't work I'll remove them.

[ldez]

@kulti can you continue to use types.NewSignature instead of types.NewSignatureType like that your linter will pass the go1.17 build and tests?

I know that types.NewSignature is deprecated in go1.18.

https://github.com/golangci/golangci-lint/runs/5806544857?check_suite_focus=true

[kulti]

@ldez, that is not possible, because fuzzing tests are only in go 1.18. I've made a new release with old API support and wip commit to check.

[kulti]

I've seen that some linters disabled for go1.18. Maybe we can disable this linter for go1.18? Or use two versions — one will be disabled for >= go1.18, another for < go.1.18.

[ldez]

I've seen that some linters disabled for go1.18. Maybe we can disable this linter for go1.18? Or use two versions — one will be disabled for >= go1.18, another for < go.1.18.

We need to build with go1.17 in the CI, at least for now.

The linters are currently not handled by build tags, all linters can be built with go1.17.
They are just replaced/inactivated at runtime.

[ldez]

that is not possible, because fuzzing tests are only in go 1.18. I've made a new release with old API support and wip commit to check.

It's possible because you don't have go1.18 dependency except types.NewSignatureType

In your repo, you can play with build tags and split test files.

In golangci-lint we cannot do the same, we can just don't put tests for fuzz inside golangci-lint.

But your code must be go1.17 compatible.

[ldez]

Another solution is to release a v1 (go1.17) and v2 (go1.18) of your linter so that we will be able to use both versions.

The ZeroVer is not something great with go modules: go is able to manage 2 versions of a lib but a major version is required.
ZeroVer can be used for applications but for libraries it's a real problem.

In all cases, both versions will be a problem because the configuration will not be the same.

[kulti]

Ok. Thank you for your ideas. I'll think about them and try to fix build on the week.

[ldez]

I created a PR (#2744) to allow tests that use go1.18 in tests files.

The linters still need to build with go1.17.

[ldez]

LGTM