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: support features (diagnostics, etc.) for open files inside of vendor directories #42527

Open
calbot opened this issue Nov 11, 2020 · 6 comments
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

@calbot
Copy link

calbot commented Nov 11, 2020

There should be some kind of message maybe in the gopls (server) output stating that a message wasn't recorded to PROBLEMS because it is from a file inside a "vendor" folder.

Also, maybe errors should be reported to PROBLEMS if you open code inside a folder which is a subfolder of vendor since you're probably developing in the vendored project itself.

@stamblerre stamblerre changed the title gopls doesn't report any errors to PROBLEMS if vscode project inside subfolder of "vendor" x/tools/gopls: report errors for open files inside of vendor directories Nov 11, 2020
@stamblerre stamblerre transferred this issue from golang/vscode-go Nov 11, 2020
@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 11, 2020
@gopherbot gopherbot added this to the Unreleased milestone Nov 11, 2020
@stamblerre stamblerre added this to Needs Triage in vscode-go: gopls by default via automation Nov 11, 2020
@stamblerre stamblerre moved this from Needs Triage to Non-critical in vscode-go: gopls by default Nov 12, 2020
@stamblerre stamblerre removed this from Non-critical in vscode-go: gopls by default Dec 16, 2020
@stamblerre stamblerre added this to Needs Triage in vscode-go: gopls by default via automation Dec 21, 2020
@stamblerre stamblerre changed the title x/tools/gopls: report errors for open files inside of vendor directories x/tools/gopls: support features (diagnostics, etc.) for open files inside of vendor directories Jan 6, 2021
@stamblerre stamblerre removed this from Needs Triage in vscode-go: gopls by default Jan 6, 2021
@Mutated1994
Copy link

Mutated1994 commented Feb 22, 2021

There should be some kind of message maybe in the gopls (server) output stating that a message wasn't recorded to PROBLEMS because it is from a file inside a "vendor" folder.

Also, maybe errors should be reported to PROBLEMS if you open code inside a folder which is a subfolder of vendor since you're probably developing in the vendored project itself.

I have resolved this issue, maybe you can try it?

index 8914d0dc..b7213f50 100644
--- a/internal/lsp/cache/load.go
+++ b/internal/lsp/cache/load.go
@@ -440,7 +440,7 @@ func (s *snapshot) setMetadata(ctx context.Context, pkgPath packagePath, pkg *pa
                // The package's files are in this view. It may be a workspace package.
                if strings.Contains(string(uri), "/vendor/") {
                        // Vendored packages are not likely to be interesting to the user.
-                       continue
+                       // continue
                }

                switch {
(END)

@Mutated1994
Copy link

Mutated1994 commented Feb 22, 2021

golang/tools#278

@stamblerre
Copy link
Contributor

stamblerre commented Feb 23, 2021

Thank you for looking into this issue, @Mutated1994. Unfortunately, I think we will have to spend some more time understanding how we can support features in vendored packages without marking them as workspace packages--since we diagnose all packages in the workspace.

@Mutated1994
Copy link

Mutated1994 commented Feb 23, 2021

Thank you for looking into this issue, @Mutated1994. Unfortunately, I think we will have to spend some more time understanding how we can support features in vendored packages without marking them as workspace packages--since we diagnose all packages in the workspace.

Gotcha!

@ronakg
Copy link

ronakg commented Jun 28, 2021

Thanks @stamblerre for linking me here. In my case, some features are already working inside the vendor directory. I'm able to get references, implementations, definitions for few types. It's just not clear what works and what doesn't.

@schellj
Copy link

schellj commented Sep 24, 2021

Noting that I ran into issues because I had created an package internal to my project with a path like <ROOT>/module/vendor/foo. Took me quite a while to figure out why LSP features were not working in files under the /module/vendor/foo/ directory.

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
No open projects
Development

No branches or pull requests

7 participants