xyz and err in
type A func(xyz int) (err error), or
type B struct{xyz int}
were incorrectly marked as types, when they are not.
These are now marked as variables (although the choice is somewhat
arbitrary for A).
Fixesgolang/go#45233
Change-Id: I2df4eab7606c356f30bf3337c12d9190e74bc392
Reviewed-on: https://go-review.googlesource.com/c/tools/+/305209
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Peter Weinberger <pjw@google.com>
It would be nice if tsc -script code.ts util.ts ran without errors,
but it doesn't. tsconfig.json documents which strict setting work and
which ones don't. code.ts and util.ts have some small typescript improvements
and running them has changed slightly, as documented in README.md.
Change-Id: Idee4934bede900df2f64165359e17a42d695f518
Reviewed-on: https://go-review.googlesource.com/c/tools/+/305210
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>
There are 2 different anonymous struct declarations that require
different approaches:
1. var x struct{...}
2. x := struct{...}{}
For the first one we can use the existing solution with a minor update.
However, it returns the wrong docs for the fields of nested structs.
To fix this we need to visit all fields recursively.
The second one is not a generic declaration. So, the simplest solution
is to use the method Snapshot.PosToField.
Fixesgolang/go#43675
Change-Id: I46685e7985cbf2c1c5b1b74ef3cd3a70b920feba
GitHub-Last-Rev: 8a5704c2ecc3f8a007c00c7adcd637e56d99106c
GitHub-Pull-Request: golang/tools#284
Reviewed-on: https://go-review.googlesource.com/c/tools/+/300029
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Bryan C. Mills <bcmills@google.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>
The blank identifier is always a local variable. It can't be
a function parameter or a return value.
Fixesgolang/go#44813
Change-Id: Ieca9da35aaa9f5826ab89ded73702bed952e1226
GitHub-Last-Rev: bb7a2353ab64eed7f13bd5b9cb3b85d90b71c0ed
GitHub-Pull-Request: golang/tools#294
Reviewed-on: https://go-review.googlesource.com/c/tools/+/305429
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Move postfix completion functionality behind an experimental option
flag. For now users can enable it by setting
"experimentalPostfixCompletions" or "allExperiments".
I added a RunnerOption so regtest tests can tweak *source.Options. I
didn't refactor the "Experimental" mode to use the new RunnerOption
because I didn't fully understand its purpose.
Change-Id: I75ed748710cae7fa99f4ea6ea117ce245a4e9749
Reviewed-on: https://go-review.googlesource.com/c/tools/+/296109
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
Trust: Heschi Kreinick <heschi@google.com>
Trust: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Postfix snippets are artificial methods that allow the user to compose
common operations in an "argument oriented" fashion. For example,
instead of "sort.Slice(someSlice, ...)" a user can expand
"someSlice.sort!". The snippet labels end in "!" to make it clearer
they do something potentially unexpected. The postfix snippets have
low scores so they should not interfere with normal completions.
The snippets are represented (almost) entirely as Go text/template
templates. This way the user can create custom snippets to match their
general preferences or to capture common patterns in their codebase.
There is currently no way for the user to create snippets, but it
could be accomplished with a configuration file, custom LSP command,
or similar.
I started by implementing a variety of snippets to help flesh out the
various facilities needed by the templates. The most interesting
template capabilities are:
- The ability to import packages as necessary (e.g. "sort" must be
imported to call sort.Slice()).
- The ability to generate unique variable names to avoid accidental
shadowing issues.
- The ability to weave LSP snippets into the template. Currently,
only {{.Cursor}} is exposed, which corresponds to the snippet's
final tab stop.
Briefly, these are the postfix snippets in this commit:
- foo.sort => sort.Slice(foo, func(...){}) (slices)
- foo.last => foo[len(foo)-1] (slices)
- foo.reverse (slices)
- foo.range => for i, v := range foo {} (slices/maps)
- foo.append
This snippet inserts a self-assignment append statement when
appropriate, otherwise just an append expression.
- foo.copy creates a copy of a slice
- foo.clear empties out a map
- foo.keys creates slice of keys
- foo().var assigns result value(s) to variables
- foo.print prints foo to stdout
Some of these are probably not very useful in practice, and I'm sure
there are lots of great ones I didn't think of.
Updates golang/go#39507.
Change-Id: I9ecc748aa79c0d47fa6ff72d4ea671e917a2d5d6
Reviewed-on: https://go-review.googlesource.com/c/tools/+/272586
Run-TryBot: Muir Manders <muir@mnd.rs>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Declare an unexported type and use it in OfString/UnpackString
so it is impossible to fool the Label.UnpackString into
accessing a non-string.
Change-Id: I840fcc99590e532a78a5f9a416cd40ce9ec2163a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/305309
Trust: Jonathan Amsterdam <jba@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
At long last, with Pontus's help reproing on Github actions, we have
tracked down the race to the gc_details diagnostics.
Since toggling gc_details does not increment the snapshot ID, we have to
use careful locking to ensure that the gc_details diagnostics we store
are consistent with the current state of the gc_details toggle.
Updates golang/go#44099Fixesgolang/go#44826
Change-Id: I7b9108a829c98a84360c9012c1b60f4990839b5a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/304169
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: Heschi Kreinick <heschi@google.com>
Some of the refactoring changed the way that we label code action kinds,
and we need to add quickfix and fixall kinds for each diagnostic type.
Support a per-kind suggested fix, and fix a small issue in setting the
analyzer for a fixall code action.
Fixesgolang/go#45111
Change-Id: I6bb32c9aa7427b690f42910672d3139579e84478
Reviewed-on: https://go-review.googlesource.com/c/tools/+/303209
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>
According to its comment, reloadOrphanedFiles is intended to work around
overlay bugs. But as of 1.16, there are no overlay bugs that we know of.
So what is it still doing?
Apparently, quite a bit, not much of it useful. Clean up as much as
possible.
- Files with no valid package declaration are ignored by the go command.
There's no point trying to reload them; stop.
- During metadata invalidation, we clear out all IDs for a file, even if
only one of its IDs is invalidated, e.g. when a test package is removed.
That leaves valid metadata for the non-test, so we don't refresh it in
the workspace reload, and only catch it as an orphan. It seems to me we
should only remove the invalidated ID.
- If the client incorrectly sends us a didOpen for a non-Go file, we
will attempt to load it as an orphaned file. Fix the regtest that did
that.
- TestEmptyGOPATHXTest_40825 set up an invalid GOPATH: you can't work in
GOPATH/src. However, it exists to test code that no longer exists, so
just delete it.
After this change, almost none of the regression tests trigger orphaned
file reloading. It's difficult/impractical to rule it out entirely
because some of them only appear racily. Since I intend to remove the
code path, I'm not too worried about more creeping in before I'm done.
The only useful case is multiple ad-hoc packages. Because we only
allow one "command-line-arguments" package in the workspace, if you
switch between two the old one becomes orphaned. I hope to work on that
soon.
Change-Id: Ia355cf104280ce51f6189c6638e8da8f4aef2ace
Reviewed-on: https://go-review.googlesource.com/c/tools/+/302089
Trust: Heschi Kreinick <heschi@google.com>
Trust: Rebecca Stambler <rstambler@golang.org>
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>
The log replayer is obsolete, and the logs parser it uses is badly
out of date.
Change-Id: I7f6b0a3bd3176a7a08379c333083daf75c98a523
Reviewed-on: https://go-review.googlesource.com/c/tools/+/303231
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>
Running gopls/internal/coverage/coverage.go in the tools directory
produces a coverage file (/tmp/cover.out by default) and a report
showing how well the gopls tests cover the packages in internal/lsp.
Change-Id: I1a7a22321f807ae54194833ee6a8e2a80bd9dca0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/303290
Run-TryBot: Peter Weinberger <pjw@google.com>
Trust: Peter Weinberger <pjw@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Prior to this, the line identified as the start of a command by the test
for a leading dot was dropped. This behaviour is not documented in the
present package documentation.
Change-Id: Ib7354f0f4a661fccc65be5f92d487fe7f627302f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/260899
Run-TryBot: Ian Lance Taylor <iant@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Zhang <cherryyz@google.com>
With -mod=readonly, all go.mod diagnostics are covered by go get quick
fixes on import statements, so we don't need to run `go mod tidy` on
save for Go files. The real issue with this bug is the call to
WorkspacePackages, which type checks every package in the workspace.
Fixesgolang/go#45092
Change-Id: Ibb82a3e58ec345ebdb67c0cbef5e029dce2d5a30
Reviewed-on: https://go-review.googlesource.com/c/tools/+/303149
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>
Locating the workspace module by convention has multiple problems:
+ gopls's view of $TMPDIR might be different from the client
+ there might be multiple views
+ there might be multiple gopls sessions per pid
Instead, assign a temp workspace directory for each workspace folder,
and provide a command to access this information.
Cleaning up all these temp directories was overcomplicated. Instead,
create a temp directory for the gopls server to nest them under, that
can be removed up on server shutdown.
Also fix a bug where the snapshot was not acquired before copying its
workspace.
Updates golang/go#42252
Change-Id: I0641cebe09cd376dfa27373cac30397711c64a8f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/300409
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 CL updates addErrCheckAndReturn to return "if err != nil { t.Fatal(err) }"
if the conditions for such snippet completion are met.The CL allows for
the following condition:
The enclosing functions takes a type that implements testing.TB which allows
for tests, benchmarks and extensions to the testing object to be completed.
Also, this CL doesn't explicitly check for the Test/Benchmark function
signature so that test helpers can also get the same benefits.
The remaining conditions for the current "if err != nil" checks also apply.
In the future, more testing completions UX can be added.
Fixesgolang/go#43310
Change-Id: I45197ab25610e31fef629394c79cb3792b532e7d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/279488
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Suzy Mueller <suzmue@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The GoogleCN code is specific to the code for golang.org,
which no longer uses golang.org/x/tools/godoc.
For golang/go#32011.
Change-Id: If13e3ed93d57f9d8a6c0f8a09b8343567dd6c0b1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/296373
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
In debugging the metadata CLs, I noticed that when a view's only go.mod
file became unparseable, we would fall back into reloading the entire
view. In such cases, we should just not reinitialize.
Change-Id: I1b552158da8855bf80e9ded8b29c346c67564239
Reviewed-on: https://go-review.googlesource.com/c/tools/+/300674
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 much as possible, try to unify the codeAction code paths. We always
run analysis now. And rather than assuming certain categories of
analyzers will generate certain kinds of code actions, mark them
explicitly and use that information to filter the actions afterward.
Change-Id: I8154cd67aa8b59b2a6c8aa9c3ea811de2e190db4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/300170
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>
Generating go get quick fixes in a single place only made it harder to
get them right. Do it during diagnostics generation, as is the new
norm.
Also improve the user experience. When we fail to import a package
because one of its dependencies is missing, it makes more sense to run
go get on the package we tried to import, not the one that's missing:
that will download all of its missing dependencies if there happen to be
more.
Change-Id: Ib6a8140bccfafcb9f966d25639799dd4c7347c3d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/300072
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>
When parse errors occur, go's parse package cannot recover nicely.
gopls tried to compute folding ranges based on the partial info
in this case, but returning partial folding range info confuses
editors (vscode) and results in dropping previous folding range
info from the region after the parse error location.
This CL makes gopls not to return anything - so the editor can
tell the result is not believable and ignore it.
The ideal solution is to return a response explicitly surfacing
this case, but currently LSP (3.16, as of today) does not have
a way to describe this condition. See the discussion in
https://github.com/microsoft/language-server-protocol/issues/1200.
We also tried to make gopls return an error. While it worked
nicely in VSCode, we are not sure about how other editors handle
errors from foldingRange. So, instead, we just let gopls return
an empty result - since foldingRange is already broken in this
case, we hope it doesn't add a lot of noise to existing users.
VSCode Go will check the response from the middleware. If the
response is empty but the file is not empty, VSCode Go will
ignore the response.
(https://go-review.googlesource.com/c/vscode-go/+/299569)
Updates golang/vscode-go#1224
Updates golang/go#41281
Change-Id: I917d6667508aabbca1906137eb5e21a97a6cfdaf
Reviewed-on: https://go-review.googlesource.com/c/tools/+/291569
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
The logic to extract the receiver identifier from a func decl was
incorrect, accepting only the common T and *T syntaxes, and panicking on
*(T).
Fix this by copying the logic from go/types.
Fixesgolang/go#44806
Change-Id: I1c87ab21ac04e484972bc4161180ca1112df3c73
Reviewed-on: https://go-review.googlesource.com/c/tools/+/298852
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>
The only changes in this CL are semicolons.
Change-Id: Id13ef3d1e5634615cf6806c5465d066e1604554a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/299249
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>
Typescript merges different definitions for a type. This CL inserts
a pass over the types to do merges better. It also has a lot of
tiny renumberings to match error messages to the line they are on.
There are two substantive changes to code.ts:
1. In the first pass over the parsed types, setData() (at line 195)
is more careful about conflicts.
2. The new pass is cleanData() at line 528. All the code down to
line 670 is used for this.
3. At line 1094, the names chosen for generated types (structs
embedded in structs) needed to be made unique. The old code only worked
by luck.
4. To merge, the code needs to change Nodes from the AST. Unfortunately
the members of ts.Node are readonly, so one has to cheat the type system.
This is done three times, using a varaible named 'fake'.
The generated code in tsprotocol.go contains types that are never used.
In Typescript these are parts of union types, but the Go code has
chosen at most one of them.
Change-Id: I15a9e5adedce35ea5f47c3fbce2a8a552fb7337e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/297429
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>
This change fixes x/tools tests before CL 298650 lands. After that CL,
the go command reports a different error message when GO111MODULE=on
and it is invoked without a go.mod file (with a command that requires
a go.mod file). We plan to backport that change to 1.16.
For golang/go#44745
Change-Id: Idb3e146828703c89f788ae660ffc95aef16433e4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/298792
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Peter Weinberger <pjw@google.com>
Now that we're generating quick fixes at analysis time, we can use those
in code action requests and delete a fair amount of redundancy. The
codeAction function is a little cluttered, but I want to get it all in
one place before I decide how to split it up.
Change-Id: Icd91e2547542cce0a05c18c02a088833f71232a4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/297532
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>
Type error analyzers can be viewed as enhancing type errors, rather
than analyzers in their own right. Create a source.DiagnosePackage
function that combines the list/parse/typecheck diagnostics with type
error analyzers. This allows us to remove some special cases from the
analysis path, and is a first step in removing all the special
handling for analysis quick fixes.
Along the way:
Pass pointers to source.Analyzer after I spent half an hour chasing a
loop capture bug. Spend a further 2-3 hours chasing slowdown in the
command tests as a result.
Move Unnecessary tag generation into diagnostic creation rather than
as a mutating post-processing step that required cloning diagnostics.
Change-Id: Id246667a9dcf484dc79516f92d5524261c435794
Reviewed-on: https://go-review.googlesource.com/c/tools/+/297879
Trust: Heschi Kreinick <heschi@google.com>
Trust: Rebecca Stambler <rstambler@golang.org>
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>
Most callers of source.Package.GetDiagnostics do it via
GetTypeCheckDiagnostics. Push its logic up or down as appropriate and
delete it.
Rather than requiring fully populated maps of diagnostics, which was
rather subtle, call storeDiagnostics for every Go file in the package.
Change-Id: If43b0cc922af1013e80f969362246538df14985b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/297878
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 current hover information for constant time.Duration is not very
useful because it displays nanoseconds. So, show formatted duration
as an inline comment.
Fixesgolang/go#44667
Change-Id: I6177455fb8932d1914d5cf623c0d9c4eff8f0b3f
GitHub-Last-Rev: e168968012741a1e614c66bc97fe60b196943ed3
GitHub-Pull-Request: golang/tools#281
Reviewed-on: https://go-review.googlesource.com/c/tools/+/297310
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Rebecca Stambler <rstambler@golang.org>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
In CL 295413 we fixed the handling of related type checker diagnostics
to correctly identify the primary and secondary errors at a position.
However, on clients that don't support diagnostic related information,
this can lead to confusing primary diagnostics.
Add handling for clients that don't support related information, to
embed the secondary error in the primary error.
Fixesgolang/go#44735
Change-Id: I3d2470d2a4044661e6ed31ac9ffd2f9ff27f7d4b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/297875
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: Heschi Kreinick <heschi@google.com>
Rather than using the directory of the package, store the package ID and
calculate the directory in GCOptimizationDetails. I think this is
slightly more readable/cleaner.
Change-Id: I13cac8a7552b73b2bd5d25ff582b5d4936a74827
Reviewed-on: https://go-review.googlesource.com/c/tools/+/297877
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>