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 · 4 comments

Comments

@calbot
Copy link

@calbot 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 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 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)
@stamblerre
Copy link
Contributor

@stamblerre 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 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!

@stamblerre stamblerre added this to To Do in gopls: v1.0.0 Feb 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants