-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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: add go:embed support #50262
Comments
This could be implemented with a code action+associated command that invokes window/showDocument. It could also be implemented with jump-to-definition+hover. I am not sure which is best, but this seems to belong in the gopls issue tracker. |
For individual files, code action associated with |
List of improvements
EDIT (rfindley): cross out semantic highlighting, as I think we should punt on that for now |
We should also include a quick-fix to add the missing "embed" import. |
New Features New analyzer for //go:embed comments Gopls now includes an analyzer for go:embed comment directives. At the moment, this analyzer checks that the "embed" import is present, but more analyses are planned for the future. See golang/go#50262 for more information. Improved hover for imports Hovering over an imported path now gives you the full package doc. Final support for Go 1.13 Per our support window, gopls v0.8.4 will be the final gopls release to support being built with Go 1.13. See golang/go#52982 for details. Bugfixes and Performance improvements Faster symbol indexing. Gopls builds a symbol index the first time symbol search is invoked. That indexing should be 3-4x faster with this release. Improved metadata invalidation (AKA fewer restarts). v0.8.4 fixes a couple of bugs that lead to gopls getting confused about packages and needing to be restarted. We're aware of more bugs of this nature, but are working on eliminating the need to ever restart gopls.
@vikblom expressed interest in picking this up. I think the semantic highlighting support is a bit tricky to implement, so let's separate that bit out for now. Viktor, if you are interested you could do the following:
I recommend doing this in two separate CLs. Adding the suggested fix is a little subtle (we should re-use the existing I'll tentatively assign you. Let me know if you don't think you'll be able to work on this. |
Well, @vikblom it turns out I cannot assign you, so I assigned myself as your proxy :) |
@findleyr thanks, makes sense to isolate the changes. |
Change https://go.dev/cl/504295 mentions this issue: |
Extend the embed directive analyzer. Verify that embed directives are followed by a single variable declaration. Updates golang/go#50262 Change-Id: Ib69bbfb3aab586a349360d501ceb714a5434e8bd Reviewed-on: https://go-review.googlesource.com/c/tools/+/504295 Reviewed-by: Alan Donovan <adonovan@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> Run-TryBot: Robert Findley <rfindley@google.com> gopls-CI: kokoro <noreply+kokoro@google.com>
Hi @findleyr, with the CL above merged I've started looking at suggesting a fix from the analyzer.
Are there any requirement on placement for the import? I'm used to placing blank imports like Edit: I've also played around with a |
Hi @vikblom yes, it sounds like you've got the right idea. There are two aproaches: either compute the edits inline as part of the analyzer, or defer them to later using the I think there's a problem though, which is that the presence of |
Thanks @findleyr that approach works great 👍 I've added a edit: I found exiting |
Change https://go.dev/cl/509056 mentions this issue: |
I noticed that I haven't kept all the docs up to speed, for example analyzers.md. That should probably be corrected as part of this issue. |
@vikblom the analyzer doc is auto-generated, and there is a test to enforce this: |
@findleyr I see! Then it's the analyzers |
Give the embeddirective source.Analyzer a Fix that can add missing "embed" imports. Since not all reports from the analyzer is this diagnostic, give source.Analyzer an IsFixable method to filter diagnostics. Updates golang/go#50262 Change-Id: I24abdd2d1a88fc5cabd3197ef438c4da041a6a9c Reviewed-on: https://go-review.googlesource.com/c/tools/+/509056 Run-TryBot: Robert Findley <rfindley@google.com> gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Change https://go.dev/cl/513895 mentions this issue: |
Bring the analyzer documentation up to speed. Include the recently added feature to check the declaration following the directive. Also fix typo in package comment. Updates golang/go#50262 Change-Id: I0e7a8de0ba10cd414251afe1e9c65ded2090f408 Reviewed-on: https://go-review.googlesource.com/c/tools/+/513895 Reviewed-by: Robert Findley <rfindley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Robert Findley <rfindley@google.com> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com> gopls-CI: kokoro <noreply+kokoro@google.com>
Hi @findleyr, is there a path forward with semantic highlighting here, given that the vscode ticket was closed by triage? I tried out a naive You mentioned code action+associated command and jump-to-definition+hover above, which seems doable. However if VSCode requires specific (or new) mechanisms to handle directories, this feature might spread to codebases ( |
Hi @vikblom, very sorry for the slow response on this. Let's not worry about semantic tokens for now, I think that's a low priority. We can treat highlighting We discussed this in our triage meeting, and I think jump-to-definition+hover is the best way to implement this feature, as it will be supported by the greatest number of LSP clients. For directories, perhaps we should just pick an arbitrary file in the directory? |
An arbitrary file could be unexpected as a user. But I don't see any alternatives if this is a limitation of LSP clients. I agree it is a good place to start. I'll try to put something together and post a CL. |
Great, thanks for sticking to this! |
Change https://go.dev/cl/530195 mentions this issue: |
Enables hover on arguments of go:embed directives. The hover body lists files matching the argument pattern. Updates golang/go#50262 Change-Id: I523cec6ab633c90d6826cdbdd6d8fca6afd98935 Reviewed-on: https://go-review.googlesource.com/c/tools/+/530195 Reviewed-by: Robert Findley <rfindley@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Suzy Mueller <suzmue@golang.org>
Change https://go.dev/cl/531775 mentions this issue: |
Enable jump to definition on //go:embed directive arguments. If multiple files match the pattern one is picked at random. Improve the pattern matching for both definition and hover to exclude directories since they are not embeddable in themselves. Updates golang/go#50262 Change-Id: I09da40f195e8edfe661acaacd99f62d9f577e9ea Reviewed-on: https://go-review.googlesource.com/c/tools/+/531775 Reviewed-by: Robert Findley <rfindley@google.com> Reviewed-by: Suzy Mueller <suzmue@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Hi @findleyr, what do you think is the next step? Would tackling semantic highlighting make sense? |
@vikblom if we're going to highlight go:embed, I think we should highlight all go: directives. Is that something you'd be interested in? If so, I think we should perhaps make that a separate issue, and close this one. |
Sure, I'd be glad to take a look directive highlights! Thanks again for all the help in this issue. |
Great! Opened https://go.dev/issue/63538. Will close this then. |
Is your feature request related to a problem? Please describe.
Go embed feature introduced in version 1.16. Currently, go-vscode treats text like
//go:embed app
as a simple comment.Describe the solution you'd like
Provide text highlighting or navigation by CTRL+Clicking on these comments
Describe alternatives you've considered
![Screenshot from 2021-12-10 18-21-42](https://user-images.githubusercontent.com/5591800/145593824-0f36941c-4ba4-40e0-a37b-7aa3f2001bcb.png)
Goland provides this feature in its recent versions:
Additional context
![Screenshot from 2021-12-10 18-25-51](https://user-images.githubusercontent.com/5591800/145593934-1ca3c7fb-1701-4ba6-b7f5-97ea6f740c9f.png)
VS code view
It would be really nice if we have this feature in my favorite code editor.
The text was updated successfully, but these errors were encountered: