x/tools/gopls: imports and go to definition mostly don't work #32360
Labels
Milestone
Comments
|
For right now, imports are working in some files but not others. Go to definition is working. .... I haven't restarted VSCode since last night when imports and go to definition were both definitely broken. ¯\(ツ)/¯ |
|
Also notably, restarting VSCode does not fix the problem for me. |
|
Note: I've been reporting and trying to gather data on Go To Definition not working with a specific example in #32209, though it's inconsistent in that a small project is fine, but a big project is not. |
|
Awesome.... great debugging tip about showing gopls logs. Looks like it might be the same issue, I'm getting "no package found for x/y/z" |
|
From my gopls log: a ton of these: |
|
It's very weird... in two different files (both very small, like 30 lines) ... one imports correctly, one doesn't.... and yet in the one where it doesn't import, gopls isn't logging anything either. |
|
@natefinch: Are you able to attach a |
|
@mdhender: Do you mind filing a separate issue? I would expect that your issue is likely related to the symlinks. |
|
Here's logs from me opening the project, adding a line that should trigger goimports and saving (i.e. added [Info - 7:59:24 PM] #### Build info golang.org/x/tools/cmd/gopls Go infogo version go1.12.4 darwin/amd64 GOARCH="amd64" [Error - 8:00:00 PM] method "SetTraceNotification" not yet implemented |
|
I had the same problem -- failure of go to definition -- with a program that I downloaded (okta-hosted-login) and set up as a module not on my GOPATH. It compiled and ran, but I neglected to run Maybe this will help someone else like me, new to go modules, figure this out more quickly than I did! |
|
@natefinch: Can you try updating to the latest version of |
|
@ThisEndUp: Thanks for the report. It's true that @SteelPhase: Just to confirm - you replaced the actual name of the imported package with "package" everywhere in your example code and your logs? |
|
yes i did. I removed the log, as it wasn't representing the actual issue. I think my issue can be better represented by this https://gist.github.com/SteelPhase/89e1057214050d694c085c0c6fb9a970 |
|
@SteelPhase: Do you mind opening a new issue? Your case seems to be different from @natefinch's. |
|
I originally thought they were the same, but I resolved my issue by updating |
|
Added the info to the wiki, thanks @SteelPhase! (https://github.com/golang/go/wiki/gopls#vscode) |
|
That seems to have done it (though I have to set it higher than 3000 for it to be reliable). I updated gopls and ironically now I'm getting the The parse error is weird. Like, the code compiles fine before I add one little line that doesn't change whether or not it compiles. (that's what I was just adding |
|
I can corfirm having to set it higher than the 3000ms I was using previously as well. On windows, and a different project with module support enabled
{
"Dir": "A:\\Projects\\gvs\\VanguardAI\\pkg\\commands",
"ImportPath": "github.com/SteelPhase/VanguardAI/pkg/commands",
"Name": "commands",
"Module": {
"Path": "github.com/SteelPhase/VanguardAI",
"Main": true,
"Dir": "A:\\Projects\\gvs\\VanguardAI",
"GoMod": "A:\\Projects\\gvs\\VanguardAI\\go.mod",
"GoVersion": "1.12"
},
"Match": [
"."
],
"Stale": true,
"StaleReason": "stale dependency: github.com/bwmarrin/discordgo",
"GoFiles": [
"commands.go"
],
"Imports": [
"github.com/bwmarrin/discordgo"
],
"Deps": [
"bufio",
"bytes",
"compress/flate",
"compress/gzip",
"compress/zlib",
"container/list",
"context",
"crypto",
"crypto/aes",
"crypto/cipher",
"crypto/des",
"crypto/dsa",
"crypto/ecdsa",
"crypto/elliptic",
"crypto/hmac",
"crypto/internal/randutil",
"crypto/internal/subtle",
"crypto/md5",
"crypto/rand",
"crypto/rc4",
"crypto/rsa",
"crypto/sha1",
"crypto/sha256",
"crypto/sha512",
"crypto/subtle",
"crypto/tls",
"crypto/x509",
"crypto/x509/pkix",
"encoding",
"encoding/asn1",
"encoding/base64",
"encoding/binary",
"encoding/hex",
"encoding/json",
"encoding/pem",
"errors",
"fmt",
"github.com/bwmarrin/discordgo",
"github.com/gorilla/websocket",
"golang.org/x/crypto/internal/subtle",
"golang.org/x/crypto/nacl/secretbox",
"golang.org/x/crypto/poly1305",
"golang.org/x/crypto/salsa20/salsa",
"hash",
"hash/adler32",
"hash/crc32",
"image",
"image/color",
"image/internal/imageutil",
"image/jpeg",
"image/png",
"internal/bytealg",
"internal/cpu",
"internal/fmtsort",
"internal/nettrace",
"internal/poll",
"internal/race",
"internal/singleflight",
"internal/syscall/windows",
"internal/syscall/windows/registry",
"internal/syscall/windows/sysdll",
"internal/testlog",
"internal/x/crypto/chacha20poly1305",
"internal/x/crypto/cryptobyte",
"internal/x/crypto/cryptobyte/asn1",
"internal/x/crypto/curve25519",
"internal/x/crypto/hkdf",
"internal/x/crypto/internal/chacha20",
"internal/x/crypto/poly1305",
"internal/x/net/dns/dnsmessage",
"internal/x/net/http/httpguts",
"internal/x/net/http/httpproxy",
"internal/x/net/http2/hpack",
"internal/x/net/idna",
"internal/x/text/secure/bidirule",
"internal/x/text/transform",
"internal/x/text/unicode/bidi",
"internal/x/text/unicode/norm",
"io",
"io/ioutil",
"log",
"math",
"math/big",
"math/bits",
"math/rand",
"mime",
"mime/multipart",
"mime/quotedprintable",
"net",
"net/http",
"net/http/httptrace",
"net/http/internal",
"net/textproto",
"net/url",
"os",
"path",
"path/filepath",
"reflect",
"regexp",
"regexp/syntax",
"runtime",
"runtime/internal/atomic",
"runtime/internal/math",
"runtime/internal/sys",
"sort",
"strconv",
"strings",
"sync",
"sync/atomic",
"syscall",
"time",
"unicode",
"unicode/utf16",
"unicode/utf8",
"unsafe"
]
} |
|
@natefinch and @SteelPhase : Can you time Also, @natefinch, could you provide a repro case for code that compiles, but where |
|
I have the same issue with newest gopls. Go to definition doesn't work most of the time. Example https://github.com/gohugoio/hugo/blob/master/minifiers/minifiers.go#L66
|
|
I'm not getting go to definitions either and this is the log I can't figure out why it says |
|
That message is specifically related to gopls. Gopls will print out |
|
Change https://golang.org/cl/181317 mentions this issue: |
gopherbot
pushed a commit
to golang/tools
that referenced
this issue
Jun 11, 2019
If the context is canceled (or times out) during parsing, we were previously caching the package with no *ast.Files. Any further LSP queries against that package would fail because the package is already loaded, but none of the files are mapped to the package. Fix by propagating non-parse errors as "fatal" errors in parseFiles. typeCheck will propagate these errors and not cache the package. I also fixed the package cache to not cache errors loading packages. If you get an error like "context canceled" then none of the package's files are mapped to the package. This prevents the package from ever getting unmapped when its files are updated. I also added a retry mechanism where if the current request is not canceled but the package failed to load due to a previous request being canceled, this request can try loading the package again. Updates golang/go#32354, golang/go#32360 Change-Id: I466ddb8d336aeecf6e50f9f6d040787a86a60ca0 GitHub-Last-Rev: 5f1e7ef GitHub-Pull-Request: #110 Reviewed-on: https://go-review.googlesource.com/c/tools/+/181317 Run-TryBot: Rebecca Stambler <rstambler@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Rebecca Stambler <rstambler@golang.org>
|
Can people check if the errors still happen on master? |
|
@muirrn Hi, I just tried master version and and at least for me go to definition is working fine 👍 |
|
Change https://golang.org/cl/183718 mentions this issue: |
|
I'm not sure I understand why this was closed. My intention is not to be rude, because things have certainly improved. Unfortunately, I still don't get any pre-import autocompletion in VSCode, auto-import doesn't happen unless there's no errors in the file (which is super difficult to do without autocomplete of the thing I am trying to import), VSCode intermittently reports weird type errors that aren't real (which go away if I restart VSCode), and things are generally very sluggish (often taking 30-60s to show output in VSCode). I have been regularly updating to the current gopls, including this morning, and my experience feels like we're still short of imports and go-to-definition working correctly. Edit:
( |
|
Sorry, I missed the request to recheck this, but the experience is still very poor. This still regularly fails for me with the tip of gopls when adding a line that should add an import. add oddly, sometimes I go back to the same file and add a space at the end of the file and resave, and gopls adds the import almost instantly. I don't know what the difference is. |
|
@bmhatfield: We don't yet support pre-import autocomplete (#31906), but imports and go-to-definition should certainly be working. Are you seeing more problems with definitions past the issue you filed about the module cache? Do you mind filing a separate issue for the type errors that aren't real? Imports should be added no matter what state the file is in (formatting fails only if a file fails contains parse errors). @natefinch: It seems like in your case, I will re-open this issue, but with the statement that, due to the high frequency of changes to |
|
|
Thanks for the logs! Seems like a lot is going on, in particular, that |
|
Also, it looks like you're using a version of |
|
That's weird, I ran this after running I'll repro again and hope to get a better log with rpc.trace |
|
To get from master you will have to do |
|
I didn't notice the |
|
Tried it again on master, looks like maybe it's just timing out? [Trace - 4:37:37 PM] Received response 'textDocument/documentLink - (46)' in 33564ms. |
|
My best guess from these logs is that this 33-35 second latency number is about the cost of |
|
Also, are you using |
|
FWIW: I see a bunch of things on my 2015 work Mac Book Pro easily take 18 seconds on a relatively small project (just a few dozen files spread across ~3 or 4 packages). |
|
@freeformz: Do you mind attaching those logs? And same questions - are you using build tags or cgo? Does |
|
Also, this could be related: #32750. |
|
@stamblerre I am experiencing long delays on save (specifically when an import needs to be added) in VSCode (30-45s, I have a 60s timeout and sometimes it only completes half the needed imports), but based upon the commands you shared, it may be the result of a different problem:
|
stamblerre
changed the title
|
With Worse, this seems to accumulate — normal, light editing of code quickly saturates all cores for a while: I also see this if I just do a few bogus changes like hitting the enter key repeatedly, (Not sure if this is the right issue to report this on.) |
|
Chiming in here to say I've been staying reasonably current on |
|
@bmhatfield for future reference, what exact version are you on right now? |
(still not sure what EDIT: After poking around locally, it appears VSCode is building gopls from master. So I was on |
|
Great, thank you for sharing. I think this issue has become long enough that it's not worth leaving open. Please track improvements to imports speed here (#32750), and for other problems, please open a new issue. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Please answer these questions before submitting your issue. Thanks!
What did you do?
add a line that uses a new import. Save.
or
click go to definition on basically anything
What did you expect to see?
import added
or
go to definition
What did you see instead?
no import added. Sometimes it'll format but not import. Most of the time it does neither.
or
doesn't go to definition, saying no definition found
Does this issue reproduce with the latest release (go1.12.5)?
yes
System details
$ gopls version
golang.org/x/tools/cmd/gopls
golang.org/x/tools@v0.0.0-20190528151238-d238219cc233 h1:Q8gfsz3A5sYwJeRvYP/nWvLYwU5af6MHYyS8QbI2x88=
The text was updated successfully, but these errors were encountered: