Currently, when a user opens a workspace with no top-level module but
multiple modules in subdirectories, gopls treats that as an invalid
build configuration and reports an error message that may be difficult
for the user to understand (a go list error message about creating a
main module in the top-level directory). Instead, show a more useful
error message about the gopls workspace layout in both the progress bar
and as a diagnostic on every open file.
This fix only works for GO111MODULE=on (for now) because it's a lot
easier to interpret user intent, and the go command will return no
packages. The next step will be to improve error messaging for
GO111MODULE=auto and for users with nested modules.
Updates golang/go#42109
Change-Id: I702ca6745f7e080ff6704ade7843972ab469ccf3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272346
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
In some cases (such as presenting more helpful error messages), we need
to know the number of go.mod files in the workspace--not just the
active go.mod files. Track both known and active mod files separately.
Change-Id: I068f76c2930c90cd0fdf5ce637e5934210880f65
Reviewed-on: https://go-review.googlesource.com/c/tools/+/273047
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
(source.Package).Imports only returns successful imports, but go mod
tidy looks at all of them, so we need to include MissingDependencies in
the key too.
Change-Id: I790fd8d3cfd8e85be18a435698954e55611cfd8c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274240
Trust: Heschi Kreinick <heschi@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Previously, we had an optional file search limit in the findModules
function. We should stay consistent, so change that to a non-optional
default of 1 million files. We should adjust this if it's necessary to
reduce the limit.
Change-Id: I2664a8760362d03d40867c8208ae0b83111cd4f4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/273307
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Without this, analysis diagnostics have to wait until the entire
workspace is analyzed, which has a noticeable latency.
Refactored diagnosePkg out of diagnose to reuse code, and cleaned up
the showMsg and seen file logic a little bit.
Fixesgolang/go#42499
Change-Id: I51314dab156dce87dc19eba997c53d2aea428b6c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/269197
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
We can offer better error messages to users in GOPATH mode. The Go
command has clear error messages indicating where it's looking for
its dependencies, so we can borrow these messages too.
The error message will look like this:
https://user-images.githubusercontent.com/5856771/100292862-bde8bb00-2f4f-11eb-9920-d945ee2c7e87.png
Change-Id: I39d367d0731ea5b7b7bb963699be3003b4fefe86
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274119
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
We don't check the value of GO111MODULE before finding all of the
modules in the workspace, meaning we treat the workspace as if it has
modules even if modules are disabled. Before creating a workspace,
we now do check this.
Change-Id: I36b9d13f3b8382e65de36b4b4deed68f5b59e21d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/273309
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
We currently have partial, untested support for symlinks. Remove all
support for now until we come up with a decision.
I thought we could re-enable the OpenBSD trybot since we think it was
failing because of the latency of evaluating symlinks, but it seems like
it's still failing.
Updates golang/go#42833
Change-Id: Iece1741def4eaaeffe5fecd10f884c1cce87f449
Reviewed-on: https://go-review.googlesource.com/c/tools/+/273190
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
gc_details runs against on-disk files, so showing the resulting
diagnostic on unsaved buffers can result in incorrect positions.
Change-Id: I997d01776b9a31dfb2aa731d6d9b1ac34f22f771
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272747
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Trust: Robert Findley <rfindley@google.com>
If XDG_RUNTIME_DIR is set, it makes more sense as a location for the
gopls daemon socket than TMPDIR.
This avoids auto discovery issues when TMPDIR is overridden for certain
editors.
For golang/go#41266
Change-Id: I5a0a20c6185ca60d8ff03b8d948b17a636aa8404
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274272
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Expanding the set of modifications in the cache package leads to a
mismatch when the didModifyFiles code in text_synchronization.go
processes the list of modifications.
Change-Id: Id0b7fea445103b34838fb9b03aee95a01e454306
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274192
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
A guard against publishing stale diagnostics was removed in CL 269677,
because the signficance of diagnoseDetached was overlooked. Restore it.
For golang/go#42837
Change-Id: I911c4707a9c18a632ce32e0c25c43ae2e92135b2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274241
Run-TryBot: Robert Findley <rfindley@google.com>
Trust: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
While evaluating workspace symbols, we avoid duplicate packages per
package path in an effort to save computing time and eliminate duplicate
results. But for simplicity, we later guard to ensure that we don't ever
walk files twice.
We can just rely on this guard to prevent duplication, and walk all
known packages. This ensures we don't miss symbols, at minimal
additional cost, and simplies the code.
Fixesgolang/go#42791
Change-Id: I97000dbe29e67bda6071d5119a6edb7c5fa4da80
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272686
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Presently ifaceassert.go panics if given asserts whose
types reduce to
[]interface{}.(string)
which is illegal Go. Its tests won't even run on such code, but
gopls will happily invoke it. This CL adds a test for nil.
See golang/go#42857
Change-Id: I2791f4bd0b58559e65e6590822ac8f4123989273
Reviewed-on: https://go-review.googlesource.com/c/tools/+/273766
Reviewed-by: Michael Matloob <matloob@golang.org>
Trust: Peter Weinberger <pjw@google.com>
This updates fillstruct to work even when the struct is partially
filled. User supplied fields are preserved but comments are blown away.
Preserving comments appears to be very hard with the current ast
library. One possible option is to do manual string shenanigans, but
after exploring that path it seems like A Bad Idea.
Fixesgolang/go#39804
Change-Id: Iec0bb93db05d4d726dfa6c77a8139f53b14bcc77
Reviewed-on: https://go-review.googlesource.com/c/tools/+/262018
Run-TryBot: Jean de Klerk <deklerk@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Jean de Klerk <deklerk@google.com>
For example:
func wantsInt64(int64) {}
func wantsDuration(time.Duration) {}
func _() {
for i := range []string{} {
// inserts "i" as "int64(i)"
wantsInt64(i<>)
// inserts "i" as "time.Duration(i)"
wantsDuration(i<>)
}
}
Type converted candidates have a significant score penalty so they
should never outrank a directly assignable candidate, other factors
being equal.
To minimize false positive completions, we don't offer converted
candidates if either:
- The candidate is a deep completion into another package. This avoids
random "float64(somepkg.SomeVar)" popping up when completing a
float64.
- Don't offer to convert ints to strings since that's not normally
what the user wants.
After going back and forth I decided not to include the type
conversion in the candidate label. This means you will just see the
candidate "i" in the completion popup instead of "float64(i)". Type
names add a lot of noise to the candidate list.
I also tweaked the untyped constant penalty to interplay better with
the new type conversion penalty. I wanted untyped constants to be
ranked above type conversion candidates since they are directly
assignable, so I reduced untyped constants' penalty. However, to
continue suppressing untyped constants from random other packages, I
applied a similar heuristic to above where we give a bigger penalty if
the untyped constant is a deep completion from another package.
Fixesgolang/go#42764.
Updates golang/go#39207 (untyped constant penalty tweak may improve
this situation).
Change-Id: I565114b3a1c9628285d07200b9dfc45c61e5d898
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272286
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
Trust: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
We can offer better error messages to users in GOPATH mode. The Go
command has clear error messages indicating where it's looking for
its dependencies, so we can borrow these messages too.
The error message will look like this:
https://user-images.githubusercontent.com/5856771/100292862-bde8bb00-2f4f-11eb-9920-d945ee2c7e87.png
Change-Id: I888b33804eec7f38c329ae2e4343b82fcc22f1df
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272166
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Some of our options were listed as experimental, despite being fairly
stable and intended for general use. Others were listed as user options,
when they should really be "deprecated" and moved into the internal
options section (which has no public documentation). Moved these various
options into the correct sections.
Fixesgolang/go#42674
Change-Id: I89724521f70707f1feb4ecb8b5ed671e988d09eb
Reviewed-on: https://go-review.googlesource.com/c/tools/+/271420
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
VS Code's file watching API doesn't send notifications about directory
deletions unless you register for them explicitly (see
https://github.com/microsoft/vscode/issues/109754). Rather than watch
every file in the workspace, keep track of every relevant directory and
register file watchers for it.
This CL moves the snapshot's WorkspaceDirectories function to the
session and changes it to a KnownDirectories function. It returns all of
the directories and subdirectories known the session at a given moment.
Top-level directories are marked as such so that their *.{go,mod,sum}
contents can be watched, while subdirectories are just watched by path
so we can be notified of deletions.
Fixesgolang/go#42348
Change-Id: Ic6d02dba55b5de89370522ea5d3cf1d198927997
Reviewed-on: https://go-review.googlesource.com/c/tools/+/271438
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Trust: Rebecca Stambler <rstambler@golang.org>
This change adds Matthew Dempskys maligned analyser as fieldalignment,
modified to provide suggested fixes as well. The pass detect structs
that would take less memory if their fields were sorted.
It is also added to gopls as an opt-in analyser.
Change-Id: I549215807d2fb7244ea4f58739bab98b0dea9c0e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/270217
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Pontus Leitzler <leitzler@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Pontus Leitzler <leitzler@gmail.com>
Update the logic that extracts positions from error messages to handle
optional column numbers, and then use that function when extracting
go command errors. This will be useful in parsing go list errors.
Change-Id: Ie68de1439f002c30f785c0c121c5cec4f2fea727
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272095
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The workspace symbol tests are not really resilient to changes and
did not generate/use golden files consistently. This made it really
tricky to switch the workspace symbols defaults.
To improve the workflow, consolidate the different kinds of tests into
one function, generate and use golden files, and require that all of the
workspace symbol queries appear in one file only. Also converted the
brittle workspace symbol regtest to a marker test.
Update golang/go#41760
Change-Id: I41ccd3ae58ae08fea717c7d8e9a2a10330e8c14f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/271626
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Some features (notably, workspace symbols) produce results with file
paths outside of the command-line package. This logic can be useful for
all tests, so factor it out into the shared testing package.
Change-Id: I2e00ebc0174079660c2f07562c50fd9377088475
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272210
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Our handling of diagnostics has gotten complicated and has recently been
a source of bugs. Heschi and I took a step back and refactored the
diagnostic pass, starting with a new data structure for tracking
diagnostics.
The LSP server now holds a map of URI to collection of diagnostic
reports, which is used to track diagnostics as they are computed by
multiple sources. Additionally, this collection holds a hash of the
last published diagnostic set.
This new information allows us to implement an algorithm for
incrementally updating diagnostics on the server: diagnostics reports
are stored as they are computed for a snapshot, and then published in
(possibly multiple) passes, with the last pass for a snapshot being
marked as 'final'. In non-final passes, 'publishReports' publishes any
diagnostics that have already been computed for the snapshot, but does
nothing with URIs for which no diagnostics have been computed. In final
passes all diagnostics are reported, with empty diagnostics being
published for any URIs with no diagnostic reports. Any URIs for which no
diagnostic reports were computed are pruned from the diagnostic set. In
all cases, tracking the hash of published diagnostics prevents us from
duplicate publication.
This enables some simplifications of the existing diagnostic logic.
Computing new diagnostics and tracking send diagnostics is now handled
by the same algorithm, avoiding some bookkeeping. It is also no longer
necessary to explicitly clear diagnostics for deletions. This fixes some
previously broken edge cases, for example when packages go out of scope
due to go.mod or gopls.mod changes.
Fixesgolang/go#42198
Change-Id: Id0d8d0f7a60f6ffa8c33f0ae41763461f61dab7b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/269677
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
There was a bug and inconsistency in how const identifiers were
categorized when being used. The new code always makes them readonly
variables.
The predeclared identifiers (true, false, nil, iota) were treated
inconsistently. The new code makes them all readonly variables.
Under rare conditions the output from gopls semtok was not syntactic
Go code because is would put a /* comment immediately after an
operator /, thereby generating a spurious line comment.
Fixesgolang/go#42715
Change-Id: I5b1ccfaf607d6baa58c132e460c5617db6634a72
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272208
Trust: Peter Weinberger <pjw@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This build is suddenly timing out with high frequency. This requires
investigation, but for now we must get builds passing again.
For golang/go#42789
Change-Id: I51dc5eab227cfb77cd3021438f1b161b21f69caf
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272687
Run-TryBot: Robert Findley <rfindley@google.com>
Trust: Robert Findley <rfindley@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
We both showing errors as a popup and returning them to the client,
which would then most likely show them as a popup. Don't return errors
back to the client.
Change-Id: I8486534e19399d514752900025d6db8db85d5086
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272090
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
These tests require special cases and are difficult to understand in the
marker format. They are much simpler as regression tests.
Fixesgolang/go#40332
Change-Id: I791b9092d0f3d08aa5415eced427850626f8eb2a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272207
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
We should be consistent about whether we pass around Error or *Error.
*Error was somewhat more common, and its Error method has a pointer
receiver, so I picked *Error.
ErrorList, on the other hand, is usually dereferenced when used, and
slice headers are small enough to pass around casually. So switch that
over to a non-pointer and change its Error method to a value receiver.
Change-Id: I19e70201ed1d6ef36d217db21c9101bb810bcf0c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272092
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
In
type myAlias = someType
type _ struct {
myAlias
}
Previously running "definition" on the "myAlias" field would take you
to the definition of "someType" instead of "myAlias". This is because
we were using the field's (*types.Var).Type() which has already
forgotten it is an alias. Fix by instead looking up the field name
ident in types.Info.Uses which yields the *types.TypeName (for the
type alias).
Fixesgolang/go#42254.
Change-Id: Idbbd0c49ba6f701f52568b3ab1143d8e24037c69
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272186
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Muir Manders <muir@mnd.rs>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
If the user opens a parent directory of a single module, we can load
their workspace without using some of the workarounds of experimental
workspace mode, simply by narrowing the workspace to this nested
subdirectory.
Do this by extending findAllModules to support a limit on the number of
modules and files to search.
Updates golang/go#41558Fixesgolang/go#42108
Change-Id: Idba800a0deaeee5137d46f16a30b2012ff902a36
Reviewed-on: https://go-review.googlesource.com/c/tools/+/268877
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Trust: Robert Findley <rfindley@google.com>
This change adds support for showing go.mod parse errors as diagnostics.
There was previously a bug in parsing these error messages, and the
diagnostic reports were also not being published if the IWL failed.
Change-Id: I56197b91c49fb68e35d8886175435d5c38bfb8c2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272089
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
This change adds tracking for package name changes, which we can use to
determine if a workspace package ID may have changed or been removed.
It's a little bit tricky for something like a test variant, because you
want to invalidate the ID only if the test variant only files have
changed package names. I figured it would be ok (speed-wise) to call
guessPackageIDsForURI on the other files since this should be a pretty
rare case.
Fixesgolang/go#40690
Change-Id: Ib3f7eed526eb5bb455e17c362632ec7ac0ecd1cf
Reviewed-on: https://go-review.googlesource.com/c/tools/+/268157
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Throwing away all of the metadata in the package means it will be
expensive to reload, so it makes sense to keep it around until a go.mod
file has been saved, indicating that the user is more likely to be done
typing. Otherwise, we will be triggering full package metadata reloads
on every keystroke.
Fixesgolang/go#42529
Change-Id: Ibc4f4bc8937f8f7176da79e9fefe166468578993
Reviewed-on: https://go-review.googlesource.com/c/tools/+/271299
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
This allows us to show parsing errors as part of module diagnostics.
Change-Id: I558b95c145135482fdfceef8a5c68c62a6d32721
Reviewed-on: https://go-review.googlesource.com/c/tools/+/271630
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
This addresses the race seen in
https://storage.googleapis.com/go-build-log/5ba1c3f2/windows-386-2008_2bf3acc7.log.
Paraphrased from Rob in chat:
The race is triggered because of the additional asynchronous handling of
file changes added to sync non-dirty files on disk changes. The buffer
is marked as non-dirty, THEN the on-disk change is processed, sending a
didChange, THEN the didSave is sent (https://golang.org/cl/267577).
Also, don't send didChange for formatting if nothing has changed.
Change-Id: Ibc6a55d35dee99c04dadf5470c2d68ca937f849b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/271578
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Make the test a little more stable by making sure diagnostics complete
before organizing imports in these tests.
Change-Id: Id23341569207878554902887498632d6f1ce56cf
Reviewed-on: https://go-review.googlesource.com/c/tools/+/271628
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The current DidModifyFiles logic does not handle the possibility of a
directory URI in a didChangeWatchedFiles request. For creation and
changes, this is fine because only file URIs matter in those cases, but
for deletion, the deletion of a directory signifies the deletion of all
of the files in it.
Add handling for directories by looking up all of the known files in a
given directory. We then create file modifications for all of those
files, instead of the directory.
Fixesgolang/go#38422
Change-Id: I26d7b93285367fe116fd1cb3e8ec13a276f9e517
Reviewed-on: https://go-review.googlesource.com/c/tools/+/266138
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Trust: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
The tidy and upgrade code lenses first run the go command they
represent, then show the lens if there are changes to be made. While
this makes for a cleaner user experience, it also means that we're
running a go command that hits the network in a synchronous code lens
call. That's risky if the user is on a slow network connection.
Removing the call does represent a change, possibly a regression, in UX.
However, we already felt that the presentation of the upgrade option on
each dependency line was too noisy. Therefore the only remaining benefit
is that the lenses only appear when they have something to do. We've
decided that's not sufficient justification. Remove the calls.
We may recreate them as diagnostics in the future, so I've left
ModUpgrade around. (ModTidy is still used by diagnostics.)
Change-Id: I16c5eaebd1a50e5358c2addde9c1bb3f1182aac2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/271297
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Rebecca Stambler
Heschi Kreinick
Himanshu
Rob Findley
Peter Weinbergr
Jean de Klerk
Muir Manders
Pontus Leitzler
Michaël Lévesque-Dion
