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

Jump to bottom

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

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

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

findleyr opened this issue Mar 31, 2022 · 4 comments
Labels
GoCommand cmd/go NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
Backlog

Comments

@findleyr
Copy link
Contributor

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
Contributor

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 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 Feedback is required from experts, contributors, and/or the community before a change can be made. label Apr 5, 2022
@cherrymui cherrymui added this to the Backlog milestone Apr 5, 2022
@cherrymui cherrymui added the GoCommand cmd/go label Apr 5, 2022
@adonovan
Copy link
Member

adonovan commented Sep 27, 2022 •
edited

(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?)

What if the user builds gopls with an older toolchain (say 1.17) then later updates the go on the PATH to 1.18? Ideally the tool should be able to process files that don't use 1.18 features, and should instruct the go command to select files according to go1.17 release tags. But it may fail to process a tree that depends on go1.18 features, just as a compiler would. That requires a way for the application to tell the go command to behave "no newer than" its own go version.

@adonovan adonovan mentioned this issue Sep 27, 2022
Closed
@gopherbot
Copy link

Change https://go.dev/cl/435356 mentions this issue: go/packages: warn if 'go list' on PATH is too new

gopherbot pushed a commit to golang/tools that referenced this issue Sep 28, 2022
@adonovan
go/packages: issue error if 'go list' on PATH is too new
4dd4ddb 
An application that links in version 1.18 of (say)
go/types cannot process Go source files reported
by version 1.19 of 'go list'. There is no way to
tell go list to behave as if it was go1.18, so
for now we proceed with parsing/typechecking but,
in case of errors, we issue an additional informative
diagnostic.

Fixes golang/go#55883
Fixes golang/go#55045
Updates golang/go#50825
Updates golang/go#52078

Change-Id: I5fd99b09742c136f4db7f71d2a75e4cdb730460d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/435356
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Alan Donovan <adonovan@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
Reviewed-by: Zvonimir Pavlinovic <zpavlinovic@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
GoCommand cmd/go NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
5 participants
@bcmills @adonovan @gopherbot @cherrymui @findleyr