SA1019: reconsider "alternative available since" logic

[dominikh]

Staticcheck tracks when API in the standard library was deprecated, and when an alternative has become available. For example, if a function was deprecated in Go 1.6, an alternative has been available already in 1.0, and we're targeting 1.2, then we flag the function, because 1.2 >= 1.0.

However, this interacts poorly with the fact that we fully rely on comment markers to know that something is deprecated in the first place. If the user uses Go 1.5, then there will be no marker, and the function will not get flagged. Once the user upgrades to Go 1.6, we'll start flagging it – even though the user hasn't changed which version of Go they were targeting. This is very similar to the problem fixed in 19a6a3c.

I see two solutions to this:

1. Detect deprecated Go API based entirely on our database, not depending on deprecation markers.
2. Remove our "alternative available since" logic, and only flag something as deprecated if the user is targeting a version >= that which deprecated it.

I think option 1 isn't perfect, either, and suffers from another variant of the problem: if the user upgrades Staticcheck, but keeps targeting the same Go version, they may start seeing deprecation warnings that weren't there before. We've just moved the problem from "which version of Go is installed" to "which version of Staticcheck is installed". So the only sensible option seems to be the removal of the logic.

/cc @cespare

[cespare]

I haven't thought about it too deeply but (2) seems right to me.

BTW I suspect a lot more people might start running into this in Go 1.20 with the deprecation of rand.Seed.

[proton-ab]

BTW I suspect a lot more people might start running into this in Go 1.20 with the deprecation of rand.Seed.

Exactly the reason why I am here. I still target Go 1.19 and am using rand.Seed knowingly in unit test yet got flagged for deprecation. This is somewhat unique situation because while I can switch to proposed alternative, I really shouldn't as I might risk forgetting about it when bumping target to 1.20 (for the use-case its unnecessary in 1.20+).

[dominikh]

I'll include this change in the next patch release.