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

cmd/go: add a flag to set (or exclude) release tags #52078

Open
findleyr opened this issue Mar 31, 2022 · 2 comments
Open

cmd/go: add a flag to set (or exclude) release tags #52078

findleyr opened this issue Mar 31, 2022 · 2 comments
Labels
GoCommand NeedsDecision
Milestone

Comments

@findleyr
Copy link
Contributor

@findleyr findleyr commented Mar 31, 2022

In #50825, we want to allow developers to build gopls with a recent version of Go while still developing for older versions of Go. One blocker to doing this properly is that the set of release tags used in go list is not configurable: they are implied by the version of cmd/go.

We had speculated that #42504 (ignore all build constraints) could help here, but the amount of post-processing required by gopls in that case is prohibitive.

Can we add a flag to cmd/go that allows us to mutate the set of release tags? For example, could we:

  • add a -release flag (-release=1.16)?
  • overload the -compat flag (-compat=1.16)?
  • add a -notags flag (-notags=go1.17,go1.18)?

I defer entirely to the cmd/go team for flag design, but it would be great to have some way to achieve this.

CC @bcmills @matloob

@bcmills
Copy link
Member

@bcmills bcmills commented Apr 1, 2022

I've been thinking about this some more, but I'm not sure that I really grokked the problem space.

If the user has a gopls built with, say, go 1.18, and they're trying to develop against go 1.17, won't the go command itself (and its GOROOT) be 1.17? In that case, go list will have the correct flags by default.

(I don't see how users can realistically target an older Go version that they don't even have installed, given that the packages and identifiers in the Go standard library also change from one release to the next — are we planning to have gopls also filter out packages and identifiers based on GOROOT/api or similar?)

@findleyr
Copy link
Contributor Author

@findleyr findleyr commented Apr 1, 2022

are we planning to have gopls also filter out packages and identifiers based on GOROOT/api or similar?

Yes, that's part of the plan (see #50825) - add an analyzer to allow developers to preserve compatibility with older go versions independent of their installed version. For example, we frequently have this problem while working on gopls, that one doesn't discover that one has used a disallowed API until after mailing the CL and getting a build failure. Presumably this would also be useful for working on the compiler, which has a bootstrap requirement.

But maybe we can insist that if users want the extra accuracy of building packages exactly as go 1.N, they must use go 1.N for go list. In that case the current request become unnecessary. It's also the case that if we analyzed function bodies for non-workspace packages, we'd want to have an accurate GOROOT (lest we infer inaccurate facts for the target Go version)

I trust your intuition if you think this feature request is a bad idea. In light of the preceding paragraph I'm inclined to agree. Please feel free to close this based on your judgement.

@cherrymui cherrymui added the NeedsDecision label Apr 5, 2022
@cherrymui cherrymui added this to the Backlog milestone Apr 5, 2022
@cherrymui cherrymui added the GoCommand label Apr 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GoCommand NeedsDecision
Projects
None yet
Development

No branches or pull requests

3 participants