You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Detect deprecated Go API based entirely on our database, not depending on deprecation markers.
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.
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+).
In the past, we made use of the AlternativeAvailableSince field. If a
function was deprecated in Go 1.6 and an alternative had been available
in Go 1.0, then we'd recommend using the alternative even if targeting
Go 1.2. The idea was to suggest writing future-proof code by using
already-existing alternatives. This had a major flaw, however: the user
would need to use at least Go 1.6 for Staticcheck to know that the
function had been deprecated. Thus, targeting Go 1.2 and using Go 1.2
would behave differently from targeting Go 1.2 and using Go 1.6. This is
especially a problem if the user tries to ignore the warning. Depending
on the Go version in use, the ignore directive may or may not match,
causing a warning of its own.
To avoid this issue, we no longer try to be smart. We now only compare
the targeted version against the version that deprecated an object.
(cherry picked from commit 6422635)