Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SA1019: reconsider "alternative available since" logic #1318

dominikh opened this issue Sep 17, 2022 · 3 comments

SA1019: reconsider "alternative available since" logic #1318

dominikh opened this issue Sep 17, 2022 · 3 comments


Copy link

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

Copy link

cespare commented Feb 2, 2023

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.

Copy link

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+).

Copy link
Owner Author

dominikh commented Feb 5, 2023

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
None yet
None yet

No branches or pull requests

3 participants