x/tools/gopls: better handling of “scripts” with //go:build ignore? #49657
Comments
gopherbot
added
Tools
|
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.
I'd rather just have gopls understand |
findleyr
added
the
FeatureRequest
|
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 ( I think it makes sense to try to land this for the next gopls release (v0.10.0). |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
PLS doesn't support
|
|
@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. |
|
@findleyr Thank you for your answer. I look forward to it. |
|
Change https://go.dev/cl/441877 mentions this issue: |
|
Oh boy, I can't wait to test this out :) Do we need to do anything special with gopls master for it to work? |
|
@mvdan please hold off for a few minutes -- I'm about to cut v0.10.0-pre.1; I embarassingly left a print statement in that will be fixed by https://go.dev/cl/442782 (I was debugging why parser.PackageClauseOnly parsed some comments after the package clause...) But to answer your question: there's a new configuration option "standaloneTags", which defaults to ["ignore"]. You can customize it if you use a a different set of tags to identify scripts. Otherwise it should just work. |
|
Gotcha. I can definitely wait a few minutes :) I will be trying it out tomorrow. |
|
Very interested to hear about anyone's experience with this feature, negative or positive: |
|
@findleyr, just checked in a couple of projects. If there are lots (tens to hundreds) of |
|
Just tested in a small project of mine in vscode, works perfectly. Been watching this for a while, thanks for implementing it @findleyr! |
|
I too confirm that it appears to work perfectly, on neovim :) |
|
I also have a directory with simple go scripts. I've been looking now for few hours how to make VS Code ignore the
errors. I found now this but even after adding |
|
@findleyr am I doing something wrong or my issue is something else? |
|
@RafalSkolasinski sorry we don't always catch comments on closed issues. I can't reproduce based on your description. Can you please file a new issue, following the issue template? For example, I would be interested to see your full version information (gopls and go command), as well as your settings. A reproducer would be ideal. |
gopls currently litters our project with a sea of red, because it assumes Go files are part of a package, but we have a lot of standalone Go scripts. (If there are C files in the same directory as the script, it gets upset about cgo. If there are multiple standalone scripts in the same directory, it gets uspet about duplicate files.) Per golang/go#49657 and https://github.com/golang/tools/blob/master/gopls/doc/settings.md#standalonetags-string, the convention seems to be a go:build ignore tag. Newer versions of gopls run in a "standalone" mode, so we still get all the nice LSP features. As part of this, I had to align the license header comments from /* block comments */ to // line comments. Go build constraints can only be preceded by blank lines and line comments. Block comments apparently aren't allowed. (See https://pkg.go.dev/cmd/go#hdr-Build_constraints.) If I leave the file unconverted, go fmt will immediately move the comment to above the license block. Change-Id: I47c69255522e9aae2bdb97a6e83fcc6ce0cf29d5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56525 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com> Auto-Submit: David Benjamin <davidben@google.com>
gopls currently litters our project with a sea of red, because it assumes Go files are part of a package, but we have a lot of standalone Go scripts. (If there are C files in the same directory as the script, it gets upset about cgo. If there are multiple standalone scripts in the same directory, it gets uspet about duplicate files.) Per golang/go#49657 and https://github.com/golang/tools/blob/master/gopls/doc/settings.md#standalonetags-string, the convention seems to be a go:build ignore tag. Newer versions of gopls run in a "standalone" mode, so we still get all the nice LSP features. As part of this, I had to align the license header comments from /* block comments */ to // line comments. Go build constraints can only be preceded by blank lines and line comments. Block comments apparently aren't allowed. (See https://pkg.go.dev/cmd/go#hdr-Build_constraints.) If I leave the file unconverted, go fmt will immediately move the comment to above the license block. Change-Id: I47c69255522e9aae2bdb97a6e83fcc6ce0cf29d5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56525 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com> Auto-Submit: David Benjamin <davidben@google.com> (cherry picked from commit 54b04fdc21d540a6e24f9ddb7ddc3e583518e24f)
gopls currently litters our project with a sea of red, because it assumes Go files are part of a package, but we have a lot of standalone Go scripts. (If there are C files in the same directory as the script, it gets upset about cgo. If there are multiple standalone scripts in the same directory, it gets uspet about duplicate files.) Per golang/go#49657 and https://github.com/golang/tools/blob/master/gopls/doc/settings.md#standalonetags-string, the convention seems to be a go:build ignore tag. Newer versions of gopls run in a "standalone" mode, so we still get all the nice LSP features. As part of this, I had to align the license header comments from /* block comments */ to // line comments. Go build constraints can only be preceded by blank lines and line comments. Block comments apparently aren't allowed. (See https://pkg.go.dev/cmd/go#hdr-Build_constraints.) If I leave the file unconverted, go fmt will immediately move the comment to above the license block. Change-Id: I47c69255522e9aae2bdb97a6e83fcc6ce0cf29d5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56525 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com> Auto-Submit: David Benjamin <davidben@google.com> (cherry picked from commit 54b04fdc21d540a6e24f9ddb7ddc3e583518e24f)
gopls currently litters our project with a sea of red, because it assumes Go files are part of a package, but we have a lot of standalone Go scripts. (If there are C files in the same directory as the script, it gets upset about cgo. If there are multiple standalone scripts in the same directory, it gets uspet about duplicate files.) Per golang/go#49657 and https://github.com/golang/tools/blob/master/gopls/doc/settings.md#standalonetags-string, the convention seems to be a go:build ignore tag. Newer versions of gopls run in a "standalone" mode, so we still get all the nice LSP features. As part of this, I had to align the license header comments from /* block comments */ to // line comments. Go build constraints can only be preceded by blank lines and line comments. Block comments apparently aren't allowed. (See https://pkg.go.dev/cmd/go#hdr-Build_constraints.) If I leave the file unconverted, go fmt will immediately move the comment to above the license block. Change-Id: I47c69255522e9aae2bdb97a6e83fcc6ce0cf29d5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56525 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com> Auto-Submit: David Benjamin <davidben@google.com> (cherry picked from commit 54b04fdc21d540a6e24f9ddb7ddc3e583518e24f)
gopls currently litters our project with a sea of red, because it assumes Go files are part of a package, but we have a lot of standalone Go scripts. (If there are C files in the same directory as the script, it gets upset about cgo. If there are multiple standalone scripts in the same directory, it gets uspet about duplicate files.) Per golang/go#49657 and https://github.com/golang/tools/blob/master/gopls/doc/settings.md#standalonetags-string, the convention seems to be a go:build ignore tag. Newer versions of gopls run in a "standalone" mode, so we still get all the nice LSP features. As part of this, I had to align the license header comments from /* block comments */ to // line comments. Go build constraints can only be preceded by blank lines and line comments. Block comments apparently aren't allowed. (See https://pkg.go.dev/cmd/go#hdr-Build_constraints.) If I leave the file unconverted, go fmt will immediately move the comment to above the license block. Change-Id: I47c69255522e9aae2bdb97a6e83fcc6ce0cf29d5 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/56525 Commit-Queue: Adam Langley <agl@google.com> Reviewed-by: Adam Langley <agl@google.com> Auto-Submit: David Benjamin <davidben@google.com> (cherry picked from commit 54b04fdc21d540a6e24f9ddb7ddc3e583518e24f)
I have a directory with several Go “scripts”. That is, files each of which has a
//go:build ingoredirective and its ownmain. Currently,goplsdoesn't seem to handle this pattern very well, as when I addignoreto the list of tags,goplsis confused by severalmains in what it sees as a single package.Is there a way to make
goplstreat such files as separate binaries?Or, perhaps, there should be a separate marker build tag for these things, like
//go:build run?The text was updated successfully, but these errors were encountered: