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>
The URL regexp is apparently enormous and we spend 13 CPU-seconds
compiling it in the gopls version of the LSP tests.
Change-Id: Id291ce0f104aa02b5e38aad43fff8647ce1b5b98
Reviewed-on: https://go-review.googlesource.com/c/tools/+/297876
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>
CL 295414 suppressed all type checking errors in the presence of parser
errors, but this was a bit overzealous. go/types attempts to suppress
follow-on errors from bad syntax, so as long as we haven't had to modify
the AST and the current file parses, type checking errors can still
provide a decent signal to the user
Fixesgolang/go#44736
Change-Id: Icd89404fbae663b8f934a38908eaaa87c561b64a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/297872
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>
In practice, the only code shared among the various switch cases was the
call to spanToRange, which definitely doesn't justify the giant
function. Split it out into per-type functions.
I removed the unused case for types.Error, and a bit of error checking I
believe to be redundant. I don't intend any functional changes.
At this point it might be worth considering moving the functions into
other files, but I don't think it matters that much.
Change-Id: I05b4d86dd37a9ff1887a116183c915c225faf3a7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/297129
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>
Hopefully improve some of the details around parsing that have always
confused me.
- parser.ParseFile will never return an error other than
scanner.ErrorList. Encode that in ParsedGoFile.
- parser.ParseFile will never return a nil file. Eliminate the code
path that handled that.
- Explain why we might fail to find a token.File.
- Trying to fix errors appears quite expensive even if there aren't any
to fix. Don't waste the time.
Change-Id: I87e082ed52c98a438bc7fd3b29e1a486f32fb347
Reviewed-on: https://go-review.googlesource.com/c/tools/+/297069
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When a //go:embed or //go:build (//+build) line changes, we need to
invalidate metadata. Do so. It might be preferable to only invalidate on
save, but we don't currently have an approach for doing that. So for now
we'll load on each keystroke in a magic comment.
Fixesgolang/go#38732, golang/go#44342.
Change-Id: Id05fb84f44215ea6242a7cf8b2bca4e85f74680e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/296549
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>
go/packages.Error has filenames relative to the go command's working
directory. We need to interpret them as such.
This would perhaps be better done in go/packages but with no release
process in place I'm leery of making changes to it.
Updates golang/go#44342.
Change-Id: I95bcdff0368efe09ec7059394e59a39bf195310b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/295412
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
In typeCheckDiagnostics, we have logic to suppress go list and type
checking errors based on the presence of other errors. Nobody seems to
know why the logic is exactly what it is, and suppressing list errors
means that bad //go:embed patterns don't show up.
Intuitively, it makes sense to me that we don't want to type check if
listing or parsing fails: list errors mean that whole files may be
missing, and parsing errors may wipe out arbitrary chunks of files.
There's little point reporting errors from type checking that. However,
list errors and parse errors should be mostly orthogonal: go list
parses very little of the file and in practice only reports errors
parsing the package statement. So, at least for now, we report both
parse and list errors, and stop there if there are any.
Finally, move the suppression logic to the actual typeCheck function
that generates the diagnostics. typeCheckDiagnostics is the primary
consumer, but I think it's better to do the suppression at the source.
Because we are now showing list errors, and they are prone to getting
stuck due to bad overlay support, a couple of tests now require 1.16.
Change-Id: I7801e44c4d3da30bda61e0c1710a2f52de6215f5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/295414
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Due to misuse of the expandErrors function, when we encountered a
continuing error, we would group all the related errors into a single
one, then return both it and all its secondaries individually. That
makes for a strange user experience where you get one complete error and
N-1 incomplete ones.
Instead, create a copy of the complete error for each secondary error,
moving the copy to the location of the secondary error and adding a bit
to the text to (hopefully) clarify what's going on.
Change-Id: I87cf0e3b2cea98317f650d16a78476edf108a934
Reviewed-on: https://go-review.googlesource.com/c/tools/+/295413
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>
Rewrite eg to use go/packages, so that it works with Go modules.
There are two known regressions:
* lost build tag support
* you can't use a template to add a new dependency
These can be re-added at a future point as needed.
Change-Id: I2b59bb5e101c738a4d4c40e84a12c5b3a19bcd18
Reviewed-on: https://go-review.googlesource.com/c/tools/+/258304
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
The /share registration is not needed by programs like
talks and blog, only by golang.org, so installing it by default
is unnecessary and perhaps more exposure than people running
those servers intend.
Add Proxy to allow recreating the /share registration (unlikely)
or installing the proxy on an alternate mux (more likely).
Change-Id: Ibb33add804d353920d405bf022428e48b3815da3
Reviewed-on: https://go-review.googlesource.com/c/tools/+/293449
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
The go/types fix for golang/go#44515 changed the type string for unsafe.Pointer
from a fixed "unsafe.Pointer" to a customizable package path followed
by "Pointer" (the customization was in place for any other object already).
The package path customization is done through a user-provider types.Qualifier
function. If none is provided, the ordinary package path is used ("unsafe").
Guru provides a package-relative qualifier which leaves away the package
path if an object is local to a package. As a result, unsafe.Pointer is
printed as "Pointer" which breaks an existing test.
Provide no qualifier function when printing a type from package unsafe
instead (there's only unsafe.Pointer). Since no qualifier was used in
the past, this Guru-specific change will also work when run using earlier
Go versions.
Fixesgolang/go#44596.
Updates golang/go#44515.
Change-Id: I3c467e4ed09aa13deb50368fe98e42c723a6376b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/296289
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
According to https://golang.org/doc/go1.14#runtime
A consequence of the implementation of preemption is that on Unix systems, including Linux and macOS
systems, programs built with Go 1.14 will receive more signals than programs built with earlier releases.
This causes syscall.Open and syscall.ReadDirent sometimes fail with EINTR errors.
We need to retry in this case.
Fixesgolang/go#44478
Change-Id: I0b0291471e47e8682fac791e1ed024b5a42a56f8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/294730
Reviewed-by: Heschi Kreinick <heschi@google.com>
Trust: Heschi Kreinick <heschi@google.com>
Trust: Peter Weinberger <pjw@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Vet complained about multiple definitions of the 'workspace' tag.
The underlying error was a failure to do type merging in alias types,
coupled with relying on luck when generating types and deciding which
type definitions to store. (Luck almost worked, but more careful type
merging made it too risky.)
The only noticeable change (outside tsprotocol.go) is that the
generated type names used in general.go now have serial numbers in them.
tsserver.go and tsclient.go just have new dates in their headers, but
are otherwise unchanged.
tsprotocol.go has more generated types (Workspace.*Gn). (There are
probably more types than are needed, but fixing that is for the future.)
All the tests pass and gopls seems to work ok. The revised code.ts will
be submitted in a future CL.
Change-Id: I7082755c327e7b6ebec57d4449eec1e0cc50fcd5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/294909
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Peter Weinberger <pjw@google.com>
Run-TryBot: Peter Weinberger <pjw@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Without this parser mode, go/parser will bail out and return no comments
from a parsed file if there are more than 10 errors. This can lead to
tests silently not running, as noted in the TODO right above the parse.
This can still happen: poor parser recovery could result in comments not
being parsed. However, the parser is generally pretty good about
preserving comments, and anyway passing parser.AllErrors means that
adding a single new error to a testdata file will not suddenly cause all
errors in that file to be ignored.
Change-Id: Ib3c22944999651018d38fa6ce5c5a11ac6853aa0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/293932
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>
### gopls
- Add `https` scheme to `CodeDescription.href`
According to the [LSP specification](https://microsoft.github.io/language-server-protocol/specification#diagnostic), `CodeDescription.href` must be [URI type](https://microsoft.github.io/language-server-protocol/specification#uri). As described in the [RFC](https://tools.ietf.org/html/rfc3986#section-3), the scheme is required for URI:
> The scheme and path components are required, though the path may be empty (no characters).
Current `gopls` does not add the scheme to `CodeDescription.href`, and this results in some LSP clients ([at least this client](https://github.com/autozimu/LanguageClient-neovim)) which are strictly validating the URI format to be failed to populate diagnostics.
Change-Id: I73f01c2e97ed1adb62fbed451a7c9b0c9794b66a
GitHub-Last-Rev: 6985bfe60e182ee788082d8fcb9515275d9612fa
GitHub-Pull-Request: golang/tools#277
Reviewed-on: https://go-review.googlesource.com/c/tools/+/294569
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>
Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild
Not strictly necessary but will avoid gofmt changes later
as people edit these files.
Change-Id: I20749ed82e18938a305d9425d0739f0ea7bd24c0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/294414
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild
The Go 1.17 gofmt will insert the extra //go:build lines.
The older gofmts will not remove them.
Get ahead of the game by adding them now.
(Keeps x/tools tests passing on go repo trybots.)
Change-Id: Ifdb4af93f6cc38a9aa616516e923384b7312e991
Reviewed-on: https://go-review.googlesource.com/c/tools/+/294413
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
This checker checks for instances of writes to struct fields and arrays
that are never read.
Change-Id: Ibeb4fc45d7b87a2ea571ba23a29ec44529623f0d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/287034
Reviewed-by: Tim King <taking@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Trust: Tim King <taking@google.com>
After playing with these a little, they definitely get the job done.
But I'm already seeing a few ways the API could be nicer (e.g.,
provide a bundle-backed go/importer.Importer implementation that reads
packages out on demand, so unneeded packages don't need to be read).
So mark these APIs as experimental so users know not to get too
attached to them just yet.
Change-Id: Idb98f45095a0c6f9825ff07172f62c42d8453016
Reviewed-on: https://go-review.googlesource.com/c/tools/+/294310
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
The comparable interface is introduced on the dev.typeparams branch.
Filter it out from gopls completion results so that it doesn't break
tests on the dev.typeparams branch.
Change-Id: Iba22c0980c09e99b454ce9e22813cc3a1f94a90c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/293931
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>
Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild
Report misplaced and malformed //go:build lines,
like we've always done for // +build lines.
Report when the // +build lines do not say the same thing as the //go:build line.
(Running gofmt will always bring them back in sync.)
For Go 1.17 vet.
Change-Id: Ifd22c6e8edcfeedc37851ba514712c5c057ad4b8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/293834
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TestFillStruct had an unnecessary dependency on the go/types.Info API.
Break the dependency.
Change-Id: I7cacd045487e3a7d2ba92a6f76f6b37e0ea33bfb
Reviewed-on: https://go-review.googlesource.com/c/tools/+/293929
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
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>
Change-Id: I7bb1caf63772a460206dd6ca0a35b11a61ca162f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/293531
Run-TryBot: Ian Lance Taylor <iant@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Previously, we were running `go get` only on modules, which led to us
not downloading dependencies of packages. This resulted in further
go.mod diagnostics that users could not resolve with quick fixes. Now,
download packages directly so that dependencies are downloaded.
Fixesgolang/go#44307
Change-Id: Id764ea5a2f7028e238eadaaba0ca3cfc765b85b4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/293729
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>
If pkgdir uses a symlink (e.g., how the macOS builders are currently
setup for their GOROOT, due to how /var and /tmp work there), then
changing into that directory to invoke cgo means that cgo will only be
able to see the actual directory it was run from. This can lead to
inconsistencies with code that expects to see the original
symlink-based path.
This CL changes go/internal/cgo to instead use cgo's -srcdir flag so
that cgo can emit //line directives with the symlink paths instead.
Fixesgolang/go#44339.
Change-Id: I3cbee6753454922711c8c70d7c64a02565b8bb4c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/293250
gopls-CI: kokoro <noreply+kokoro@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is a lead-up to a change to create a better help messages in the go command.
Change-Id: I695fd2bf5420a62774334c77788e67565d3965c1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/291909
Trust: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
Reviewed-by: roger peppe <rogpeppe@gmail.com>
Change-Id: Ifb3f1b03a8e0b58465e088cdda3e0357ce648124
Reviewed-on: https://go-review.googlesource.com/c/tools/+/293249
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It appears that /var/folders is a symlink to /private/var/folders on
macOS, and further that go/loader uses the original name whereas
cmd/compile uses the dereferenced name. (Judging based on error
messages.)
Change-Id: I3515b223031e3e7a1508acfdbb6dca3009ead398
Reviewed-on: https://go-review.googlesource.com/c/tools/+/292910
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Ainar Garipov
Hana
Rob Findley
pjw
Jay Conrod
Rebecca Stambler
Heschi Kreinick
Shoshin Nikita
Josh Bleecher Snyder
Russ Cox
Robert Griesemer
Ichinose Shogo
stephen
Yuki Ito
Guodong Li
Matthew Dempsky
smasher164
Joe Kyo
Rob Pike