Collapse Diagnostic.Kind, Source, and Category into just Source. Remove
code that converted from Diagnostic to Diagnostic. Notes on the changes
I had to make along the way:
- We used to use Kind to determine Severity. Set Severity when the
Diagnostic is created instead.
- Use constants for Source as much as possible -- we still need to use
Analyzer.Name for analysis diagnostics. It would be nice to break that
dependency so that Source was totally opaque, but that's a separate
issue.
- Introduce a new Source for gc_details, "optimizer details". It was "go
compiler" previously.
- Some of the assignments are a little arbitrary. Is inconsistent
vendoring really a "go list" error?
- GetTypeCheckDiagnostics had code to cope with diagnostics that had no
URI associated with them. We now spread such diagnostics to all files
when they are generated.
- Analyze modifies Diagnostics by adding a Tag to them. That means it
has to own them, so I had it clone them. I would like to push that logic
down to the diagnostics, per the TODO, but that's another CL.
And some observations:
- It's obviously tempting to combine DiagnosticSource and
diagnosticSource, but they mean very different things. I'm open to a
better name for one or the other.
Change-Id: If2e861d6fe16bfd2e5ba216cf7e29cf338d0fd25
Reviewed-on: https://go-review.googlesource.com/c/tools/+/288215
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>
source.Error and source.Diagnostic are almost identical types, used
arbitrarily in different parts of the code. This CL is the first step in
cleaning up that redundancy: it deletes the source.Error type.
To do that, I added the fields from source.Error to source.Diagnostic,
and made absolutely no other semantic code changes -- I just renamed
things that were named Error to Diagnostic. With only aesthetic concerns
in play, I hope this CL will be easy to review. The next CL will clean
up all the stupid-looking code that converts a Diagnostic to a
Diagnostic, etc.
Change-Id: I1298cc8144c686b8a37fc2cc106930105e511353
Reviewed-on: https://go-review.googlesource.com/c/tools/+/288214
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>
code.ts and util.ts for the latest version of the LSP protocol.
Change-Id: I911254ee7e66d91071e465ed83c456975e358ca4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/288732
Trust: Peter Weinberger <pjw@google.com>
Trust: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
The Typescript source is still at version 3.16, but there are new
requests, more detailed client capabilities, and an attempt to be
more specific about ranges of number in the Typescript code.
Vscode defines types integer and uinteger (32-bit signed and unsigned),
so the Go code now uses int32 and uint32.
They've changed the use of TextDocument, so version information is sometimes
missing. cache/session.go:625 was changed correspondingly.
This CL also make CodeAction.Disabled into a pointer.
New requests or notifications:
DidCreateFiles, DidRenameFiles, DidDeleteFiles (notifications)
ShowDocument, WillCreateFiles,WillRenameFiles, WillDeleteFiles (request)
It's a lot of code; I've probably missed something.
Change-Id: I8449ad8473ac00947d0344c5f6133f9bd73b9e10
Reviewed-on: https://go-review.googlesource.com/c/tools/+/286192
Run-TryBot: Peter Weinberger <pjw@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Peter Weinberger <pjw@google.com>
Using structured errors in gopls has proven to be difficult to manage:
it's hard to know whether a given error return is expected to be
structured without any type information. We have mostly eliminated
them; finish the job.
I don't intend any semantic changes here.
I considered eliminating CriticalError altogether, but it does seem
useful to have a convenient bundle for return values. So I left it
alone for now.
Change-Id: I4b5f85a8de9712babffbc1383088151b596bd815
Reviewed-on: https://go-review.googlesource.com/c/tools/+/287792
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>
Now that workspace module mode generates a combined go.sum there are
relatively few blockers to enabling -mod=readonly. Fix them and do it.
This CL is a bit of a grab bag, but the fixes are relatively separate. I
can split it into multiple CLs if desired.
- If module A depends on module B at v1.0.0, the go command will want to
upgrade the workspace module from v0.0.0-goplsworkspace to v1.0.0. To
prevent that, use vN.999999.0 as the base pseudoversion, adjusting v0 to
v1 where appropriate. A few test cases needed updating as a result.
- For old Go versions, sort the generated workspace module and
synthesize a go statement from the maximum go version declared in the
workspace.
- Some regtests need go.sum files created.
- matchErrorToModule created incorrect quick fixes: it would try to
download the top-level module mentioned in the error message, not the
one that actually caused the problem. Now it issues quick fixes for the
lowest-level module.
- TestMultiModuleModDiagnostics accidentally included the same module
in the workspace twice. Fix it, and make that an error.
Fixesgolang/go#43346.
Change-Id: I605f762a4d23bedd914241525e64c1b3ecc42150
Reviewed-on: https://go-review.googlesource.com/c/tools/+/287032
Trust: Heschi Kreinick <heschi@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
In CL 271297, I disabled the constantly-running upgrade check, which
removed the upgrade commands for individual dependencies. This seems to
have been a relatively popular feature. Re-introduce it, but requiring
explicit user interaction.
We now run an upgrade check when the user clicks "Check for upgrades".
Those results are stored on the View and used to show diagnostics on
any requires they apply to. Right now we only check the go.mod the user
has open; in multi-module workspaces it might make sense to check all of
them, but I'm not sure.
Fixesgolang/go#42969.
Change-Id: I65205dc99a4fa9daafdb83145b0294b6f3be5336
Reviewed-on: https://go-review.googlesource.com/c/tools/+/286474
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>
Rather than coming up with an ad-hoc error message, use the friendly
errors from the gocommand package. I noticed this because the latter
is missing the verb.
I *think* this is generally an improvement; instead of seeing a massive
command line, users just see the actual error from the go command. Even
if it's not, I'd rather improve the single source of the error than play
whack-a-mole.
Change-Id: Ib110eaac6c3984e617339cf14cffe3b59f33591b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/287033
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>
We were always sending an empty reason for "disabled" in code actions,
which leads clients to see all code actions as disabled.
Change-Id: I855fb622a52557cc56ce91cf90fdc971df099a90
Reviewed-on: https://go-review.googlesource.com/c/tools/+/287796
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>
TryBot-Result: Go Bot <gobot@golang.org>
Regtests have gotten large, and started timing out on some slow
builders. They also can't yet be run in parallel, due to some
process-level shared state (e.g. gc_details). Furthermore, there seems
to be some per-process resource leak that we don't yet fully understand
causing slowdown as the tests progress.
Address these problems by splitting the regtests up into multiple
packages. This also makes it easier to run only relevant tests during
development.
For golang/go#42789
For golang/go#39384
Change-Id: I1a74e4c379f3a650f4c434db44f9368e527aa459
Reviewed-on: https://go-review.googlesource.com/c/tools/+/287572
Trust: Robert Findley <rfindley@google.com>
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>
We were not locking while iterating s.files in snapshot.knownFilesInDir.
All other accesses of s.files appear to be locked, so this should fix
golang/go#43972.
Fixesgolang/go#43972
Change-Id: I01184c3992c91f8beb4a3239f70cc4487a528ec0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/287573
Trust: Robert Findley <rfindley@google.com>
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>
Field embedding links two objects (a TypeName and a Var) by name,
requiring special handling during renaming. In CL 282932, renaming of
types was made to propagate to uses of their embeddings. However, no
such propagation in the reverse direction was added, meaning that
renaming an embedded field would not rename the corresponding type, and
code could still be left in a non-compiling state.
It should be an invariant that renaming does not change program
behavior. To enforce with field embeddings this we'd need to also rename
the corresponding type, but this seems problematic. If I'm hovering over
the field selector x.T, and rename T, it is surprising that this would
end up renaming a type.
For lack of a better solution, make it an error to rename embedded
fields, but try to provide a helpful error message.
Also handle the blank identifier, for which renaming was giving a
message to "please file a bug".
Marker tests are added for the new errors in rename, but not for
prepareRename. The prepareRename tests were not set up for asserting on
errors -- perhaps that would be a good project for a later CL where we
clean up errors.
Fixesgolang/go#43616
Change-Id: I66c2dd5e531dd102431d1edd443d553687d9ca7e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/284312
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>
Now that we're only including licenses for the things gopls actually
depends on, we don't need to access the network on the trybots, and we
can get rid of the go.sum check that adds a step to the release process.
Change-Id: I3d38334ea3a9c904dfa125157c7b0468a0699b54
Reviewed-on: https://go-review.googlesource.com/c/tools/+/286436
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
CL 278872 fixed the fact that field comments messed up the suggested
edits by removing comments entirely.
This change also remove documentation style comments since they also
produce broken suggestions in the same way.
Change-Id: I18d9c42fbf1453dcd5019b2a4aa3f4be4a58f7c7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/284732
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Pontus Leitzler <leitzler@gmail.com>
Run-TryBot: 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>
Using awaiting a certain number of work items in the regtest is a source
of flakes and latent bugs. This CL replaces all such assertions with
assertions based on the number of notifications sent by the fake.Editor.
While implementing this, I discovered several tests that had incorrect
counting, so this may fix some flakes.
Implementing this required pushing the asynchronous processing of file
events into the Editor, rather than the Workdir.
Change-Id: I9c3639409f2beed4a76295cbd53180c6e2ace126
Reviewed-on: https://go-review.googlesource.com/c/tools/+/285612
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>
The change displays outstanding diagnostics on the Client page of
the debug server.
Very occasionally gopls displays incorrect diagnostics or diagnositics
that won't go away. It is possible that providing more complete
information will help us find the causes, at least when the debug
server is running.
Change-Id: I01f2bbbfeac86e7296f57f4a9aad8e1e658babfa
Reviewed-on: https://go-review.googlesource.com/c/tools/+/285252
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: Robert Findley <rfindley@google.com>
The README still felt a little long and contained information that I
don't expect most users need. I pulled some of it out into an "advanced
users" document. Let me know if you think another word might be better--
the word advanced has lost all meaning to me.
I also rearranged some of the heading levels--does this make more sense
or is the old way better?
Change-Id: I34bcbe91ec52107cf2875c33f224837b3c7fb0d3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/285514
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 discussed, mention workspaces.md in the README. I figured build
systems like Bazel might be also worth mentioning, though IDK if that
fits well under configuration...
Change-Id: I8dd3c88d2e6f1096468eb08351676a99b91023f7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/285512
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>
As part of investigating golang/go#43023, I noticed that it's possible
for us to show context cancellation as a critical error--we should not
do this.
Change-Id: I1f7cc13a151e0a161d5a4ea4d5b55fba15270b32
Reviewed-on: https://go-review.googlesource.com/c/tools/+/284937
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>
These two pages were serving largely the same function, so it makes more
sense to merge them. Mostly deleted all of the information about
configuration--its really verbose and not likely to be helpful to users.
Change-Id: Id5eb6cd2acc19cc2d863943cb399cfefb6bdcee8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/283644
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>
Remove the exception for the Android amd64 builder, now that flakes are
fixed (though the exception didn't actually work anyway due to
golang/go#39460).
Also, accept the import reorganization applied by gopls.
Fixesgolang/go#43554
Change-Id: I9a7cce35998cfa673699d74a487111e4daecf7ec
Reviewed-on: https://go-review.googlesource.com/c/tools/+/284935
Trust: Robert Findley <rfindley@google.com>
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>
This change ensures that packages using exec.LookPath or
exec.Command to find or run binaries do not accidentally run
programs from the current directory when they mean to run programs
from the system PATH instead.
Change-Id: I5907aa630ff64012395a7eb472967a477d90f12e
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/949438
Reviewed-by: Katie Hockman <katiehockman@google.com>
Reviewed-by: Russ Cox <rsc@google.com>
Reviewed-on: https://go-review.googlesource.com/c/tools/+/284773
Run-TryBot: Roland Shoemaker <roland@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Rewrite the troubleshooting doc to be (hopefully) more helpful. I tried
to start from the assumption that the user had made a mistake rather
than that there was a bug in gopls. In particular, they're now
instructed to check for mistakes before updating gopls, and to try
Gophers Slack before filing a bug.
In general, I tried to adopt a more conversational voice as the gopls
authors, which I hope will make it more readable.
Once this looks good I'll do the VS Code version.
Change-Id: Ie36ad47af9e96b734475f8abe157ab3ad9c8cf09
Reviewed-on: https://go-review.googlesource.com/c/tools/+/283934
Trust: Heschi Kreinick <heschi@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This is a first CL to clean up the gopls documentation. The main changes
are cosmetic (to correct warnings found by the MD Lint VS Code
extension), though some parts are reworded or moved around. Ultimately,
more work needs to be done, particularly on the user guide and features
overview.
My current thinking is that we should rename settings.md to
configuration and move the configuration piece out of the user guide,
and also reorganize the user guide to be more "getting started"
oriented.
I'm still not sure where miscellaneous items should go (e.g., working on
the Go distribution itself)--I deleted the FAQ because it seemed useless
and is probably not the most discoverable, but it's the only place that
comes to mind so far.
Change-Id: I3689362067672f7ad8d5e8fd97ca9c7c45cfc8c4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/280595
Trust: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This change adds a workspace.md file that explains the different ways
of configuring your workspace with gopls. Ultimately, I think we should
move this to the user.md documentation, but I didn't want to deal with
merge conflicts from my other CL, so moving it here to start.
Fixesgolang/go#36899
Change-Id: I9217dc85a10cc6d0cbb4471509a186405d2e2088
Reviewed-on: https://go-review.googlesource.com/c/tools/+/283513
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>
Jumping to definition in a regtest can indirectly lead to a didOpen
call, so the awaits added to TestUseGoplsMod to synchronize metadata
were ineffectual. On Android, this can lead to the race described in
golang/go#43652.
But in any case, all this bookkeeping of notifications is fragile. Avoid
it entirely by having the fake editor keep track of notification
statistics. In the future, we should use this to clean up many existing
regtests.
For golang/go#43554
For golang/go#39384
Change-Id: Icd1619bd5cdd2f646d1a0050f5beaf2ab1c27f37
Reviewed-on: https://go-review.googlesource.com/c/tools/+/283512
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Trust: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Update the vscode settings example based on the new settings organization.
Change-Id: I6a52cc525a038caa4f35716f6a8c2be145b5238e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/283394
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Investigating flakes in TestGoModInvalidatesOnSave highlighted a couple
bugs:
+ A didOpen on a go.mod file invalidates the workspace, since it is
treated as a saved change. This, in itself, is probably not such a
big deal, except that...
+ When metadata is deleted on this didOpen, we break the workspace
before it can be recomputed.
Fix this by awaiting diagnostics from the didOpen, but it would be
better to have a more robust fix (e.g. CL 271477).
For golang/go#43554
Change-Id: I75d49b818ae2f3730a48ac6a473c24c664227523
Reviewed-on: https://go-review.googlesource.com/c/tools/+/283352
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>
Our filesystem caching layer uses file modification time to invalidate
file contents. This is an imperfect heuristic, and on certain operating
systems with low resolution filesystem clocks (such as WSL), this can be
broken in practice.
A proper fix would be to just read the file contents directly and rely
on the snapshot to optimize file access, but we don't know that this is
a safe change. Instead, try to reduce the likelihood of false cache hits
by also checking the file size reported by Stat.
For golang/go#43554
Change-Id: I1af384db532725e84fa6f3a2e5469d10b43fee92
Reviewed-on: https://go-review.googlesource.com/c/tools/+/283053
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>
On builders with low resolution clocks (e.g. WSL), it's possible for us
to miss file events that occur within a single 'tick'.
Fix this by instead tracking full file identity. Since we should have
only a few relatively small files in tests, the additional overhead
should be small.
For golang/go#43554
Change-Id: I05a48567f83007ff2278145638547c6ebb2523fd
Reviewed-on: https://go-review.googlesource.com/c/tools/+/283052
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>
When renaming a type name, also rename indirect uses of the name as an
embedded field. This is conservatively isolated to just renames for now;
it's not clear to me that users would also want to see uses of embedded
fields as references.
Fixesgolang/go#43616
Change-Id: I41913d037fedb8c27a448cd922eeaf11a02d01f1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/282932
Run-TryBot: Robert Findley <rfindley@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
If the user of go/packages passes an overlay package that results in a
package having Go files in multiple directories, return an error instead
of crashing.
This is more of a bandaid than a fix for anything, but go/packages is
hard to follow even with full data. Without it I don't really have a
clue, so this is the best I've got.
Fixesgolang/go#43520, I guess.
Change-Id: I37537ae2e0126f715719273ed9a6708ed53b850f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/282732
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>
Now that gopls is passing GOPROXY=off, running go list -m gives an error
if any modules aren't downloaded. We need to pass -e to get results for
the modules that we do have. Also add the missing error handling that
resulted in silent failure. That, in turn, reveals that we need to
explicitly ignore an expected error.
Fixesgolang/go#43333.
Change-Id: I77604650b67a3c480d8231c65f0486f22e4a6722
Reviewed-on: https://go-review.googlesource.com/c/tools/+/283172
Trust: Heschi Kreinick <heschi@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Adapted the script that I used to automatically add copyright notices
into a test that all files in the repository currently have appropriate
copyrights. Caught a few typos and extra spaces, which I decided to fix
rather than adjust regular expression.
Change-Id: Ifdbad969eca482e25c89afc5a2ddd5968c6661a6
Reviewed-on: https://go-review.googlesource.com/c/tools/+/282592
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>
Now that joaotavora/eglot#367 is fixed, I think we should recommend it
as a serious alternative to LSP mode. This change describes both
packages, summarizes their different philosophies, and simplifies the
example LSP Mode configuration to avoid relying on another unnecessary
third-party package.
Users who need more detail on alternative configurations should
consult the LSP client vendors' pages — we don't need to recapitulate
all of that detail here.
Change-Id: If125fbde6d609e223ce44936504cc4b08b84dc3d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/278774
Reviewed-by: Muir Manders <muir@mnd.rs>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Add a "licenses" command that shows the licenses of included software.
As special cases, we print the Go license first, and the LSP
specification license second since we bundle a Go version of it.
Change-Id: I3575073766a458c214108643b2b550c407a118dd
Reviewed-on: https://go-review.googlesource.com/c/tools/+/282112
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>
We're adding a command that shows the licenses of all the code we depend
on. Start by creating a (very kludgy) shell script to gather them into a
string constant. Hopefully something nicer will come along later, but
for now this works fine with our current dependencies.
There's no strong reason this needs to be in the gopls module but it
felt right and it needed to live somewhere.
Trybots don't have network access, so testing that the file is in sync
is a little tricky. For simplicity's sake, we bake the gopls go.sum into
the generated file, and if that goes out of sync we assume the licenses
need updating. That's an overapproximation, since a dependency update
doesn't necessarily mean a license change, but it's easy and we don't
update deps often.
Change-Id: I338834044078f7df25304fa50864716057ce308e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/281858
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: Russ Cox <rsc@golang.org>
Rather than downloading the module and hoping the imports cache will
be refreshed in time, start with the module downloaded and remove it.
Change-Id: I1b8e7b150d66b018d12db070d0f813a827e14cc7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/282374
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>
"Cmd" not "The cmd command".
While we're here, add pronounciation
and link directly to the docs (README.md)
instead of a commit directory listing.
Change-Id: I1ea8d9bfa371a4d8422dfd0586de40fdba26999b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/282652
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
We can't assume that we're in module mode when we rebuild the imports
cache. (This is a long standing bug, but I suspect it was made more
common by my recent CL that refactored this code.)
Fixesgolang/go#43544.
Change-Id: Ie35c43e6b6e496bd2fbf49cf9bf06c28cf1dab80
Reviewed-on: https://go-review.googlesource.com/c/tools/+/282113
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The existing test didn't catch it because it doesn't look for specific
warning messages.
Change-Id: I1ec7f7a75c1055c960cdd7545331c2fd655e3aa8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/281860
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Trust: Rebecca Stambler <rstambler@golang.org>
Use provided build flags may include -mod or -modfile, and these should
be removed before any go command calls that don't accept them.
Fixesgolang/go#43418
Change-Id: Ie96626bced5093c67fc1890533f1f8cc03d42c80
Reviewed-on: https://go-review.googlesource.com/c/tools/+/280694
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: Michael Matloob <matloob@golang.org>
Heschi Kreinick
pjw
Rebecca Stambler
Rob Findley
Ajanthan Balachandran
Pontus Leitzler
Roland Shoemaker
Hyang-Ah Hana Kim
Bryan C. Mills
Russ Cox
Ian Lance Taylor