Look in all packages the snapshot knows of (through a new method on snapshot called
KnownPackages) and see if any of those packages contain implementations. Before,
the Implementation call only looked in the current package.
Much of the new complexity in implementation.go is routing through the Type to
Package data in the implementsResult.pkg field so the identifier can be looked up
in its correct package.
Fixesgolang/go#32973
Change-Id: Ifa7115b300f52fb4fb55cc00db2e7f339e8c2582
Reviewed-on: https://go-review.googlesource.com/c/tools/+/206518
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
It uses it to update the config of all active views cleanly
Fixesgolang/go#32258
Change-Id: I7a849941d5022499d48ad640c5b7bc9cf79eb9b9
Reviewed-on: https://go-review.googlesource.com/c/tools/+/206148
Run-TryBot: Ian Cottrell <iancottrell@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
It attempts to detect changes that would invalidate the view and replace itself
with a new view when that happens
Change-Id: I0f1a8cd3bd6ddcef115fedc6c57ae0398b16d3b6
Reviewed-on: https://go-review.googlesource.com/c/tools/+/206147
Run-TryBot: Ian Cottrell <iancottrell@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This change adds command line support for foldingRange.
Provided with a file, it will display a list of folding
ranges within that file, with 1-indexed positions using
the format
{startingLine}:{startingChar}-{endingLine}:{endingChar}
Example:
$ gopls folding_ranges ~/tmp/foo/main.go
$
$ 3:9-6:0
$ 10:22-11:32
$ 12:10-12:9
$ 12:20-30:0
Updates golang/go#32875
Change-Id: Ib35cf26088736e7c35612d783c80be7ae41b6a70
Reviewed-on: https://go-review.googlesource.com/c/tools/+/206158
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
We don't want to return an error for the whole package when we are just
building out error positions.
Change-Id: I56b5b88ff2b4b44da8a372ade81cd9b1534235c4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/206597
Reviewed-by: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
Even if the packages.Load of the directory the NewView is being created for
fails, create and add the view. But also return the error from NewView, just
after the new view has been added.
Fixesgolang/go#35468
Change-Id: I76c2d3cbe1a508ad0794a6fcd3bc67cd48c97e22
Reviewed-on: https://go-review.googlesource.com/c/tools/+/206497
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This change copies the code in guru's implements implementation
that finds implementations of methods over to gopls, and uses
the information determined to resolve implements requests on
methods. Implements still only works only within packages.
Updates golang/go#32973
Change-Id: I0bd7849a9224fbef7ab8385070b18fbb30703e2b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/206150
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Change tsprotocol.go so that the types are in alphabetical order, which
will make it simpler to see what has changed. (In this version only the
git hash and date have changed. The Go code has only been rearranged.)
The typescript code with this tiny change will be submitted in
another CL.
Change-Id: I7055b31075c7b3cda6e23b467205683423529c33
Reviewed-on: https://go-review.googlesource.com/c/tools/+/205499
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Add a special case for append() arguments so we infer the expected
type from the append() context. For example:
var foo []int
foo = append(<>)
We now infer the expected type at <> to be []int. We also support the
variadicity of append().
Change-Id: Ie0ef0007907fcb7992f9697cb90970ce4d9a66b8
Reviewed-on: https://go-review.googlesource.com/c/tools/+/205606
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
I assumed that f.Pos() would be the first byte of the file, but it's the
position of the package declaration. This kills the file. Just use 0.
Fixesgolang/go#35458.
Change-Id: Ic77c93344c71435ef8e5624c2f2defb619139a15
Reviewed-on: https://go-review.googlesource.com/c/tools/+/206145
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Treat it as okay if no packages are found when loading all the packages in a
workspace. Users may open workspaces that don't have any Go files, either because
they are workspaces for other languages, or because no Go files have been created
yet.
Fixesgolang/go#35455
Change-Id: I60912472ec8930649996edc150d1d19cd74a0a2e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/206140
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Previously, if we failed to find an item's documentation, we would not
return the item at all. It seems better to do a best-effort approach,
i.e. return the item without documentation.
Fixesgolang/go#35406
Change-Id: I896ffda2fc79b9210f0d83311808114d0e686820
Reviewed-on: https://go-review.googlesource.com/c/tools/+/205862
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Add a source.Scope type that can be used to refer to directories or
files, and modify (*snapshot).load to take source.Scope.
Then call load in NewView.
Change-Id: I8f03c7b271d700b162100d2890d23219ef9578c2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/204822
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
We want people to add imports as they need them. That means we probably
don't want adding an import to reformat your whole file while you're in
the middle of editing it.
Unfortunately, the AST package doesn't offer any help with this --
there's no good way to get a diff out of it. Instead, we apply the
changes, then diff a subset of the file. Picking that subset is tricky,
see the code for details.
Also delete a dead function, Imports, which should have been unused but
was still being called in tests.
Fixesgolang/go#30843.
Change-Id: I09a5344e910f65510003c4006ea5b11657922315
Reviewed-on: https://go-review.googlesource.com/c/tools/+/205678
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Previously we were erroneously suggesting a "func() {}" literal in
cases like:
http.Handle("/", <>)
This was happening because saw that the http.HandlerFunc type
satisfied the http.Handler interface, and that http.HandlerFunc is a
function type. However, of course, you can't pass a function literal
to http.Handle().
Make a few tweaks to address the problem:
1. Don't suggest literal "func () {}" candidates if the expected type
is an interface type.
2. Suggest named function types that implement an interface. This
causes us to suggest "http.HandlerFunc()" in the above example.
3. Suggest a func literal candidate inside named function type
conversions. This will suggest "func() {}" when completing
"http.HandlerFunc(<>)".
This way the false positive func literal is gone, and you still get
literal candidates that help you use an http.HandlerFunc as an
http.Handler. Note that this particular example is not very compelling
in light of http.HandleFunc() which can take a func literal directly,
but such a convenience function may not exist in other analogous
situations.
Change-Id: Ia68097b9a5b8351921349340d18acd8876554691
Reviewed-on: https://go-review.googlesource.com/c/tools/+/205137
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Improve candidate ranking when completing the variadic parameter of
function calls.
Using the example:
func foo(strs ...string) {}
- When completing foo(<>), we prefer candidates of type []string or
string (previously we only preferred []string).
- When completing foo("hi", <>), we prefer candidates of type
string (previously we preferred []string).
- When completing foo(<>), we use a snippet to add on the "..."
automatically to candidates of type []string.
I also fixed completion tests to work properly when you have multiple
notes referring to the same position. For example:
foo() //@rank(")", a, b),rank(")", a, c)
Previously the second "rank" was silently overwriting the first
because they both refer to the same ")".
Fixesgolang/go#34334.
Change-Id: I4f64be44a4ccbb533fb7682738c759cbca3a93cd
Reviewed-on: https://go-review.googlesource.com/c/tools/+/205117
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In CL 205501 I thoughtlessly set import name to package name, but really
we only want to name imports when goimports would do it. For now, it's
better to not name them and let the usual imports code add a name if
necessary.
Fixesgolang/go#35397.
Change-Id: Id0df866f95e5e86ed72b25fbd1a7224c79ee8084
Reviewed-on: https://go-review.googlesource.com/c/tools/+/205657
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Add a new "verboseOutput" config flag (defaults to "false") to enable
verbose go/packages and imports output. Previously this output was
always present.
The go/packages output would dump out the entire (humongous) "go list"
JSON response which would lock up my editor for a second whenever
something triggered a go/packages call.
The imports output would produce a bunch of "gopathwalk" debug
messages that aren't useful in general and in particular add noisy
output to tests.
Change-Id: Ie4693d074cb84f1397e0e51d7346dc9391bd1278
Reviewed-on: https://go-review.googlesource.com/c/tools/+/205138
Reviewed-by: Koichi Shiraishi <zchee.io@gmail.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Unimported completions now try to pull Packages from everywhere, not
just the transitive dependencies of the current package. That confused
the import formatting code, which only looked at deps. Pass the Package
along with the import suggestion, and use it when it's present.
Also change some error messages to be different for diagnostic purposes.
Fixesgolang/go#35359.
Change-Id: Ia8ca923e46723e855ddd2da7611e6eb13c02bb4f
Reviewed-on: https://go-review.googlesource.com/c/tools/+/205501
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
The special handler was dropped in cl/191963 which moved the logging functionality, but
was still needed for the rpc metrics
Change-Id: I494ef47646fe0d705709694378dbc981b549622a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/205164
Run-TryBot: Ian Cottrell <iancottrell@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
There was a dealock introduced in cl/190737 on all the internal structure
debug pages.
The object getters all protect with the mutex already, it should not also
be done in the outer Render function
Change-Id: I5c85dc8e2ec489e59ca5a80128f2649dd7753983
Reviewed-on: https://go-review.googlesource.com/c/tools/+/205165
Run-TryBot: Ian Cottrell <iancottrell@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Loading completion suggestions can be slow, especially in GOPATH mode
where basically anything can change at any time. As a compromise, cache
everything for 30 seconds. Specifically, after a completion operation
finishes, if the cache is more than 30 seconds old, refresh it
asynchronously. That keeps user-facing latency consistent, without
chewing up CPU when the editor isn't in use. It does mean that if you
walk away for an hour and come back, the first completion may be stale.
In module mode this is relatively benign. The only things the
longer caching affects are the main module and replace targets, and
relevant packages in those will generally be loaded by gopls, so they'll
have full, up-to-date type information regardless.
In GOPATH mode this may be more troublesome, since it affects
everything. In particular, go get -u of a package that isn't imported
yet won't be reflected until the cache period expires. I think that's a
rare enough case not to worry about.
Change-Id: Iaadfd0ff647cda2b1dcdead9254b5492b397e86e
Reviewed-on: https://go-review.googlesource.com/c/tools/+/205163
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Packages that aren't imported in the current file will often have been
used elsewhere, which means that gopls will have their type information
available. Expose loaded packages in the Snapshot, and try to use that
information when possible for unimported packages.
Change-Id: Icb672618a9f9ec31b9796f0c5da56ed3d2b38aa7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/204824
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
When a user completes rand.<>, propose rand.Seed (from math/rand) and
rand.Prime (from crypto/rand), etc.
Because we don't necessarily have type checking information for
unimported packages, I had to add shortcut cases to a number of
functions around the completion code. Better suggestions welcome.
Change-Id: I7822dc75c86b24156963e7bdd959443f4f2748b1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/204819
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Muir Manders <muir@mnd.rs>
The metadata was being added to the cache before it was fully computed.
Change-Id: I6931476a715f0383f7739fa4e950dcaa6cbec4fe
Reviewed-on: https://go-review.googlesource.com/c/tools/+/204562
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
This way, we can tell if someone is building gopls at head, or if they
are using a tagged version. We should only change the version string on
a release branch.
Change-Id: I55eba534baa2e171315fe72242a400e2d2794314
Reviewed-on: https://go-review.googlesource.com/c/tools/+/205159
Reviewed-by: Ian Cottrell <iancottrell@google.com>
A lot has changed since golang/go#32794 was filed, and we now have many more
tests for the command line.
Fixesgolang/go#32794
Change-Id: Ib268865a2345fd6676b2679bd76197c2d8658a85
Reviewed-on: https://go-review.googlesource.com/c/tools/+/204818
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Some analyses may panic, so we should be careful to recover.
Change-Id: Ie13df07aca1a21f4e6a66648cd4890b6a31966cc
Reviewed-on: https://go-review.googlesource.com/c/tools/+/204817
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
If the identifier doesn't have type info, don't try to access it.
Change-Id: I7e7c834c2863ec82a1269e60f7c50b0ce03f4692
Reviewed-on: https://go-review.googlesource.com/c/tools/+/204740
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change adds command line support for symbols.
Symbols are formatted as '{name} {type} {range}', with
children being preceded by a \t.
Example:
$ gopls symbols ~/tmp/foo/main.go
$
$ x Variable 7:5-7:6
$ y Constant 9:7-9:8
$ Quux Struct 29:6-29:10
$ Do Method 37:16-37:18
$ X Field 30:2-30:3
$ Y Field 30:5-30:6
Updates golang/go#32875
Change-Id: I1272fce733fb12b67e3d6fb948f5bf3de4ca2ca1
Reviewed-on: https://go-review.googlesource.com/c/tools/+/203609
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This adds support for calling links from the gopls command line,
e.g.
$ gopls links ~/tmp/foo/main.go
Optional arguments are:
-json, which emits range and uri in JSON
With no arguments, a unique list of links are emitted.
Updates golang/go#32875
Change-Id: I1e7cbf00a636c05ccf21bd544d9a5b7742d5d70b
GitHub-Last-Rev: 7ed1e4612186bce4077d3c73f2407cf6def211d9
GitHub-Pull-Request: golang/tools#181
Reviewed-on: https://go-review.googlesource.com/c/tools/+/203297
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The approach of using ASTs to determine error ranges had more
complications than I anticipated. Revert it for now to go back to the
old user experience, while we consider a better approach.
Change-Id: I5b23f0147c26089330f8a4bbf7b6914ae66cf59a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/204561
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
This change stops the memory leak from happening. It does not stop the
large number of allocations done by analysis, however, so these still
need to be prevented through correct cancellation.
Change-Id: I1cf7fbf6f85ed413af1f2ea55f91862a6d7f2db7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/204558
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
This change adds command line support for signatureHelp.
If the location provided corresponds to a function, that
function signature is displayed. In case that function is
documented the related comment is shown as well.
Example:
$ gopls signature ~/tmp/foo/main.go:7:5
$
$ Next(n int) []byte
$
$ Next returns a slice containing the next n bytes from
$ the buffer, advancing the buffer as if the bytes had been
$ returned by Read.
Note that linebreaks shown in the comment are just to adhere
commit message guidelines. The command prints documentation
comments on one line.
Updates golang/go#32875
Change-Id: Ib0dcc3267c594f95d80b74f289c1235c2c0c5f64
Reviewed-on: https://go-review.googlesource.com/c/tools/+/204057
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This adds support for the LSP implemention call, based
on the guru code for getting implementations. The guru code
did much more than we need, so some of the code has been
dropped, and other parts of it are ignored (for now).
Fixesgolang/go#32973
Change-Id: I1a24450e17d5364f25c4b4120be5320b13ac822b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/203918
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This adds support for calling suggestedfix from the gopls command line, e.g.
$ gopls suggestedfix ~/tmp/foo/main.go
Optional arguments are:
-w, which writes the changes back to the original file; and
-d, which prints a unified diff to stdout
With no arguments, the changed files are printed to stdout.
Wasn't sure if the command should be `suggestedfix` or just `fix` or `quickfix`?
Also this applies all changes to a file, does not allow for selective fixes.
Updates golang/go#32875
Change-Id: I8b75f9824be82974f6edb7c03383b4d56116943c
GitHub-Last-Rev: 070fcda33ac3494bfe8f19c2cd78c089c713ed98
GitHub-Pull-Request: golang/tools#174
Reviewed-on: https://go-review.googlesource.com/c/tools/+/202480
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
When proposing packages to import, we can propose more relevant packages
first. Introduce that concept to the pkg struct, and sort by it when
returning candidates.
In all cases we prefer stdlib packages first. Then, in module mode, we
prefer packages that are in the module's dependencies over those that
aren't. We could go further and prefer direct deps over indirect too,
but I didn't have the code for that handy.
I also changed the alphabetical sort from import path to package name,
because that's what the user sees first in the UI.
Updates golang/go#31906
Change-Id: Ia981ee9ffe3202e2a68eef3a36f65e81849a4ac2
Reviewed-on: https://go-review.googlesource.com/c/tools/+/204203
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
go/parser has switched from reporting no position for the end of a
broken file to reporting an invalid position. This broke on of our tests
that contains broken code. Change the test case as a result.
Change-Id: I4feb7790539994e593c56d5ae84929364c1eec1c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/204202
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
When our expected type is a named type from another package, we now always
search that other package for completion candidates, even if it is not currently
imported.
Consider the example:
-- foo.go --
import "context"
func doSomething(ctx context.Context) {}
-- bar.go--
doSomething(<>)
"bar.go" doesn't import "context" yet, so normally you need to first import
"context" through whatever means before you get completion items from "context".
Now we notice that the expected type's package hasn't been imported yet and give
deep completions from "context".
Another use case is with literal completions. Consider:
-- foo.go --
import "bytes"
func doSomething(buf *bytes.Buffer) {}
-- bar.go--
doSomething(<>)
Now you will get a literal completion for "&bytes.Buffer{}" in "bar.go" even
though it hasn't imported "bytes" yet.
I had to pipe the import info around a bunch of places so the import is added
automatically for deep completions and literal completions.
Change-Id: Ie86af2aa64ee235038957c1eecf042f7ec2b329b
Reviewed-on: https://go-review.googlesource.com/c/tools/+/201207
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Closing over the checkPackageHandle creates a cycle that forces the
checkPackageHandle not to be garbage collected until the value is
created. If a value is never created, the handle will not be collected.
Change-Id: I0f94557da917330ebe307a0e843b16ca7382e210
Reviewed-on: https://go-review.googlesource.com/c/tools/+/204079
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
This change encompasses the refactorings needed to correctly implement
CL 204079. The goal of this CL is to make the actual relevant diffs more
clear.
Change-Id: I38acfd436e2380be790910e01b6e37d8280e9100
Reviewed-on: https://go-review.googlesource.com/c/tools/+/204139
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
This adds support for calling import from the gopls command line,
e.g.
$ gopls imports -w ~/tmp/foo/main.go
Optional arguments are:
-w, which writes the changes back to the original file; and
-d, which prints a unified diff to stdout
With no arguments, the changed file is printed to stdout.
Updates golang/go#32875
Change-Id: I12f980d977fe12c16e51b024c9dd28c33ba6c002
GitHub-Last-Rev: c3fdd90e25204e7a12a94e9dfde389b7674e7e6d
GitHub-Pull-Request: golang/tools#176
Reviewed-on: https://go-review.googlesource.com/c/tools/+/202624
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This change eliminates the need for the importer struct. We should no
longer need the "seen" map for cycle detection. This is because
go/packages will not return import maps with cycles, and we fail in the
Import function if we see an import we do not recognize.
Change-Id: I06922c74e07eb47ce63b56fa2ac2099e7fc8bd8a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/202299
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
