Skip the runtime package as it does lots of stack switching that
causes false positives.
Change-Id: I001c5750db9f53b270073a05b4ae322141f4c49a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275518
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
`go get -u all` can have unexpected behavior for some users, since
upgrades all transitive dependencies as well as direct ones. Offer users
the ability to upgrade only direct dependencies via a code lens.
Also, change the placement of the upgrade code lenses. The module
declaration was getting cluttered, and they make more sense above the
requires anyway.
Updates golang/go#38339
Change-Id: I6790a02f2a334f3f4d1d89934b2c4dc4f11845ce
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275432
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>
Users working in large repositories may want to include only selected
directories in their workspace to avoid memory usage and performance
slowdowns. Add support for inclusion/exclusion filters that control what
directories are searched for workspace packages and modules. Packages
that are excluded by the filter may still be loaded as non-workspace
packages if other things depend on them.
For a description of the option's syntax, see the documentation.
Note that because we don't have any way to communicate the filters to
packages.Load, we still run go list on the unfiltered workspace scope,
then throw away the irrelevant packages. That may cost us, especially in
workspaces with many files.
Comments on the naming welcome. Also, if you know any places I may have
missed applying the filter, please do tell. One thing I thought of is
file watching, but that's covered because allKnownSubdirs works off of
workspace files and those are already filtered.
Possible enhancements:
- Support glob patterns.
- Apply filters during the goimports scan.
- Figure out how to apply the filters to packages.Load. I don't know
how to do it while still being build system neutral though.
Closesgolang/go#42473, assuming none of the enhancements are required.
Change-Id: I9006a7a361dc3bb3c11f78b05ff84981813035a0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275253
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>
Reviewed-by: Robert Findley <rfindley@google.com>
When GO111MODULE=auto and the workspace is outside of $GOPATH/src, we
should still show diagnostics about how to correctly configure
multi-module workspaces. We should not show these warnings for
workspaces outside of a module within GOPATH.
This adds an extra piece to the WorkspacePackages error logic--we may
still need to show the errors even if WorkspacePackages returned
results. We should eventually consolidate all of this logic to be more
cohesive, but for now I think it's more important to cover all of the
different cases and add tests.
Updates golang/go#42109
Change-Id: I673a03c9840cdaaf7f058de1cda3bf36b96fa7d3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275553
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>
In CL 268157, I tried to be careful about only deleting workspace
packages when we were certain they had been deleted. After investigating
this issue a little bit more in practice, I think we can afford to just
delete any package ID that has had a file change package names. We don't
always have valid metadata to use from the previous snapshot, and we
will pick up the new workspace package on the next reload.
Also, hardcode GO111MODULE=off for a test that was failing on my
machine at master.
Change-Id: I43a9d50821c90ad4b4560a6ff27d37bd572dbcd3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275536
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>
Trust: Rebecca Stambler <rstambler@golang.org>
When generating a default param name based on a type name, we want to
ignore any package qualifier. For example, if the type is "ast.Node"
we want to generate the variable name "n", so we must ignore the
"ast." qualifier. To do this we use a types.Qualifier that always
returns empty, but qualifyExpr wasn't respecting an empty qualifier
because it is doing manual ast manipulation. However, it seems like
things "just work" if you set a SelectorExpr's "X" to empty
string (i.e. only "Sel" is output when formatting).
Fixesgolang/go#42794.
Change-Id: Ied86b9511e4a9550590417c5a506fe35d561d4f9
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275519
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>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
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.
This is a roll-forward of CL 272686, which was accidentally submitted
too early.
Fixesgolang/go#42791
Change-Id: I8c39b7afe6c38fedb0e21831d88c28d13d51f102
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274243
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
When running with -mod=readonly, we need a go.sum to be present for go
command invocations. Achieve this by merging the go.sum of tracked
modules.
Fixesgolang/go#42509
Change-Id: I36dd084f865ebcee0ba6e1e542fdf51031b1487e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272886
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Trust: Robert Findley <rfindley@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Given package f containing f.go and f_test.go, the test variant for f
will have both in its list of go files. But the variant is deleted as
soon as f_test.go is deleted, and we should stop trying to load it.
Adjust the workspace package logic in (*snapshot).clone to consider only
_test files when checking whether to remove a test variant.
External tests don't need this logic, since they don't include the
normal files, but it doesn't hurt so there wasn't any point in being
picky.
Change-Id: Id0060ad4593545a85df74c3d1997338005ceb736
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275273
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
In Go 1.16 error codes as well as start and end positions are added for
go/types errors. This information is temporarily stored in unexported
fields, until we're more confident in the correctness of both the API
and the underlying data.
Read this information using reflection and, if available, use it to set
the corresponding field in compiler diagnostics. This establishes a
positive feedback loop: in most cases this should improve the gopls
diagnostic, and wherever it doesn't we can make a note and fall back on
the old heuristics for that error code.
For golang/go#42290
Change-Id: I37475189cbd14a0a5bcfde163f599c9a7b957372
Reviewed-on: https://go-review.googlesource.com/c/tools/+/268539
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Trust: Robert Findley <rfindley@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Links to godoc.org pages are changed to link to pkg.go.dev.
CL 253017 and CL 234678 are also backported.
For golang/go#36106
Change-Id: I6a875f5b43e456f11d8eeccfc5ef647a5501c4d3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275235
Trust: Julie Qiu <julie@golang.org>
Run-TryBot: Julie Qiu <julie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Executing the "go test" command did pass Package.PkgPath() as first
argument to the go invokation before. That failed when using test
packages with _test suffix.
The "go test" command now use Package.ForTest() instead.
Fixesgolang/go#43037
Change-Id: Iea1a0e0c949a53770c1d3e1126a16a9c4952a53f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275496
Trust: Pontus Leitzler <leitzler@gmail.com>
Run-TryBot: Pontus Leitzler <leitzler@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Two changes are made to speed up the regtests (from 150s->100s on my
desktop):
+ Eliminate WithoutExperiments in favor of just Singleton mode, now
that we're not running other tests in Forwarded mode by default.
+ Reduce the diagnostics delay to 10s, which should still be enough to
exercise bugs related to debouncing but is not so much that it slows
down the tests significantly.
Change-Id: Ia12c8417aee7bb50baccce27e1e1752315900b76
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275450
Run-TryBot: 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>
Trust: Robert Findley <rfindley@google.com>
There was a race to the background context that allowed work for earlier
snapshots to run on the background context of later snapshots. For
example, the following sequence is possible and has been observed in
tests (admittedly at unrealistic time scales):
- snapshot N is created
- view.cancelBackground() is called
- snapshot N+1 is created
- snapshot N+1 is diagnosed
- snapshot N is diagnosed
- snapshot N is destroyed
Fix this by pinning the background context to the snapshot. This also
makes more sense; I'm guessing the background context being on view is a
vestige of when more work was done on the view.
For golang/go#42837
Change-Id: If9cbad7361de823da9bfd2f55cb2f8b3aed95075
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275239
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>
These options were added in CL 274532, but it's not possible for users
to actually set them.
Change-Id: I85642ada017f225d4d77e4dfc97fe13847f4091a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275442
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>
As part of the earlier changes, I didn't realize that multiple //-style
comments would be grouped as one *ast.Comment, even though they are
multiple comment tokens. Handle the possibility of multiple consecutive
comment tokens.
Fixesgolang/go#42923
Change-Id: I6bc6cbdfb28a8e60c699288528566e406f27514c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275012
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've been aiming to enable diagnostic debouncing by default, and now
that CL 269197 is merged, I think it's time to do that.
I know that the experimental setting had it at 200ms, but the 250ms was
specified in golang/go#42693, so I'm not sure which is preferable.
Also, fix a bug I introduced in CL 269197, which set alwaysAnalyze to
true for diagnoseChangedFiles. This should only be used for testing.
Add a requirement for 1.13 to one test that relies on good overlay
support (loading the file directly produced a different response from
the full workspace load).
Fixesgolang/go#42693
Change-Id: I49b764a8d473a66a01ef0f2c6f4cbe2d512fd64e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274445
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>
difftest using output of GNU diff, which will be translated based on
LANG settings.
Fixesgolang/go#42962
Change-Id: Id4ae22da04077eb7cda7faace306fdbe1836ec60
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274992
Trust: Meng Zhuo <mzh@golangcn.org>
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
We adjust the value of GO111MODULE to "auto" when running the go
command, since it handles more edge cases. However, in some cases, we
may want to know the environment's actual value of GO111MODULE, so
separate out these two concepts.
Also, as of Go 1.13, `go env` reports GO111MODULE, so add it to the
environmentVariables, but only for Go versions >= 1.13.
Removed a regression test that doesn't seem very important--looks like
even `go env` will fail with GO111MODULE=on and a malformed GOPATH.
I don't think that it's important that `gopls` continue working in such
a case, since the go command will also fail.
Change-Id: I8147782222261a190d0f1017fe9f6043f2ac0cdb
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275013
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>
The LSP server tracks the snapshot ID for which diagnostics were last
published, but this ID was not being updated if the publish was
suppressed when there are no changes, which can cause incorrect
diagnostics when snapshots are published out-of-order (a separate bug).
Fix this to update the snapshot ID when the current published
diagnostics match the latest computed diagnostics.
Fixesgolang/go#42837
Change-Id: I3634e6f351a479aefa5c9423956720431590d814
Reviewed-on: https://go-review.googlesource.com/c/tools/+/275238
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>
This check doesn't need to be super precise about the snapshot it uses,
and it's only needed in the case of a didChange. We can refactor this
code to simplify it a bit.
Change-Id: I360be78bed236cb188b32b17cc7515bc4a3e42ba
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274451
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>
Add support for providing a suggested fix when the struct have field
lines with multiple names, such as:
type s struct {
b bool
i1, i2 int
a3 [3]bool
_ [0]func()
}
This was a leftover from CL 270217.
Change-Id: Icccec5b8b4b82823cee33b7a84d0cccab38b6f45
Reviewed-on: https://go-review.googlesource.com/c/tools/+/273346
Reviewed-by: Michael Matloob <matloob@golang.org>
Trust: Pontus Leitzler <leitzler@gmail.com>
Combine the generation of the API json with the generation of the
documentation. This cuts out a step from the generation process, and
allows us to depend on third-party modules. Use litter to print a
composite literal instead of JSON text, which will diff and merge much
better.
The only real drawback is that you have to "go run" from the gopls
module to avoid adding the extra deps to tools.
Sorry about the copy and paste; there's relatively little actual code
change, just a bit in doMain and rewriteAPI.
Change-Id: Iac936d31b7e52651b3b33f27497cfdbd133f1e76
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274373
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>
The changes to require more explicit dependency management and network
access are very user-facing, and we may not fully understand their
implications. Allow users to roll them back with options for the moment.
Ideally we'll be able to remove them in a few months after things
stabilize.
Change-Id: I5a5ff7c9f3afa490b9945604109c4e3bd9bd7844
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274532
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>
Reviewed-by: Robert Findley <rfindley@google.com>
With -mod=readonly set, we no longer automatically add new requires to
go.mod, even the temporary one. We have the go mod tidy code lens, but
that only works on saved files, even in 1.16 due to golang/go#42491.
Plus we may remove the code lens's network access in the future.
Add a simple quick fix for import errors that runs (the moral equivalent
of) go get on the missing import.
Change-Id: Id5764a37ce7db0dce5370da9d648462aefa2042b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274121
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>
Reviewed-by: Robert Findley <rfindley@google.com>
For users with poor network connections, go command invocations that
access the network may hang up for long periods of time. Even for
users with good network connections, accessing proxy.golang.org or
github can take a few seconds, which is a long time to lock up an
editor.
Disable network access via GOPROXY=off when running most go commands.
There are two notable exceptions. First, the initial workspace load is
allowed, though subsequent loads are not. My reasoning is that if the
user is opening a project they've just downloaded, they probably expect
to fetch its dependencies. (Also, it's convenient to keep the regtests
going.) The second is the go mod tidy diagnostics, which I hope to
address in a later change. All the other commands that access the
network are at the user's request.
When the workspace load fails due to a dependency that hasn't been
downloaded, we present a quick fix on the go.mod line to do so. The only
way that happens is if there's a manual modification to the go.mod file,
since all of the other quick fixes will do the download. So I don't
think there's a need to present the fix anywhere else.
Updates golang/go#38462.
Change-Id: I470bc1ba790db7c1afee54d0b28fa0c6fd203fb9
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274120
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>
Reviewed-by: Robert Findley <rfindley@google.com>
Go 1.16 will set -mod=readonly to be the default behavior of the go
command. This CL changes gopls' behavior to be more in line with that.
The model we end up with is more explicit about managing the go.mod.
Previously, adding an import for a package in the module cache but not
in scope would succeed, but add a warning with a quick fix. Now, the
import will fail, again with a quick fix, and the project will not
compile until the require is added. It also means that the go.sum needs
to be in sync. Previously, the go command would update the temporary
go.sum if the user's was out of date, and then we would discard those
changes. Now, loads will fail until the go.sum is brought into sync,
either by `go mod tidy` or the new "update go.sum" command.
The go.sum requirements affect many regtests. I added a DumpGoSum
function to the environment, which prints the txtar format go.sum file
that needs to be added to the workspace. We'll need to keep them in
sync, unfortunately. We could update them on the fly, but that would
slow down the regression tests somewhat and potentially mess up the test
setup. So I'm not sure what to do exactly. Perhaps maintain them
out-of-line in a separate file that could be auto-updated? Dunno.
I also had to add go directives to go.mod files to keep old Go versions
happy.
Multi-module workspace mode currently doesn't create a go.sum file at
all and is held back to the old behavior until it does.
Change-Id: Ib31afc17614afac2f5fbdf31c7fc03a90bd13e3a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/268597
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>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
I've recently started working on gopls. It's been a fantastic
experience, but the testing strategies here have required non-trivial
mental work to understand. (thanks Rebecca for all your help!)
Now that I understand the testing a bit better, I wanted to codify it
into a readme for the next person that comes along.
I've taken a stab at that: please feel free to suggest heavy edits,
it's just a best-effort attempt.
Change-Id: Ib739d40ef71018521cd904844443e8c9634a10a6
Reviewed-on: https://go-review.googlesource.com/c/tools/+/273066
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Jean de Klerk <deklerk@google.com>
Previously, we would always reload views with invalid build
configurations on every call to reloadWorkspace, even if the metadata
had no reason to be treated as invalid.
Fixesgolang/go#42813
Change-Id: I9e0e493228916262908b81bc1b1ab1eb4e4eca9e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274443
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>
golang.org/cl/258957 dropped 387 support, and golang.org/cl/260017
implements GO386=softfloat, so use it instead.
While at it, also cleanup things related to nacl.
Change-Id: I7bd58c5653dd61635b373f1b219f52bfc53e55e4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274752
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Instead of skipping the test, insist on 1.16 or later.
See golang/go#41061
Change-Id: Ie13f114039693993d65333ab9194629187a9b6b1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/274533
Run-TryBot: Peter Weinberger <pjw@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Peter Weinberger <pjw@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
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>
Keith Randall
Rebecca Stambler
Heschi Kreinick
Muir Manders
Robert Findley
Julie Qiu
Pontus Leitzler
Meng Zhuo
Jean de Klerk
Simon Frei
Cuong Manh Le
Peter Weinbergr
Himanshu
