This change changes the linksInHover option from bool to
a sum of false | true | "gopls".
The "gopls" setting causes Hover(SynopsisDocumentation)
to generate links to gopls' internal web-based doc viewer.
Thanks to Hana for the idea.
+ Test, release note
Fixesgolang/go#67949
Change-Id: I384796780436b191a0711c60085d67363d00e5f6
Reviewed-on: https://go-review.googlesource.com/c/tools/+/572037
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
This change simplifies the SetOptions machinery by
eliminating the (public) OptionsResult and Options
types and their methods, and using simpler standalone
functions of these forms:
setT(dest *T, value any) error
asT(value any) (T, error)
The code is clearer and significantly shorter.
Details:
- rename SetOptions to Options.Set.
- return only the errors, not the OptionsResults;
server.handleOptionResult renamed handleOptionErrors.
- remove error result from server.handleOptionResult,
per preexisting TODO.
- add missing doc comments.
- use JSON terminology in error messages.
Note, minor behavior changes:
- the buildFlags and directoryFilters flags now use
asStringSlice (per the preexisting TODO), and also
templateExtensions, but this replaces Sprint(x)
with asString(x), which is strictly speaking an
incompatible change.
Change-Id: Ib2169ba8e1db1a34e9bc269e6e8cef3a6763e6e6
Reviewed-on: https://go-review.googlesource.com/c/tools/+/592536
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
As reported in golang/go#67889, a short unresolved identifier can cause
goimports fixes to be quite slow, because the substring match heuristic
used to filter import paths matches a large fraction of the module
cache.
Fix this by improving the precision of the matching heuristic used to
filter potential packages. We now match only full segments of the import
path (ignoring '.' and '-'), or subsegments delimited by '.' and '-'.
Add a gopls benchmark that reproduces this initial slowness, along with
a command to force a scan of the module cache. On my (overpowered) linux
development machine, with a 5GB module cache, this change reduces the
benchmark time ~90%, from 2s to 200ms. With a smaller machine, slower
operating system, or larger module cache, I imagine the starting
point could be significantly more than 2s.
Fixesgolang/go#67889
Change-Id: Id8f7ea20040b059b42366333adeb4add684dee61
Reviewed-on: https://go-review.googlesource.com/c/tools/+/591715
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
As described in golang/go#67865, CL 590377 exacerbated a problem that
module cache refreshes may outlive the lifecycle of the view.
Fixesgolang/go#67865
Change-Id: Ieafdf6601fee00b6e8ce705502a80224da071578
Reviewed-on: https://go-review.googlesource.com/c/tools/+/591315
Auto-Submit: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
An apparent bad merge in CL 561235 caused the critical component--
clearing the resolver for a new scan--to be dropped. Fix this, so that
the imports state is actually refreshed asynchronously.
It is surprising that this was not reported, though I see perhaps two
related comments in survey results. Most likely adding a new import is
infrequent enough that users were simply confused, or learned to restart
gopls (alas).
Also, add more instrumentation that would help debug golang/go#67289.
For golang/go#67289
Change-Id: I50d70a470eb393caf9e0b41856997942372b216f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/590377
Auto-Submit: Robert Findley <rfindley@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The go command treats imports of packages whose path contains
"/internal/" specially, and gopls must simulate it in several
places. However, other build systems such as Bazel have their
own mechanisms for representing visibility.
This CL suppresses the check for packages obtained from a
build system other than go list. (We derive this information
from the view type, which in turn simulates the go/packages
driver protocol switch using $GOPACKAGESDRIVER, etc.)
Added test using Rob's new pass-through gopackagesdriver.
Fixesgolang/go#66856
Change-Id: I6e0671caeabe2146d397eb56d5cd4f7a40384370
Reviewed-on: https://go-review.googlesource.com/c/tools/+/587931
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
When a file->package association changes, it may fix broken imports.
Fix this invalidation in Snapshot.clone.
Fixesgolang/go#66384
Change-Id: If0f491548043a30bb6302bf207733f6f458f2574
Reviewed-on: https://go-review.googlesource.com/c/tools/+/588764
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The bug report in golang/go#67144 likely means that we got a change
notification after the session was shut down (and thus s.viewMap was
nil).
Fix this by being more rigorous in guarding any function that resets
s.viewMap with a check for s.viewMap != nil. Also, refactor to remove
the confusing updateViewLocked and dropView functions, which obscure the
logic of their callers.
Fixesgolang/go#67144
Change-Id: Ic76ae56fa631f6a7b11709437ad74a2897d1e537
Reviewed-on: https://go-review.googlesource.com/c/tools/+/589456
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
The 'bestView' function was used in two places, where the meaning of
'best' differed. When re-evaluating view definitions in selectViewDefs,
we may want to create a new view if none of them matched build tags.
When operating on a file in viewOfLocked, we want to choose the most
relevant view out of the existing view definitions.
In golang/go#60776, we see that the latter concern was poorly handled by
the 'bestView' abstraction. Returning nil was not, in fact, best,
because it resulted in the file being associated with the default AdHoc
view, which doesn't know about modules.
Refactor so that viewOfLocked chooses the most relevant view, even if
none match build tags. This causes the orphaned file diagnostic to more
accurately report that the file is excluded due to build tags.
Fixesgolang/go#60776
Change-Id: I40f236b3b63468faa1dfe6ae6aeac590c952594f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/588941
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Also, audit the golang package for similar places where we
discriminate builtins, and make them all use the new isBuiltin
helper, which is based on lack of a position instead of messing
around with pkg==nil||pkg==types.Unsafe||...
"A symbol without a position" is a fair definition of a built-in.
Fixesgolang/go#66923
Change-Id: I7f94b8d0f865f8c079f1164fd61121eefbb40522
Reviewed-on: https://go-review.googlesource.com/c/tools/+/588937
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
Make the missing import error knowledgeable of the view type, so that it
can correctly reference modules, GOROOT, GOPATH, or go/packages driver
as applicable.
While at it, fix some duplicated and broken logic for determining if the
view is in go/packages driver mode, consolidate on representing the
driver accurately as GoEnv.EffectiveGOPACKAGESDRIVER.
Fixesgolang/go#64980
Change-Id: I7961aade981173098ab02cbe1862ac2eca2c394b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/589215
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Robert Findley <rfindley@google.com>
VS Code has a complex and undocumented logic for presenting
Code Actions of various kinds in the user interface.
This CL documents the empirically observed behavior at
CodeActionKind.
Previously, users found that "nearly always available"
code actions such as "Inline call to f" were a distracting
source of lightbulb icons in the UI. This change suppresses
non-diagnostic-associated Code Actions (such as "Inline call")
when the CodeAction request does not have TriggerKind=Invoked.
(Invoked means the CodeAction request was caused by opening
a menu, as opposed to mere cursor motion.)
Also, rename BundleQuickFixes et al using "lazy" instead
of "quick" as QuickFix has a different special meaning
and lazy fixes do not necesarily have kind "quickfix"
(though all currently do).
Fixesgolang/go#65167
Update golang/go#40438
Change-Id: I83563e1bb476e56a8404443d7e48b7c240bfa2e0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/587555
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
This CL splits codelenses.md out of settings.md, since
they aren't settings.
This reduces the indentation level of settings by one,
since we can dispense with a heading. Also, don't increase
the <h%d> nesting level for each level of nested dotted options:
ui.foo.bar should not be rendered smaller than ui.foo.
Use only h2 for groupings and h3 for settings.
Also:
- improve the introduction.
- add anchors for groupings.
- delete handwritten .md doc for obsolete newDiff setting.
- add TODOs for some existing bugs in the generator.
Change-Id: If6e7fff028b2c372e0d766d3d092bd0e41d61486
Reviewed-on: https://go-review.googlesource.com/c/tools/+/586879
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Historically, CodeLenses were identified in the UI (LSP, CLI, docs)
by the command.Command that they return, but this is confusing
and potentially ambiguous as a single lens algorithm may offer
many commands, potentially overlapping.
This change establishes a separate CodeLensKind identifier for
them. The actual string values must remain unchanged to avoid
breaking users.
The documentation generator now uses the doc comments attached
to these CodeLensKind enum declarations. I have updated and
elaborated the documentation for each one.
Change-Id: I4a331930ca6a22b85150615e87ee79a66434ebe3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/586175
Auto-Submit: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: I70517b1b17b4ee3243e85de2701195a2531d67e5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/586335
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
This change causes the parser of go list error messages to
fill in 1, not 0, for missing line/column information, as
those are the correct values for this particular representation
(1-based UTF-8).
Also, report a bug if we see non-positive arguments to LineCol8Position.
Plus, a regression test.
Fixesgolang/go#67360
Change-Id: I87635b99c8b13056c4816b58106ec4a29a9ceb9e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/585555
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
This change causes go commands executed by the snapshot
to set the -overlay=... flag to a file describing
the unsaved editor buffers of the snapshot. (Previously,
this was done only for the main metadata load via
packages.Load.)
We factor the WriteOverlays logic from go/packages/golist.go
into internal/gocommand and use it from Snapshot.goCommandInvocation.
The cleanup logic has been cleaned up.
The ToggleGCDetails feature was an example of a command
that had a needless "file save required" restriction even
though the underlying machinery (go build) is overlay-aware.
This change removes that restriction and adds a test that
the feature works on unsaved editor buffers.
Another one is Tidy, for which I have also removed the
restriction and added a test.
(This is what happens when you try to write down a list of
all gopls features for documentation purposes...)
Change-Id: I801e3a9c7c27f6b63efaaa1257fcca37e6fafa4c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/582937
Auto-Submit: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Analyzers are free to add new files to Pass.FileSet.
(This is documented, but perhaps not clearly enough,
so this CL clarifies the commentary.)
Previously, gopls' analysis driver assumed that the token.File
for a given Diagnostic must be one of the set of parsed Go files
fed to the Pass; the previous point refutes this assumption.
This change causes the driver to search for files by name,
not *token.File pointer, to allow for re-parsing.
The driver still calls bug.Report if the file is not found;
this still indicates a likely analyzer bug.
This should stem the prolific flow of telemetry field reports
from this cause.
Also, add a regression test that ensures that the cgocall analyzer,
which not only parses but type-checks files anew, actually
reports useful diagnostics when run from within gopls.
(Previously, it would trigger the bug.Report.)
Also, plumb the Snapshot's ReadFile and context down to
the Pass so that Pass.ReadFile can make consistent reads
from the snapshot instead of using os.ReadFile directly.
We also reject attempts by the analyzer to read files
other than the permitted ones.
Fixesgolang/go#66911Fixesgolang/go#64547
Change-Id: I5c35ad6cc5c15c99e9af48aaffb3df2aff621968
Reviewed-on: https://go-review.googlesource.com/c/tools/+/580836
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Address some long-standing TODOs to simplify the invocation of go
commands from the Snapshot. In the past, the combinations of
Snapshot.goCommandInvocation, cache.InvocationFlags, and
Snapshot.RunGoCommand* helpers created a remarkable amount of
indirection even in the case of simple Go command where the arguments
should be known--all on top of the already significant indirection of
the gocommand package. As a result, it was difficult to reason about
what exactly is being run.
This indirection attempted to abstract things like the go command
environment, and -mod flags, which in the past were more configurable
and depended on the ambient Go version. But we've since stopped
supporting much of this configuration, and the Go command has stabilized
its behavior. The abstraction is no longer carrying its weight.
Simplify as follows:
- Reduce the gopls APIs to (1) Snapshot.GoCommandInvocation, which
populates an invocation according to the Snapshot's environment, and
(2) View.GoCommandRunner(), which is used for running Go commands in a
shared control plane.
- Eliminate cache.InvocationFlags, which were a very leaky abstraction
around -mod, -modfile, and GOWORK behavior. Instead, pass -mod and
-modfile as needed at the callsites. In most contexts, it is clear
what the flags and environment should be, the one notable exception
being Snapshot.RunGoModUpdateCommands, which may accept multiple
verbs. This will be cleaned up in a subsequent CL.
- Add a cache.TempModDir helper, to replace the tempURI behavior of
the WriteTemporaryModFile flag. Now the caller can own the temp
directory, and snapshot.GoCommandInvocation just produces an
Invocation.
Change-Id: Ieb5a4dc6e79ce6e69a0f1e072843538f0162f744
Reviewed-on: https://go-review.googlesource.com/c/tools/+/579439
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The ReadFile function enables an analyzer to read the contents
of a file through the driver. The allows the driver to provide
the analyzer with a view of the file system that is consistent
with that seen by the parser and type checker, and enables
drivers to reject attempts to read arbitrary files, so that
their dependency analysis (if any) can be sound and precise.
+ a test
Fixesgolang/go#62292
Change-Id: I9f301cbfd4a705a259f9e213fc2e63d74424294a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/581555
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
The check in CL 576678 was comparing the release version, which is a
language version, with the contents of the go directive, which may be a
toolchain version. As a result, gopls detects go1.22 < go1.22.2, and
does not set types.Config.GoVersion. Normally this would be acceptable,
since go/types falls back on allowing all language features.
Unfortunately, gopls@v0.15.x lacks CL 567635, and so the loopclosure
analyzer reports a diagnostic in this case.
Fix by comparing language versions.
Fixesgolang/go#567635
Change-Id: I13747f19e48186105967b9c777de5ca34908545f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/579758
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Tim King <taking@google.com>
(cherry picked from commit 429c9f0c2c)
Reviewed-on: https://go-review.googlesource.com/c/tools/+/581807
Auto-Submit: Robert Findley <rfindley@google.com>
As part of the log audit in golang/go#66746, I noticed several
irregularities addressed by this CL:
- Move "tags" (domain-specific event keys, which are used construct
labels) closer to the packages that use them. Specifically, the
internal/event/tag package contained gopls-specific tags, but x/tools
should not care about gopls.
- Use consistent values for log attributes. For example, "method" was
being used to mean jsonrpc2 method and Go method. Also, "directory"
was being used as both file path and URI.
- Use log attributes for the view attributes logged when views are
created.
- Eliminate (yet another) redundant log during Load.
- Include the ViewID with snapshot.Labels, since snapshot IDs are only
meaningful relative to a View.
With these changes, my audit of logging is complete.
Fixesgolang/go#66746
Change-Id: Iaa60797a7412fb8e222e78e2e58eff2da9563bbb
Reviewed-on: https://go-review.googlesource.com/c/tools/+/579335
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
This is one of our most frequent and oldest open crash bugs.
Updates golang/go#60890
Change-Id: I97bdf339ec355aaf23fb81ee8fed11b142d28409
Reviewed-on: https://go-review.googlesource.com/c/tools/+/581175
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Change-Id: I5d5f6cc4a6984b8577e8178082bc60dfe08107b6
GitHub-Last-Rev: 16ede6bf75
GitHub-Pull-Request: golang/tools#490
Reviewed-on: https://go-review.googlesource.com/c/tools/+/580156
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
That no tests fail when this setting is removed is evidence enough that
it is unsupported. Additionally, this was one of the final pins holding
together some of the unnecessary complexity of the gocommand package,
which subsequent CLs will untangle.
Fixesgolang/go#65546
Change-Id: I8efececfd743d898c5f72c6a2d2a416e023ee3bc
Reviewed-on: https://go-review.googlesource.com/c/tools/+/579435
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Simplify some of the legacy indirection that used to be required when
the bulk of gopls' implementation lived in the x/tools module. We no
longer need to set hooks on the settings.Options; hooked-in
implementations can simply be statically linked.
Remove the settings.Hooks type, and pull the thread as far as it will
go, cleaning up a bunch of unnecessary indirection. As a result, we no
longer need the hooks package.
Change-Id: Ifd71da13174af4b7bc733f97774830ec1d98a2bc
Reviewed-on: https://go-review.googlesource.com/c/tools/+/578039
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
In CL 538796, options were made immutable on the View, meaning any
change to options required a new View. As a result, the
minorOptionsChange heuristic, which avoided recreating views on certain
options changes, was removed.
Unfortunately, in golang/go#66647, it appears that certain clients may
send frequent didChangeConfiguration notifications. Presumably the
configuration is unchanged, and yet gopls still reinitializes the view.
This may be a cause of significant performance regression for these
clients.
Fix this by making didChangeConfiguration a no op if nothing changed,
using reflect.DeepEqual to compare Options. Since Hooks are not
comparable due to the GofumptFormat func value, they are excluded from
comparison. A subsequent CL will remove hooks altogether.
For golang/go#66647
Change-Id: I280059953d6b128461bef1001da3034f89ba3226
Reviewed-on: https://go-review.googlesource.com/c/tools/+/578037
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Robert Findley <rfindley@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
The check command previously ignored Diagnostic.RelatedInformation,
which confused me as I was trying to run an experiment related
to golang/go#64547. This change causes it print the related errors.
+ test
(Aside: there's a lot of weirdness in the way that
check.typeErrorsToDiagnostics constructs the response,
as you will see if you run the test on c.go not c2.go,
but that's not the test's concern.)
Change-Id: I14efbf8f2e47ac00c2e7d6eceeacbaaecab88213
Reviewed-on: https://go-review.googlesource.com/c/tools/+/576656
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
We could do more, but this is a minimal change addressing
golang/go#61543.
Fixesgolang/go#61543
Change-Id: I1535ffcf9246d2d8abad384cab4a29c24696a220
Reviewed-on: https://go-review.googlesource.com/c/tools/+/578455
Auto-Submit: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
With gopls@v0.15.0, zero config gopls made it much more likely that
sessions would have multiple Views. Additionally, with improved build
tag support, it made it more likely that these Views would share files.
As a result, we encountered (and fixed) this latent bug:
1. User changes file x.go, invalidating view A and B. A and B are
scheduled for diagnosis.
2. User changes file y.go, invalidating only view B. Step (1) is
cancelled and view B is scheduled for diagnosis.
3. View A never gets rediagnosed.
The fix was naive: just mark view A and B as dirty, and schedule a
goroutine to diagnose all dirty views after each step. As before, step
(2) would cancel the context from step (1).
But there's a problem: diagnoses were happening on the *Snapshot*
context, not the operation context. Therefore, if the goroutines of step
(1) and (2) both find the same snapshots, the diagnostics of step (1)
would *not* be cancelled, and would be performed in addition to the
diagnostics of (2). In other words, following a sequence of
invalidations, we could theoretically be collecting diagnostics N times
rather than 1 time.
In practice, this is not so much of a problem for smaller repositories.
Most of the time, changes are arriving at the speed of keystrokes, and
diagnostics are being scheduled faster than we can type. However, on
slower machines, or when there is more overall work being scheduled, or
when changes arrive simultaneously (such as with a 'save all' command or
branch switch), it is quite possible in practice to cause gopls to do
more work than necessary, including redundant loads. I'm not sure if
this is what conspires to cause the regressions described in
golang/go#66647, but it certainly is a real regression.
Fix this by threading the correct context into diagnoseSnapshot.
Additionally, add earlier context cancellation in a few cases where
redundant work was being performed despite a context cancellation.
For golang/go#66647
Change-Id: I67da1c186848286ca7b6221330a655d23820fd5d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/577695
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Previously, gopls would log package contents whenever reloading (but not
reinitializing) a workspace--essentially whenever the query did not
contain a '...'. But following a big invalidation, gopls may reload
hundreds or even thousands of packages. Logging them is tremendously
verbose.
Change the behavior to simply log packages if and only if verboseOutput
is set. This is easier to understand and greatly reduces the noisiness
of loading.
Also annotate the one test that broke when I experimented with this
behavior. We should really have a more robust framework for asserting on
loads, but that is a project for another CL.
For golang/go#66746
Change-Id: I0eff7fad1b2deb2f170a1c336abf2c2a9e4f56ba
Reviewed-on: https://go-review.googlesource.com/c/tools/+/577875
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
- Fix a bug in the logic to suppress a context cancellation error
computing the shared import graph.
- Remove ErrIsDefinition. It was introduced for testing in CL 196560,
and is no longer needed.
- Update golang.SignatureHelp to return (nil, nil) in the case where
SignatureHelp is simply not available.
- Suppress the mod tidy diagnostic error when GOPROXY=off. It is too
noisy, and golang/go#56395 tracks the fix for the root cause.
- Suppress noisy errors about semantic tokens. Researching the history
behind this error, it seems it was only added to force the
invalidation of semantic tokens client-side. The same can be achieved
by returning a non-nil, empty result.
- Enforce that marker tests encounter no error logs, with an -errors_ok
flag to allow them in select cases.
- Update the -min_go version of some marker tests that use a go.mod file
with a too-new go version. This was an error log.
For golang/go#66746
Change-Id: I21fe274e320cf5fa7d6b85d7402330fb647dbd29
Reviewed-on: https://go-review.googlesource.com/c/tools/+/577655
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Also, use go1.19 generic helpers for atomics.
Updates golang/go#66732
Change-Id: I7aa447144353ff2ac5906ca746e2f98b115aa732
Reviewed-on: https://go-review.googlesource.com/c/tools/+/577435
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
If the primary diagnostic has invalid position information (due to a bug
in the parser or AST fix logic), gopls may panics when linking primary
and related information. Avoid this panic.
Fixesgolang/go#66731
Change-Id: Ie2f95d158a1c93d00603a7ce4d38d8097bd8cb08
Reviewed-on: https://go-review.googlesource.com/c/tools/+/577259
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
The type checker produces an error if the Go version is too new. When
compiled with Go 1.21, this error is silently dropped on the floor and
the type checked package is empty, due to golang/go##66525.
Guard against this very problematic failure mode by filtering out Go
versions that are too new. We should also produce a diagnostic, but that
is more complicated and covered by golang/go#61673.
Also: fix a bug where sandbox cleanup would fail due to being run with a
non-local toolchain.
Fixesgolang/go#66677
Change-Id: Ia66f17c195382c9c55cf0ef883e898553ce950e3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/576678
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Poor parser error recovery may cause Node.End to be zero, or
a small positive displacement from zero due to recursive Node.End
computation (#66683).
This change further refines the bug.Reports for such problems,
and additionally repairs the values heuristically to avoid
downstream bug.Reports after toGobDiagnostics (#64547).
Updates golang/go#66683
Updates golang/go#64547
Change-Id: I7c795622ec6b63574978d2953c82036fcc4425af
Reviewed-on: https://go-review.googlesource.com/c/tools/+/576655
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Fix the same crash as golang/go#66195, this time in Analyze: don't set
invalid Go versions on the types.Config.
The largest part of this change was writing a realistic test, since the
lack of a test for golang/go#66195 caused us to miss this additional
location. It was possible to create a test that worked, by using a flag
to select a go1.21 binary location.
For this test, it was required to move a couple additional integration
test preconditions into integration.Main (otherwise, the test would be
skipped due to the modified environment).
Fixesgolang/go#66636
Change-Id: I24385474d4a6ebf6b7e9ae8f20948564bad3f55e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/576135
Auto-Submit: Robert Findley <rfindley@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Filter diagnostics only to the "best" view for a file. This reduces the
likelihood that we show spurious import diagnostics due to module graph
pruning, as reported by golang/go#66425.
Absent a reproducer this is hard to test, yet the change makes intuitive
sense (arguably): it is confusing if diagnostics are inconsistent with
other operations like jump-to-definition that find the "best" view.
Fixesgolang/go#66425
Change-Id: Iadb1a01518a30cc3dad2d412b1ded612ab35d6cc
Reviewed-on: https://go-review.googlesource.com/c/tools/+/574718
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This change causes Hover to report size information for
types and struct fields when hovering over
the declaring identifier, plus offset information for
struct fields.
Some tests needed tweaks to make them CPU-independent,
or to disable them on 32-bit machines.
Also, add the first release notes using the new
git+gerrit workflow (and backfill a missing item for
"View package documentation").
Change-Id: Ibe8ac5937912c3802f3ad79e3d9f92ba24eb51de
Reviewed-on: https://go-review.googlesource.com/c/tools/+/573076
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
This CL does for the gopls module what CL 565035 did
for the x/tools module.
In particular, we don't yet address desired behavior
changes for materialized aliases, nor generic aliases.
Change-Id: Iace78c1f8466afe8a6a24e3da3d6f431bf5ebc3e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/565756
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Tim King <taking@google.com>
Rename methods on cache.Package to eliminate unnecessary "Get" prefixes.
Also rename pkg.go to package.go.
Change-Id: I42f2fa7a18a5973a53af93c63b48c7db19cba3b2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/572475
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
This change fixes a gopls panic caused by giving go/types@go.1.20
a Go version string with three components, e.g. go1.2.3.
Unfortunately this is hard to write a test for, since it requires
building gopls with go1.20 and running it with a go1.21 toolchain.
Fixesgolang/go#66195
Change-Id: I09257e6ded69568812b367ee80cafea30add93d3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/570135
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
In golang/go#66145, users reported spurious import errors in multi-root
workspaces. The problem was related to scenarios where module A had a
local replace of module B, and the user opened a file F in module B that
wasn't in the forward dependencies of module A. In this case, if the
View of module A tried to load F, it would get real packages (not
command-line-arguments), but due to module graph pruning the View of
module A would not have access to the full set of dependencies for
module B, resulting in the potential for import errors. Even this would
not be a problem, as long as the package that module A loaded for F was
not considered a 'workspace' package.
Unfortunately a couple of incorrect heuristics in gopls added along with
the zero-config work of gopls@v0.15.0 allowed us to diagnose these
broken packages:
1. In resolveImportGraph, we called MetadataForFile for each overlay. As
a result, the import graph optimization caused gopls to attempt
loading packages for each open file, for each View. It was wrong for
an optimization to have this side effect.
2. In golang/go#65801, we observed that it was inconsistent to diagnose
changed packages independent of whether they're workspace packages.
To fix that, I made all open packages workspace packages. It was
probably wrong for the set of workspace packages to depend on open
files. To summarize a rather long philosophical digression: open
files should determine Views, not packages.
Fixing either one of these incorrect heuristics would have prevented
golang/go#66145. In this CL, we fix (2) by building the import graph
based on existing metadata, without triggering an additional load.
For (1), we check IsWorkspacePackage in diagnoseChangedFiles to enforce
consistency in the set of diagnosed packages. It would be nice to also
remove the heuristic that "all open packages are workspace packages",
but we can't do that yet as it would mean no diagnostics for files
outside the workspace, after e.g. jumping to definition. A TODO is left
to address this another day, when we can be less conservative.
Fixesgolang/go#66145
Change-Id: Ic4cf2bbbb515b6ea0df24b8e6e46c725b82b4779
Reviewed-on: https://go-review.googlesource.com/c/tools/+/569836
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Use Func.Origin instead.
Change-Id: Ie4d29f2bd319a46901ce137107689e37d8e1edfa
Reviewed-on: https://go-review.googlesource.com/c/tools/+/569316
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Tim King <taking@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
Fix two bugs discovered during the investigation of golang/go#66109,
which revealed the strange and broken intermediate test variant form
"path/to/command/package [command-line-arguments.test]", referenced from
the equally broken
"command-line-arguments [command-line-arguments.test]". This latter
package was *also* detected as an ITV, which is why we never tried to
type check it in gopls@v0.14.2.
- Snapshot.orphanedFileDiagnostics was not pruning intermediate test
variants, causing it to be the one place where we were now type
checking ITVs.
- Fix the latent bug that caused gopls to record a dangling edge between
the two ITVs.
There is a third bug in go/packages, filed as golang/go#66126.
Fixesgolang/go#66109
Change-Id: Ie5795b6d5a4831bf2f73217c8eb22c6ba18e59cd
Reviewed-on: https://go-review.googlesource.com/c/tools/+/569035
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
We should not create Views for vendored modules, just as we don't create
Views for modules in the module cache. With this change, gopls behaves
similarly to gopls@v0.14.2 when navigating around the Kubernetes repo.
Also add some test coverage that vendored packages are not workspace
packages.
Fixesgolang/go#65830
Change-Id: If9883dc9616774952bd49c395e1c0d37ad3c2a6a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/565458
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Fix two bugs related to workspace packages that contributed to
golang/go#65801.
The first is that we didn't consider packages with open files to be
workspace packages. This was pre-existing behavior, but in the past we
simply relied on diagnoseChangedFiles to provide diagnostics for open
packages, even though we didn't consider them to be part of the
workspace. That led to races and inconsistent behavior: a change in one
file would wipe out diagnostics in another, and so on. It's much simpler
to say that if the package is open, it is part of the workspace. This
leads to consistent behavior, no matter where diagnostics originate.
The second bug is related to loading std and cmd. The new workspace
package heuristics relied on go/packages.Package.Module to determine if
a package is included in the workspace. For std and cmd, this field is
nil (golang/go#65816), apparently due to limitations of `go list`. As a
result, we were finding no workspace packages for std or cmd. Fix this
by falling back to searching for the relevant go.mod file in the
filesystem. Unfortunately this required reinstating the lockedSnapshot
file source.
These bugs revealed a rather large gap in our test coverage for std. Add
a test that verifies that we compute std workspace packages.
Fixesgolang/go#65801
Change-Id: Ic454d4a43e34af10e1224755a09d6c94c728c97d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/565475
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
As described in golang/go#65762, treating locally replaced modules the
same as workspace modules doesn't really work, since there will be
missing go.sum entries. Fortunately, this functionality was guarded by
the "includeReplaceInWorkspace" setting. Revert the default value for
this setting.
Fixesgolang/go#65762
Change-Id: I521acb2863404cba7612887aa7730075dcfebd96
Reviewed-on: https://go-review.googlesource.com/c/tools/+/564558
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Update the view selection algorithm to consider replace directives,
treating locally replaced modules in a go.mod file as workspace modules.
This causes gopls to register watch patterns for these local replaces.
Since this is a fundamental change in behavior, add a hidden off switch
to revert to the old behavior: an "includeReplaceInWorkspace" setting.
Fixesgolang/go#64762Fixesgolang/go#64888
Change-Id: I0fea97a05299acd877a220982d51ba9b4d4070e3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/562680
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
To prepare for the follow up change, where we honor local replaces in
the view selection algorithm, treat go.mod files more like go.work files
in a couple places:
- Re-run the view selection algorithm whenever a go.mod file changes on
disk.
- Use the workspaceModFiles field in the bestView algorithm, rather than
checking the gomod field directly.
Apart from perhaps running the view selection algorithm more frequently,
this change should have no observable impact.
For golang/go#64888
Change-Id: I9d9a74b876791a77e284a1a1d5fcc7a691199901
Reviewed-on: https://go-review.googlesource.com/c/tools/+/562679
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
The "missing Diagnostic.Code" assertion checks an invariant
that isn't guaranteed. This change downgrades it to a bug.Reportf.
Also, we add a similar assertion to analysistest.RunWithSuggestedFixes
which has much better coverage of all the analyzer's different
ways of constructing a SuggestedFix, unlike gopl's own superficial
tests of each analyzer it carries. (This assertion may be enabled
only for analyzers in x/tools, since the invariant is stricter
than is required by the public API.)
Also, fix a couple of places in unusedvariable where it could
conceivably return a fix with no TextEdits; they are not intended
to be lazy fixes.
Fixesgolang/go#65578
Change-Id: I5ed6301b028d184ea896988ca8f210fb8f3dd64f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/562397
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
Commit-Queue: Alan Donovan <adonovan@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Gopls' refresh of the goimports resolver already introduces
non-determinism into imports operations: gopls does not observe changes
until the asynchronous refresh occurs.
This change allows operations to continue to run on the stale resolver
until a new resolver is ready.
Due to inherent raciness, it's hard to benchmark the impact of this
change: one would have to catch gopls during a refresh, which occurs at
an automatically adjusted pacing.
Also update TODOs.
Fixesgolang/go#59216
Change-Id: I303df998d804c9a1cd1c0e307872d1d271eed601
Reviewed-on: https://go-review.googlesource.com/c/tools/+/561235
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
When using the gopls daemon, or with the multi-View workspaces that will
be increasingly common following golang/go#57979, there is a lot of
redundant work performed scanning the module cache. This CL eliminates
that redundancy, by moving module cache information into the cache.Cache
shared by all Sessions and Views.
There should be effectively no change in behavior for gopls resulting
from this CL. In ModuleResolver.scan, we still require that module cache
roots are scanned. However, we no longer invalidate this scan in
ModuleResolver.ClearForNewScan: re-scanning the module cache is the
responsibility of a new ScanModuleCache function, which is independently
scheduled. To enable this separation of refresh logic, a new
refreshTimer type is extracted to encapsulate the refresh logic.
For golang/go#44863
Change-Id: I333d55fca009be7984a514ed4abdc9a9fcafc08a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/559636
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Switch the ModuleResolver from a lazy initialization model to a
constructor, so that the resolver returned by ProcessEnv.GetResolver is
ready to use.
A constructor is easier to maintain as it involves less state, avoids
redundant calls to init, and avoids bugs where the call to init is
missing (such as was the case for the scoreImportPath method). It also
lets the caller differentiate between a failure to construct the
resolver and a resolver that only returns errors.
Pragmatically, I'd like to move toward a model where the caller re-scans
imports by asynchronously cloning, priming, and replacing the resolver,
rather than blocking. This is a step in that direction.
This change is not without risk, but it looks like all calls to
ModuleResolver methods are preceded by a call to GetResolver, and
errors from GetResolver are handled similarly errors from methods.
There is some messiness resulting from this change, particularly in
tests. These are noted inline, and can eventually be fixed by similarly
avoiding lazy initialization of ProcessEnv.
For golang/go#59216
Change-Id: I3b7206417f61a5697ed83e811c177f646afce3b2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/559635
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
With zero-config gopls (golang/go#57979), this function is no longer
used.
Change-Id: Ie59a7d39c62eab340fb6e44ddd9b7a0b1cabd92e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/560467
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
No matter where the go.work file is, the addition or deletion of
workspace-vendored modules mandates reinitialization.
Add the necessary watch pattern, and detect that reinitialization is
required in snapshot.clone. The latter required threading through the
file modification, so that we can detect creations and deletions
explicitly.
This is a great example of where having a realistic fake file watcher
paid off.
Fixesgolang/go#63375
Change-Id: Id3658e85bd2d915639d24fed31aba2d54ebc75e7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/560717
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Interestingly, this turned up one false positive of the form
var hook = func(err error) {}
where other build-tagged files not visible to the analysis
assigned other values to hook that actually used the
parameter.
Change-Id: I7d230160fd7e5ad67ade7b6e57db150bf68fa1c3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/560716
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
This change pushes the assertions more deeply into the type
checking logic so that we might have a chance of understanding
the recurring inconsistency problems reported by telemetry.
Updates golang/go#63822
Change-Id: I1371f7aa7104df0c55e055a11e9e6bb15219d79a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/560795
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Support workspace vendoring by simply removing logic in gopls for
deriving the `-mod` flag. If we don't need to set `-mod=mod`, let the go
command decide what to do. We don't need to worry about explicitly
setting `-mod=readonly`, since this has been the default since Go 1.16.
For golang/go#63375
Change-Id: I1adbe20cef5b9e3edcb7ac2445c4d5ae63f3a3a9
Reviewed-on: https://go-review.googlesource.com/c/tools/+/560466
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
The previous assertion required exactly one, but this condition
is violated by a file=emptyfile.go query, which produces no
CompiledGoFiles and IgnoredFiles=[emptyfile.go]. So we relax
the assertion, and use the first ignored file as the suffix.
Fixesgolang/go#64557
Change-Id: I097badd1b102bdc73af2ffa8a4871da1e359b173
Reviewed-on: https://go-review.googlesource.com/c/tools/+/560465
Auto-Submit: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
This change causes the metadata graph to assert that it is
acyclic before applying the updates. This should be an
invariant, but the attached issues make us skeptical.
Updates golang/go#64227
Updates golang/vscode-go#3126
Change-Id: I40b4fd06fcf2c64594b34b8c300f20ca0676d0fa
Reviewed-on: https://go-review.googlesource.com/c/tools/+/560463
Reviewed-by: Robert Findley <rfindley@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Remove the ProcessEnv.ModFile field, which was never set. Also add
additional comments and superficial cleanup.
Change-Id: I45d63e5039043d01d4280d2d916df6794e437d8a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/559506
Reviewed-by: Alan Donovan <adonovan@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Robert Findley <rfindley@google.com>
Now that views are immutable, we can simplify the invalidation of
imports state. The imports.ProcessEnv can also be immutable, and we need
only invalidate module state (i.e. dependencies) if a go.mod file
changes.
While at it, add documentation and perform some superficial cleanup in
the internal/imports package. This is a first step toward larger state
optimizations needed for the issues below. TODOs are added for remaining
work.
For golang/go#44863
For golang/go#59216
Change-Id: I23c1ea96f241334efdbfb4c09f6265637b38f497
Reviewed-on: https://go-review.googlesource.com/c/tools/+/559496
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Now that options are immutable on the view, we can safely memoize the
view's directory filter function. Do this, which fixes the regression in
BenchmarkReload observed in golang/go#64724.
For golang/go#64724
Change-Id: Iaf8c2d5e69e68e0077f07a72026ef46c0e19bcc0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/559157
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Add testenv.NeedsExec to this test, since it must be able to run the Go
command. Also fix the test error message.
Fixesgolang/go#65271
Change-Id: I525c5fd59cab7e057ab765eb41f2a84a7dd03635
Reviewed-on: https://go-review.googlesource.com/c/tools/+/559155
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Missing or null arguments can be expressed in a variety of ways,
so provide a helper function to consolidate the necessary checks.
Change-Id: I595f71a6485d84883667f3c6adf5a87c41fbd6aa
Reviewed-on: https://go-review.googlesource.com/c/tools/+/556695
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
The lsp directory is no more.
Change-Id: I7badd01645c7faab841e6219387cb84d8b893f2b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/557741
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Alan Donovan <adonovan@google.com>
Alan Donovan
Rob Findley
cuishuang
racequite
Suzy Mueller