In one of my previous refactoring changes, I lost the fact that the
context should be detached before invalidating a file's contents. If
this function is canceled, we will be in a bad state.
Also, small change to return ctx.Err() instead of a custom error message
from (*packageHandle).check.
Change-Id: I19e513e09e438feee105fdd89cb7364a0c3c5e7f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/212104
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Now that `go list` errors are sufficient for us to determine a circular
dependency, we don't need to cache errors on dependency packages.
Change-Id: I0633aeb356f93d21afed3371d61d7eae7de255ac
Reviewed-on: https://go-review.googlesource.com/c/tools/+/212197
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rohan Challa <rohan@golang.org>
Reviewed-by: Rohan Challa <rohan@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change merges the small helper functions that modified overlays
into a single function and removes the openFiles sync.Map in the view.
Change-Id: Id94c7d86228c9628b7373fab0030ad0c8018dda5
Reviewed-on: https://go-review.googlesource.com/c/tools/+/212037
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
This change eliminates the extra step of calling GetFile on the view and
getting the FileHandle from the snapshot. It also eliminiates the
redundant source.File type. Follow up changes will clean up the file
kind handling, since it still exists on the fileBase type.
Change-Id: I635ab8632821b36e062be5151eaab425a5698f60
Reviewed-on: https://go-review.googlesource.com/c/tools/+/211778
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
On startup gopls runs go/packages over the entire workspace. The log
message in question outputs each package found along with all the
package's filenames. Obviously in a large project this produces an
incredible amount of output. Fix by putting the log message behind the
"verboseOutput" flag when invoking go/packages in the "dir/..." mode.
I also added the go/packages "query" string to the
once-per-go-packages-call log message so it is more useful.
Change-Id: I651419e34a855325056bca6720eda8671f7d5fa8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/210739
Run-TryBot: Muir Manders <muir@mnd.rs>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
There is an issue when highlighting a single character identifier if the cursor is on the right of it. This problem
is a result of an assumption made in astutil.PathEnclosingInterval relating to the arguments passed in. Specifically,
if start==end, the 1-char interval following start is used instead. As a result, we might not get an exact match
so we should check the 1-char interval to the left of the passed in position to see if that is an exact match.
Updates golang/go#34496
Change-Id: If689fdf695df6ec1bc1935088e50d3de055bd5db
Reviewed-on: https://go-review.googlesource.com/c/tools/+/212137
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rohan Challa <rohan@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This CL makes sure that code.ts will generate the latest version
of tsprotocol.go. It has a more succinct way of deciding which fields
need to be pointers.
Change-Id: I6854cb2f096d3707bc3b828a9601f9384638f475
Reviewed-on: https://go-review.googlesource.com/c/tools/+/212140
Run-TryBot: Peter Weinberger <pjw@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This CL adds a "disableTempModfile" boolean that can be turned on or off.
While we are adding support for go.mod files in gopls, this flag will allow
users to opt out of using the -modfile flag that is enabled in Go 1.14. This
flag might be removed at a future point, the decision still needs to be made.
Updates golang/go#31999
Change-Id: Ic90229333e988fcc6d461ab1ee47bce1114bd965
Reviewed-on: https://go-review.googlesource.com/c/tools/+/212139
Run-TryBot: Rohan Challa <rohan@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
The import cycle not allowed error should be returned as a ListError not
an UnknownError.
Fixesgolang/go#35964
Change-Id: Ibc575f92d926ff715c0da67a4fceda05badcc652
Reviewed-on: https://go-review.googlesource.com/c/tools/+/212138
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rohan Challa <rohan@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
It wasn't infinite, but gopls would sit at 100% cpu for ~25 seconds
whenever I made a change to a package imported by essentially
everything in my project.
Change-Id: Ifa253a4de06897260e0791888284527258e8de48
Reviewed-on: https://go-review.googlesource.com/c/tools/+/212000
Run-TryBot: Muir Manders <muir@mnd.rs>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
The situation in golang/go#35638 was as follows:
didOpen main.go creates a snapshot that knows main.go is in package
"mod.com".
didChange main.go creates a snapshot. When a file changes, we discard
its contents by leaving the file handle out of the "files" map.
didOpen const.go creates a snapshot, and attempts to invalidate the
metadata for packages in the same directory.
The way we detect packages in the same directory is by iterating through
the files in the snapshot. But we threw away the only file in "mod.com"
in step 2 when its contents changed. If a diagnostics run happened to
get in between the two steps, it would re-load main.go and the bug would
go away. If not, step 3 would find no files and fail to invalidate
"mod.com".
The best way to fix this is to insert the new file handle eagerly during
cloning. That way there's no confusion.
Fixesgolang/go#35638.
Change-Id: I340bd28a96ad7b4cc912032065f3c2732c380bb2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/211578
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Eliminate the file watcher, since it led to a lot of confusion and
difficulty reasoning about the flow of a file action. This change splits
a file invalidation into the two logical steps - 1) things that affect
the overlay, and 2) things that affect the view. It is based on top of
CL 211757, so the diffs will look better once that CL is merged.
Change-Id: I277475569b61f3c80feaa6b6fe457b4bace82e35
Reviewed-on: https://go-review.googlesource.com/c/tools/+/211777
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
This change has no code modifications. Just move the handling for
overlays and debugging into separate files to make them easier to find.
Also, add some missing copyrights.
Change-Id: I7256f704c017457fa3418818d03f89f061af6fc9
Reviewed-on: https://go-review.googlesource.com/c/tools/+/211757
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Print the debug port to stderr when the debug server listens on a
dynamic port so that clients can determine which port to use when
launching a browser to the debug view.
Change-Id: I92f5e334df5cefdf54f7242ac2328b026852c70e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/211798
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
In the upcoming Go 1.14 release, there is an introduction of the -modfile
flag which allows a user to run a go command but choose where to direct the
go.mod file updates. The information about this can be found here: golang/go#34506.
This change starts setting up the infrastructure to handle the seperate modfile
rather than keep changing a user's go.mod file. To support versions of Go that are
not 1.14, we run a modified "go list" command that checks the release tags to see
if 1.14 is contained.
Updates golang/go#31999
Change-Id: Icb71b6402ec4fa07e5f6f1a63954c25520e860b0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/211538
Run-TryBot: Rohan Challa <rohan@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Clear out a few things I noticed aren't really used anymore.
Change-Id: I03f955015632197b56230ae0443cfb3871b54db2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/211717
Run-TryBot: Muir Manders <muir@mnd.rs>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change fixes the link anchors for fields within a struct or
composite literal by getting the enclosing types.Type.
Fixesgolang/go#36138
Change-Id: I534a900fad6fa6fa1b1acaa5a63ca264c5d34c39
Reviewed-on: https://go-review.googlesource.com/c/tools/+/211582
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Generally speaking, if the imports package can operate on a file, we can
assume that it's in good enough shape for the rest of our work. That
means it's important we run imports first. On one code path, we weren't.
Fixesgolang/go#36162.
Change-Id: I750aff31e0c3706aeb798ceb60c35ea17ba95943
Reviewed-on: https://go-review.googlesource.com/c/tools/+/211580
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is a continuation of the discussion on
https://github.com/microsoft/vscode-go/issues/2920. Add corresponding
checks to internal/lsp/cmd/capabilities_test.go.
Change-Id: I51af05dee9e7ecea0e40733dd4c5ca3dfb8f4dd8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/209859
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Cloning is complicated enough without worrying about concurrency, so
hold the snapshot's lock during the entire process.
Consolidate everything into one function. I don't think that the split
was making it easier to understand, and I was able to see and clean up
some extra complexity once it was all in one place. Let's discuss
options if you think the result is too long.
I don't intend any semantic changes in this CL.
Updates golang/go#35638.
Change-Id: I05c4b28875976293f5fcd56248d9c9e468f85cc6
Reviewed-on: https://go-review.googlesource.com/c/tools/+/211537
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
We weren't returning promoted methods as implementations when the
promoted method was defined in a different package than the type
implementing the interface.
Fix by properly mapping the implementer types.Object to its containing
source.Package.
I generalized the implementations() result to just contain the
implementer objects and their containing package. This allowed me to
get rid of some result prep code in Implementation().
Fixesgolang/go#35972.
Change-Id: I867f2114c34e2ad39515ee3c8b6354c1cd35f7af
Reviewed-on: https://go-review.googlesource.com/c/tools/+/210280
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Descriptions of certain commands were changed to not start with capital
letter.
All of the commands were splitted into so called main
commands and feature commands.
Package tool did have a limitation that revealed itself when command
was invoked only with `-h`, i.e. `gopls -h`. Limitation was that in
above mentioned case, FlagSet.Parse() was intercepting `-h` flag and
printing just default usage.
Updates golang/go#35855
Change-Id: I9bd27fc72e8fb8d18025d95ebcae974dd5583e91
Reviewed-on: https://go-review.googlesource.com/c/tools/+/210359
Run-TryBot: Ian Cottrell <iancottrell@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
In a previous change I inadvertently added completion candidates like:
var f func(int)
f = <> // useless candidate "func(int)(<>)"
Ignoring the fact it is a syntax error without more parens around the
signature, it isn't a useful candidate because you don't need to cast
when assigning a named signature type to an unnamed type.
Change-Id: Ic261817af344ee47193240a11dca5d3a32cbd293
Reviewed-on: https://go-review.googlesource.com/c/tools/+/211319
Run-TryBot: Muir Manders <muir@mnd.rs>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
If the cursor is within an argument that is within a callExpr which is
in a return statement, we only want it to highlight the ident that the cursor
is in. We do not want it to highlight the entire function.
Updates golang/go#34496
Change-Id: If4025660a99fd5df90098e0560a5e9e7260e33c8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/211338
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rohan Challa <rohan@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Created an analogous data structure for go.mod files when we parse them
using the golang.org/x/mod package. Gopls can now access the data
within a go.mod file using a parseModHandle and the corresponding
parseModData object. This will help down the road when it is time
to implement the lsp functions for go.mod files.
Updates golang/go#31999
Change-Id: Ibd4d64569bbe3df61b203490b63399d479e7d794
Reviewed-on: https://go-review.googlesource.com/c/tools/+/211303
Run-TryBot: Rohan Challa <rohan@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
After the addition of golang/go#35964, the import cycle error now
has the import stack attached in the message. This CL parses that
stack and attached the import cycle diagnostic to the import versus
just adding it to the first character of the .go file.
Fixesgolang/go#33085
Change-Id: I6f5f067c338879b898829951236f816aa63d9dfa
Reviewed-on: https://go-review.googlesource.com/c/tools/+/210942
Run-TryBot: Rohan Challa <rohan@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
The current handling of error messages did not address the case that a
user may have multiple directories listed in their GOPATH.
Fixesgolang/go#36120
Change-Id: I8e68a45d3dd902975a0ccf4177ec2698accdf69d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/211304
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
If there are less than 3 args for @item, it does an early
return without recording it for a given pos.
This leads to a panic when tests runner can't lookup
a non-nil item for a pos.
Since other collect* methods seem to use t.Fatal for error
handling, do the same in collectCompletionItems().
Change-Id: I21960731f532b93029e6e06800e0484dc7d599df
Reviewed-on: https://go-review.googlesource.com/c/tools/+/211257
Run-TryBot: Iskander Sharipov <quasilyte@gmail.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
When the expected type is a basic type, we will now offer a
corresponding type conversion candidate. For example:
var foo int64
foo = // offer "int64(<>)" as a candidate
The type conversion candidate will be ranked below matching concrete
candidates but above the sea of non-matching candidates.
This change broke almost every completion test. I added a new
completion option for literal candidates so tests can selectively ask
for literal completions.
Updates golang/go#36015.
Change-Id: I63fbdb33436d662a666c1ffd3b2d918d840dccc7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/210288
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This change refactors some of the logic that builds a link anchor for
a given symbol, pushing the actual Link into the HoverInformation struct.
This is necessary because type information is needed to build up that
link in certain cases, like methods.
The last step will be to correctly display struct fields.
Updates golang/go#34240Fixesgolang/go#36031
Change-Id: I7f989faddbaa07f91838a870b4477bf78ce8ddf7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/210201
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Having nil ranked normally causes it to show up as the top candidate
in cases like:
context.WithCancel(<>) // "nil" shows up before "context.Background()"
"context.Background()" gets a slight score penalty since it is a deep
completion, so "nil" is ranked highest.
Sometimes you do want "nil", but it's such a short identifier you
probably aren't leaning too heavily on autocompletion. I think it
makes sense to optimize for the case when you want something non-nil.
Change-Id: I537927db2b573535e751380c4cba5c9873dfe524
Reviewed-on: https://go-review.googlesource.com/c/tools/+/210539
Run-TryBot: Muir Manders <muir@mnd.rs>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Cache delivered diagnostics on the server so that we can determine if
they should be resent. To be careful about this, we only reuse cached
diagnostics if they are for a greater version, or if we don't know
the file's version and it is unchanged.
Fixesgolang/go#32443
Change-Id: I4ba22d85e5b21a8ad6cc62f74cd83c07d3c220cf
Reviewed-on: https://go-review.googlesource.com/c/tools/+/208261
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
This change is the next step in unification of text synchronization
methods. The logic really belongs in the internal/lsp/cache package
rather than the internal/lsp package.
Pulled out a function to run diagnostics on a file (diagnostics are still
run async).
Change-Id: I5e237411a02af210ad386b37a6c2aa62ef723567
Reviewed-on: https://go-review.googlesource.com/c/tools/+/210784
Reviewed-by: Heschi Kreinick <heschi@google.com>
We previously searched the reverse dependencies of the "widest"
package that contained out starting identifier, but if our package has
tests then the widest package is the ".test" variant, and it has no
reverse dependencies. Fix by searching through all of the packages
that contain our starting identifier.
For example:
-- foo/foo.go --
package foo
func Foo() {}
-- foo/foo_test.go --
package foo
func TestFoo(t *testing.T) {}
-- bar/bar.go --
import "foo"
func _() {
foo.Foo()
}
We would start searching from the foo.test variant, but we wouldn't
search package bar at all because bar does not import foo.test, it
imports plain foo. Now we search from both foo and foo.test (you still
need search foo.test to find references within foo_test.go).
Fixesgolang/go#35936.
Change-Id: I5fd2f7bb130a421ed6fad92da11179995c99a2cf
Reviewed-on: https://go-review.googlesource.com/c/tools/+/210537
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
When we are processing a go.mod file, we are calling go/packages.load
when we should not be. It will always return 0 packages since it is
not a .go file. This CL adds branching inside each internal/lsp protocol
function and also adds a check in snapshot.PackageHandles for the file type
and returns an error. This will prevent `go list` from running on go.mod files for now.
Updates golang/go#31999
Change-Id: Ic6d0e9b7c81e1f404342b98e10b9c5387adde2ee
Reviewed-on: https://go-review.googlesource.com/c/tools/+/210757
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rohan Challa <rohan@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Say you have foo.go and foo_test.go yielding packages "foo" and
"foo.test". Previously when you changed foo_test.go we would
invalidate the foo.test and foo packages. Invalidating foo is not
necessary since it does not depend on any test files. Furthermore, it
caused problems because nothing would refetch foo's metadata until
foo.go changed, so various things (such as finding implementations in
packages that depend on "foo") would be broken.
Now we only invalidate metadata from packages that contain the
modified file. We only invalidate type info from packages that contain
the modified file, or from such packages' transitive reverse
dependencies.
Change-Id: I23d1af91bcdf22fad4faa1b048afe17ef4e403a1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/210460
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This CL teaches lsp to report `**T` instead of `**invalid type`,
`func (badParam) badResult` instead of `func (invalid type) invalid type`, etc.
To do that, we need to detect "invalid type" inside any part of a type.
I've added typeIsValid() function for that.
To simplify type formating code in resolveInvalid(), formatNode
function is added that can also format *ast.StarExpr (of any depth).
Since we already used AST printer in the same file, I
added formatNode function that is now used in both places.
While at it, replaced bytes.Buffer to strings.Builder there.
Change-Id: I3bb84c58c417b175cceefb410e238c48425f7cee
Reviewed-on: https://go-review.googlesource.com/c/tools/+/210357
Run-TryBot: Iskander Sharipov <quasilyte@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
When the go.mod file changes, we should invalidate all the files that are
contained in the package for the mod file. This will allow the files to recheck
their packages in case new packages were added in the go.mod file.
This still does not fix issue where changes to go.mod files do not trigger recalculation of diagnostics.
Updates golang/go#31999
Change-Id: I6d8f1531f5c28ed2dca7fb8ad4ee0317fada787b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/210557
Run-TryBot: Rohan Challa <rohan@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
We previously only searched for implementations of the object we found
in the "widest" package variant. We instead need to search all
variants because each variant is type checked separately, and
implementations can be located in packages associated with different
variants.
For example, say you have:
-- foo/foo.go --
package foo
type Foo int
type Fooer interface { Foo() Foo }
-- foo/foo_test.go --
package foo
func TestFoo(t *testing.T) {}
-- bar/bar.go --
package bar
import "foo"
type impl struct {}
func (impl) Foo() foo.Foo { return 0 }
When you run find-implementations on the Fooer interface, we
previously would start from the (widest) foo.test's Fooer named
type. Unfortunately bar imports foo, not foo.test, so bar.impl
does not implement foo.test.Fooer. The specific reason is that
bar.impl.Foo returns foo.Foo, whereas foo.test.Fooer.Foo returns
foo.test.Foo, which are distinct *types.Named objects.
Starting our search instead from foo.Fooer resolves this issue.
However, we also need to search from foo.test.Fooer so we match any
implementations in foo_test.go.
Change-Id: I0b0039c98925410751c8f643c8ebd185340e409f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/210459
Run-TryBot: Muir Manders <muir@mnd.rs>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
When a file is changed, we invalidate various cached data so we
re-type check and refetch metadata as needed. Previously when a file
changed we would delete the metadata for all transitive reverse
dependencies. This broke all-packages-in-workspace features since we
could no longer fetch the package handle for packages without
metadata.
Fix by only deleting metadata for the packages that the file being
changed belongs to. It doesn't seem like a package's metadata contains
anything that is sensitive to changes in the package's dependencies.
Change-Id: I6a2d5df49ecd4d627b37689e48ed48fe78ce658d
Reviewed-on: https://go-review.googlesource.com/c/tools/+/210458
Run-TryBot: Muir Manders <muir@mnd.rs>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This should provide simple name completions for comments
above exported variables.
Can be activated with `ctrl+space` within a comment.
Pretty new, so all help is welcome.
Fixes#34010
Change-Id: I1c8f71baa3beaa22ec5fd9fd4a531284a8d125f3
GitHub-Last-Rev: a9868eb69dc587cb4579268b2c3ae46932702641
GitHub-Pull-Request: golang/tools#166
Reviewed-on: https://go-review.googlesource.com/c/tools/+/197879
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
