SA1019: reconsider "alternative available since" logic #1318
Comments
|
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. |
Exactly the reason why I am here. I still target Go 1.19 and am using |
|
I'll include this change in the next patch release. |
dominikh
added a commit
that referenced
this issue
Feb 14, 2023
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. Closes: gh-1318 (cherry picked from commit 6422635)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
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
The text was updated successfully, but these errors were encountered: