proposal: cmd/vet: gate newly restrictive checks on language version

[findleyr]

This issue is related to #71485, where a newly added vet check for go1.24 was suppressed if the language version is undefined, or < go1.24.
That new check tended to find a significant number of issues in existing code bases, and was liable to cause churn for our users. In one case (Fedora), it was estimated that it would take ~months to address all the findings.

It is important to Go's philosophy that users can easily update to the most recent Go toolchain. This motivates the Go1 compatibility promise, and our work on forward and backward compatibility. Generally speaking, we never want a new (or newly restrictive) check to prevent users from updating their toolchain. After all, the new bugs found by vet still exist when used with an older toolchain.

Therefore, this issue proposes the change in policy alluded to in #71485, and suggested by (at least) @rsc and @adonovan: new vet checks should be gated by the language version in which they were added. Specifically, they will only apply when the file version of the file containing the new diagnostics is at least the Go version of the toolchain in which the new check was added. This means they will only apply in modules where the go directive is at least go1.N, or in files gated by //go:build go1.N.

(In some cases, we may find errors so severe that we actually DO want them to be reported for existing code. That's fine, but I'd argue it should be an exception to the policy).

[ianlancetaylor]

If we do this, perhaps we should also add an option to vet to set the language version to use when checking, so that people can try out newer checks on their program before they update.

[seankhliao]

isn't this the same as #57063

[findleyr]

Yes, thanks @seankhliao (Gaby, where were you?!).

I'll close as a dupe.