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

x/tools/gopls: better handling of “scripts” with //go:build ignore? #49657

Open
ainar-g opened this issue Nov 18, 2021 · 7 comments
Open
Assignees
Labels
FeatureRequest gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@ainar-g
Copy link
Contributor

ainar-g commented Nov 18, 2021

I have a directory with several Go “scripts”. That is, files each of which has a //go:build ingore directive and its own main. Currently, gopls doesn't seem to handle this pattern very well, as when I add ignore to the list of tags, gopls is confused by several mains in what it sees as a single package.

Is there a way to make gopls treat such files as separate binaries?

Or, perhaps, there should be a separate marker build tag for these things, like //go:build run?

@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Nov 18, 2021
@gopherbot gopherbot added this to the Unreleased milestone Nov 18, 2021
@findleyr
Copy link
Contributor

findleyr commented Nov 18, 2021

I think we've talked about this in the past; it would require making 'ignore' special, but that seems fine to me. We have a long-standing issue to improve handling of build tags (#29202), that this will probably be prioritized behind.

Or, perhaps, there should be a separate marker build tag for these things, like //go:build run?

I'd rather just have gopls understand ignore. There's plenty of code in the wild that uses this already. If this causes problems for anyone (because they use ignore to define multi-file packages), we can make it configurable. But I would be surprised if that happened.

@findleyr
Copy link
Contributor

findleyr commented Aug 4, 2022

This is perhaps a medium-sized project, but would resolve some of the pain points around build tags. While it requires an understanding of the complicated way that gopls resolves packages, it does not require duplicating the package graph, or even signficant refactoring of how we track packages: we simply need to teach our package loader (snapshot.Load) how to build synthetic packages for a special tag or sets of tags. In fact, supporting this for a single file only (i.e. not synthesizing multiple files into a package) is probably a small project.

I think it makes sense to try to land this for the next gopls release (v0.10.0).

@wonderfate

This comment was marked as off-topic.

@findleyr

This comment was marked as off-topic.

@wonderfate
Copy link

wonderfate commented Aug 14, 2022

@findleyr

PLS doesn't support //go:build ignore and it miserable me

image

@findleyr
Copy link
Contributor

findleyr commented Aug 14, 2022

@wonderfate this issue is currently scheduled for the next gopls release, in September. There's always a chance it may miss that milestone, but barring some unforeseen technical obstacle it should get done soon.

We understand that gopls doesn't work for ignored files, which is why this is prioritized.

@wonderfate
Copy link

wonderfate commented Aug 14, 2022

@findleyr Thank you for your answer. I look forward to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

4 participants