feat: deprecate varcheck, deadcode, and structcheck

[ldez]

also, remove them from the default linters.

They can be replaced by unused.

varcheck and structcheck have not changed for 3 years. https://github.com/opennota/check / https://gitlab.com/opennota/check
deadcode have not changed for 6 years. https://github.com/remyoudompheng/go-misc

All those linters are using the deprecated golang.org/x/tools/go/loader API that is deprecated for more than 3 years (this API does not have support for Go modules).

https://github.com/golang/tools/blob/587a15310bddfc939d37cfaa8be8ea4c3808c3f1/go/loader/doc.go#L10-L11

Fixes #1841

issue related to structcheck:
Close #1517
Close #826

[bombsimon]

I like this change but curious about the reasoning for modifying default linters not being a breaking change. Breaking default behavior is usually a reason to reject suggestions and push them to v2 (f.e.x modifying or changing exclude use defaults) so this feels a bit inconsistent.

Won't //nolint directives for non enabled linters yield a warning by nolintlint?

[ldez]

In fact, unused already handles the same things as varcheck and deadcode.
As unused is enabled by default, it's not really a breaking change because the feature is still here, just not handled by the same linters.

Another point, as they are in the default linters, deprecation warnings will appear even if you are not using any configuration.

yes nolint directives will yield some warning, I don't know if this will be a bigger problem than linter changes.

[bombsimon]

In fact, unused already handles the same things as varcheck and deadcode. As unused is enabled by default, it's not really a breaking change because the feature is still here, just not handled by the same linters.

Yeah I get that the analysis result might be the same but the change can still result in changes that breaks CI or other workflows.

Another point, as they are in the default linters, deprecation warnings will appear even if you are not using any configuration.

Yup, and this is a great reason to disable them by default if deprecating, if not that would be a pretty bad user experience.

yes nolint directives will yield some warning, I don't know if this will be a bigger problem than linter changes.

Yeah me neither. Someone running without configuration and golangci-lint run -Enolintlint with //nolint:varcheck directives will start to get errors by just upgrading version. That to me is a change that I don't feel is in line with previous discussions where this project tend to be pretty restrictive to avoid breaking changes.

Maybe nolintlint isn't a big enough problem to block this kind of change, I just wanted to hear your reasoning around it. I feel I want to leave that decision up to you, personally I don't have a big problem to go less restrictive since bumping version always been a pretty controlled change for me where I've worked.

[bombsimon]

Change is good, resonable deprecation. As discussed might introduce breaking changes but I trust your judgment around this change!

[ejain]

unused detects an unused const x = 42, but, unlike deadcode, won't flag const X = 42.

[ldez]

varcheck and structcheck have not changed for 3 years. https://github.com/opennota/check / https://gitlab.com/opennota/check

So the project is abandoned.