CL 239754 eagerly initialized the environment. This turns out to be a
problem for gopls, which calls ApplyFixes with no ProcessEnv.
Reinitializing it every time seriously harmed the performance of
unimported completions. Move back to lazy initialization.
Working with invalid options has caused a lot of confusion; this is only
the most recent. We have to maintain backwards compatibility in the
externally visible API, but everywhere else we can require fully
populated options. That includes the source byte slice and the options.
LocalPrefix is really more of an Option than an attribute of the
ProcessEnv, and it is needed in ApplyFixes where we really don't want to
have to pass a ProcessEnv. Move it up to Options.
Change-Id: Ib9466c375a640a521721da4587091bf93bbdaa3c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/241159
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This CL got away from me a little.
For a number of reasons, the existing goimports API of passing in values
for various GO* values was not working. For one, the number of necessary
variables kept growing. For another, we tried to avoid calling `go env`
in GOPATH mode by using `build.Default`, but that turns out to be buggy;
see golang/go#39838. And finally, it created massive confusion about
whether the values were intended to be read from the OS environment, or
fully evaluated by the `go` command.
There are only two users of the internal imports API, so there really
shouldn't need to be more than two modes. For the command line tool, we
have to call `go env` to deal with the `go/build` bug. So we just do it.
Tests use that same path, but can augment the enviroment to set
themselves up. In contrast, `gopls` needs to fully specify the
environment. It can simply pass in the fully evaluated GO* values.
Finally, make the change I was actually here to make: propagate
GOMODCACHE and use it where appropriate.
Fixesgolang/go#39761.
Change-Id: I720c69839d91d66d98e94dfc5f065ba0279c5542
Reviewed-on: https://go-review.googlesource.com/c/tools/+/239754
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
In all cases, use a Logf field to configure debug logging. Non-nil means
that logging is enabled through the given function.
Fixes accidental debug spam from goimports, which had a separate Debug
flag that was supposed to guard logging, but wasn't used when creating
the gocommand.Invocation.
Change-Id: I448fa282111db556ac2e49801268d0affc19ae30
Reviewed-on: https://go-review.googlesource.com/c/tools/+/221557
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
goimports now wants various module flags, but I forgot to set them up in
the many places we create environments. Do so.
Change-Id: Ic3817caeb8fc4d564b49006ef6ca6842b2498eaf
Reviewed-on: https://go-review.googlesource.com/c/tools/+/211581
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
For various reasons we need an internal-facing imports API. Move imports
to internal/imports, leaving behind a small wrapper package. The wrapper
package captures the globals at time of call into the options struct.
Also converts the last goimports tests to use the test helpers, and
fixes go/packages in module mode to work with empty modules, which was
necessary to get those last tests converted.
Change-Id: Ib1212c67908741a1800b992ef1935d563c6ade32
Reviewed-on: https://go-review.googlesource.com/c/tools/+/175437
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Amends prematurely submitted CL 173918. We now use file:/// URLs for
go1.13 and later and file:// URLs for go1.12 and earlier.
Fixesgolang/go#31675
Change-Id: I009c63a900bdfd091bf46def5cea5a0843639b47
Reviewed-on: https://go-review.googlesource.com/c/tools/+/173919
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
goimports will add an import for the package of target source file accidentally,
so check if package path is different from target source file when finding import candidates.
Fixesgolang/go#30663
Change-Id: I77c29bc74bef6c888e63ccb501b013a5fbc30b5c
Reviewed-on: https://go-review.googlesource.com/c/tools/+/170238
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The syscall/js API is not included in the GOROOT/api/go1.*.txt files
at this time, and so it needs to be added to mkstdlib.go explicitly.
Run the cmd/api command directly in the generator to determine the
syscall/js API.
Regenerate zstdlib.go with the updated generator, using Go 1.12.1.
Fixesgolang/go#27590
Change-Id: I541588986d70f67f4917d9b34bdd57ca44f538f7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/170014
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
If GO111MODULE=on but there's no go.mod, GOMOD will be set to /dev/null
or NUL and there will be no main module. goimports should handle this
case roughly the same way the go command does.
Fixesgolang/go#30855
Change-Id: I6fbf4c056000db5abd8788a6014ae5f13b1c8cd4
Reviewed-on: https://go-review.googlesource.com/c/tools/+/167860
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
A package name cannot contain a '.' anyway, so this is a mostly likely
internal package name in the presence of a '.' in the import path.
This stops goimports from adding a local alias in places where it is not
needed, for instance in gopkg.in conventions.
Fixesgolang/go#29556
Change-Id: I0ab11f2852d7f1dae14457995692760077201c8e
Reviewed-on: https://go-review.googlesource.com/c/157357
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
It was originally added to support goimports, but goimports
is going with another solution. We're going to disable it for
now, but not delete it, so that the goimports code path that
uses it can continue to be tested if and when we want to
use it.
We don't think there are any other users of name= but if
there are, please let us know and we'll work with you to
fix you, or we'll stop or revert this change. Thanks!
Change-Id: I73b7b6c0a5788148af5f3380189055b450f7b45e
Reviewed-on: https://go-review.googlesource.com/c/159702
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
go/packages needs to call `go list` multiple times, which causes
redundant work and slows down goimports. If we reimplement `go list` in
memory, we can reuse state, saving time. `go list` also does work we
don't really need, like adding stuff to go.mod, and skipping that saves
more time.
We start with `go list -m`, which does MVS and such. The remaining work
is mostly mapping import paths and directories through the in-scope
modules to make sure we're giving the right answers. Unfortunately this
is quite subtle, and I don't know where all the traps are. I did my
best.
cmd/go already has tests for `go list`, of course, and packagestest is
not well suited to tests of this complexity. So I ripped off the script
tests in cmd/go that seemed relevant and made sure that our logic
returns the right stuff in each case. I'm sure that there are more cases
to cover, but this hit all the stuff I knew about and quite a bit I
didn't.
Since we may want to use the go/packages code path in the future, e.g.
for Bazel, I left that in place. It won't be used unless the magic env
var is set.
Files in internal and imports/testdata/mod were copied verbatim from
cmd/go.
Change-Id: I1248d99c400c1a0c7ef180d4460b9b8a3db0246b
Reviewed-on: https://go-review.googlesource.com/c/158097
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
The imports package's public API is build.Default, but that doesn't mean
we need to use it in the internal implementation or the tests. Now we
have a new type, fixEnv, that contains everything relevant from
build.Context, as well as the various global vars that were only used
for testing.
Don't worry too much about the new function parameters; they mostly
move into the resolvers in the next CL.
Refactoring only; no user-visible changes intended.
Change-Id: I0d4c904955c5854dcdf904009cb3413c734baf88
Reviewed-on: https://go-review.googlesource.com/c/158437
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Before this change, we guessed package names during loadPackageNames
when necessary. That made it impossible to tell if we failed to load
a package's name, e.g. because its source code is unavailable. That
interferes with fixes for golang/go#29557. It also meant that each
implementation of package name loading needs to do the guessing,
which gets annoying in CL 158097.
Instead, leave package names unset unless we're certain about them, and
guess only in (*pass).importIdentifier when necessary.
Refactoring only; no user-visible changes intended.
Change-Id: Ia6072ada823e6e3a86981ad90228f30baa2ac708
Reviewed-on: https://go-review.googlesource.com/c/158199
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Fix a pair of bugs that combined to cause golang/go#29520. First, don't go
looking for a package if we've only seen unexported identifiers selected
from it. It's probably a typo. Second, don't find packages with no files
in them, e.g. because they're all build tagged out. We can't know what
package they form, so we have no business considering them.
Test only for the first, since without the first bug the second has no
observable effect on behavior, and I don't want to test the private API.
Fixesgolang/go#29520
Change-Id: I5b797940bec051be5945b9c5cb4e7bf28527a939
Reviewed-on: https://go-review.googlesource.com/c/156178
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Since we don't really need type info, and want everything to be fast,
use LoadFiles and do parsing manually. It would be nice if there were a
mode for that.
Change-Id: I33f8a85ffb87a70048c4775058bd0813cf677061
Reviewed-on: https://go-review.googlesource.com/c/155478
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
When a package contains both a var and an import that produce the same
identifier, the compiler will complain. I had thought that it made sense
to remove the redundant imports in that case. However, we can't reliably
tell whether a global from one file is in scope in another file. Most
notably, having multiple main packages in the same directory is pretty
common, and if someone declares a var in one that matches an import in
another, we don't want to remove the import.
Change-Id: I49f58fccdb8a8542ec85cf4d80d3e20d3159d2c7
Reviewed-on: https://go-review.googlesource.com/c/154740
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
When in module mode (go env GOMOD is nonempty), use go/packages to load
package information. This adds module support, without slowing down
non-module mode. Functionality should be the same in both cases.
Since we intend to use go/packages for everything eventually, the tests
run in three modes: GOPATH, using the old code paths; GOPATH_GoPackages,
using go/packages on a GOPATH layout; and Modules, using go/packages on
a module layout. They do take a little while to run.
The code path for go/packages is a lot more convoluted than it should be,
since it mixes in and out of the older path. I expect we'll clean that
up after deleting the old one.
Change-Id: I5b54bd470e091e6fb429597dfbfd1c8fa03f5b59
Reviewed-on: https://go-review.googlesource.com/c/152317
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
This is the fix I should have made in CL 153440. What I get for being in
a rush.
Fixesgolang/go#29180
Change-Id: I7ee3e26173b86c70574b9710f84094e46db27a37
Reviewed-on: https://go-review.googlesource.com/c/153859
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Fix some logic errors around renamed sibling imports. The one in
findMissingImport was just a silly mistake, the one in addCandidate
was because I hadn't thought about renamed imports.
Change-Id: Iecd0b4e6151bff7b8cb6ad21065f017fb1245bfd
Reviewed-on: https://go-review.googlesource.com/c/153440
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
imports exposes a few function vars that can be overridden to customize
its behavior. Now that the pass type exists, it should be easier to use
that as a rough API, rather than replacing functions piecemeal.
Remove all the existing hooks and just allow for fixImports to be
overridden entirely.
Change-Id: I8400eb64dab7b7b1bfa0b85fe2599df5780ddf37
Reviewed-on: https://go-review.googlesource.com/c/153437
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Some people put multiple packages' files in the same directory, most
commonly commands and code generators. Global variables from one package
should be ignored in other packages.
Change-Id: I9a5d27778570183dfe391dd3273dfa8277a29bf2
Reviewed-on: https://go-review.googlesource.com/c/153419
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For clarity and performance reasons, we want the fast path of goimports
to be purely syntactic. Packages whose import paths don't match their
package names make this harder. Before this CL, we parsed each imported
package to get its real package name. Now, we make named imports for
such packages, and on subsequent runs we don't have to do the extra
work.
A package name matches its import path if the name is the last segment
of the path, or the next-to-last before a version suffix vNN. gopkg.in
style .vNN suffixes are considered mismatching.
The previous attempt (CL 145699) failed because I assumed we'd be able
to find all packages from scratch. That's not true if the import path is
completely unrelated to the package name. To avoid that problem, rather
than removing and re-adding mismatched imports, we just literally add
names to them.
Fixesgolang/go#28428
Change-Id: I93bd820f5956162ae9c99afa73bdcfc570a2e7b4
Reviewed-on: https://go-review.googlesource.com/c/152000
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Redesign fixImports to have a clearer workflow, and hopefully create
clear places to plug in go/packages. This change is mostly
performance/functionality neutral, but does clean up some corner cases.
The new flow centers around the pass type, which encapsulates the
process of loading information about the current code, adding possible
new imports, and trying to apply them. I'm hoping that it's easy to
understand what's happening just by reading fixImports, and that new
sources of information (e.g. a network service) fit well into that flow.
Where possible, I left the functions near where they were extracted in
hopes of making review easier, but it's probably not going to be easy.
Sorry. I might move them into a more reasonable order in a followup CL.
Notable modifications:
- The stdlib cache is restructured to match pass' internal storage.
- Sibling imports with conflicting names are considered.
- Package name lookups are batched, hopefully making it easier to plug
in go/packages.
Questions that might be worth answering:
- Should findImportGoPath really scan $GOROOT? Unless the user is working
on a development copy, it's totally redundant with the cache.
- What is the best way to combine candidates from multiple sources?
Right now the first one wins, and findStdlibCandidates relies on that
to get crypto/rand ahead of math/rand.
- In the third pass, should it assume sibling imports or should it
actually go load the exports? It didn't load them before, but that seems
arbitrary.
Change-Id: Ie4ad0b69bfbe9b16883f2b0517b1278575c9f540
Reviewed-on: https://go-review.googlesource.com/c/150339
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This reverts CL 145699 (commit 864069cfd1)
Reason for revert: If the mismatch is bad enough that goimports can't find
it again, then the import is just removed, even if the user adds it back again.
Fixes#28645.
Change-Id: I6c8fc5434c2b56c73b260bcec2c12d8746fac4ad
Reviewed-on: https://go-review.googlesource.com/c/148237
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
For clarity and performance reasons, we want the fast path of goimports
to be purely syntactic. Packages whose import paths don't match their
package names make this harder. Before this CL, we parsed each imported
package to get its real package name. Now, we make named imports for
such packages, and on subsequent runs we don't have to do the extra
work.
A package name matches its import path if the name is the last segment
of the path, or the next-to-last before a version suffix vNN. gopkg.in
style .vNN suffixes are considered mismatching.
goimports already had almost exactly the desired logic, but only when
adding a new import. So the bulk of this change is simply removing the
logic that allowed it to recognize that a mismatched import satisfied
some uses. With that gone, it will remove those imports as unused, then
add a new renamed import. Some comments may be destroyed.
Fixesgolang/go#28428
Change-Id: I53846e6046affb420f41719f84c71086c5b9e5e6
Reviewed-on: https://go-review.googlesource.com/c/145699
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Tweak the goimports tests to be more module-compatible. This should be
the last big change to the tests; they all pass with the new
implementation.
The primary change is to avoid using packages not provided by the test's
modules. Other modules will be downloaded at test time, which is
nonhermetic and quite slow.
Other miscellanea:
- The appengine grouping tests have to be split out so
they can be GOPATH-only, because modules have to have dots in their
names.
- The tests for .goimportsignore and node_modules are GOPATH-only
because we decided not to include those behaviors in go/packages in
module mode.
- Some vendoring tests are GOPATH-only because vendoring is not a thing
in module mode.
- TestFindImportInLocalGoFiles changes content, because the existing
test was incorrect: bogus.net/bytes was a viable candidate even though
it isn't on disk. I'm not sure why it wasn't flaky.
Change-Id: I35a3aac92d3fb7f70a1a8f027f0b423282420a4d
Reviewed-on: https://go-review.googlesource.com/c/145138
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
I tried to introduce new modules where it made sense. I deleted the
weird goroot test because I removed the optimization it was testing in
an earlier CL.
Change-Id: I219ddaa4f462a4aeb640f62215d16f246511a5fe
Reviewed-on: https://go-review.googlesource.com/c/144497
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Add an implementation of name= for go list. It will be used to
implement goimports and godoc-like lookups by package name.
Imported a copy of the semver package from the stdlib to do version
comparison, and tweaked the gopathwalk API to include a hint about what
kind of source directory is being traversed.
Note that the tests, despite my best efforts, are not hermetic: go list
insists on doing version lookups in situations where it seems to me like
it shouldn't need to.
I think this implementation is ready for serious use. The one thing I'm
nervous about is that it currently does a substring match when looking
for a package name, so if you look up a package named "a" you will get
a huge number of results. This matches goimports' behavior but I don't
know if it's suitable for general use.
Change-Id: I2b7f823b74571fe30d3bd9c7dfafb4e6a40df5d3
Reviewed-on: https://go-review.googlesource.com/c/138878
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Replace the repeated Process/err check/output block with a test helper
eliminating a lot of copy/pasting. Change many tests to get their input
from disk rather than the argument to Process; this is mostly me being
selfish: go/packages doesn't support creating new packages with overlays
and that breaks a lot of these tests.
Change-Id: Ib1b7908c3d86d17323a94f1ee4ce074e264327b4
Reviewed-on: https://go-review.googlesource.com/c/141680
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We plan to change goimports to use go/packages, which requires changing
its internal design. Having tests use the external interface makes those
changes easier. After this change almost all testing is through Process.
Broadly speaking, the changes are:
- Switch to subtests wherever possible. This involved making up many
names, which I hope are accurate.
- Convert tests that used findImport directly to use Process instead.
This often made them slightly larger but not unduly IMO.
- Replace simple tests with entries in the giant table at the top.
- Remove uses of custom goroots, which are troublesome for
go/packages' use of the go command. Almost none of them were actually
necessary. I left one in TestGoRootPrefixOfGoPath; I'm not sure how
to handle it yet.
Change-Id: I7b810750f72842b58223f102097ccbb51b82bf39
Reviewed-on: https://go-review.googlesource.com/c/140840
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Extract goimports' logic for walking Go source directories into a
separate package, suitable for use in go/packages. No functional
changes. Added a convenience feature to fastwalk, allowing the user to
say that they're done with a directory and stop receiving callbacks for
it.
Testing is a little light; I expect goimports' tests to cover most
everything we care about.
Change-Id: If047ada4414f5f282637d11fd07e8342fadc9c33
Reviewed-on: https://go-review.googlesource.com/c/138877
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We plan to reuse goimports' directory walking logic in the
implementation of go/packages. To prepare for that, refactor it to have
fewer global variables and a simpler interface.
This CL makes no functional changes, but may change performance
slightly. It always scans both $GOPATH and $GOROOT, and does so
serially. I expect that fastwalk's internal parallelism is enough to
keep the disk busy, and I don't think it's worth optimizing for people
hacking on Go itself.
Change-Id: Id797e1b8e31d52e2eae07b42761ac136689cec32
Reviewed-on: https://go-review.googlesource.com/c/135678
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The existing implementation detects import groups and tryies to
sort/regroup only the last one. Ignore existing grouping and
applying the sort function to all imports fix this.
Fixesgolang/go#20818
Change-Id: I5db46c6dc8fabd9299b79349880994be5c1b8195
Reviewed-on: https://go-review.googlesource.com/c/116795
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Go 1.11 has been released; it's time to update zstdlib so
imports knows about API additions that went into Go 1.11.
Unfortunately, this does not include the syscall/js package
that was added in Go 1.11 for WebAssembly. This is because
it's not included in the GOROOT/api/go1.11.txt file. Getting
it into imports can/will be done in a future CL (after some
discussion of the best way to do it).
Previously:
- https://golang.org/cl/93195 (Go 1.10)
- https://golang.org/cl/49150 (Go 1.9)
Updates golang/go#27590.
Change-Id: I229d7c0a658b0d8090b58cfe844c95b4cb0b2212
Reviewed-on: https://go-review.googlesource.com/134176
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This reformats the table using the new gofmt rules in Go 1.11. No
changes apart from the whitespace change.
Change-Id: I74a1d9c14ec7a4f691e78cc7ffa443da68fb8681
Reviewed-on: https://go-review.googlesource.com/132395
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Run-TryBot: Andrew Bonventre <andybons@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
TestFixImports did not have to explicitly add "strings" to the
simplePkgs map - this only happened because sibling files were searched
and the strings import was found through them. If we stub out the
dirPackageInfo function, we have to explicitly add the strings import.
Change-Id: I149e522fad37039fc790e6a855834d86ff050674
Reviewed-on: https://go-review.googlesource.com/129036
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
The fix in golang/go#23709 introduced a separate bug where extra blank
lines were sometimes inserted. This fixes that newly introduced bug.
Fixesgolang/go#26246
Change-Id: I78131cc1d01ae246922ed9e4336ebb31d1c6cfa1
Reviewed-on: https://go-review.googlesource.com/122538
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This will be true in general for Go modules, so it's the right fallback.
Note that if the package can be found in GOPATH, the code still
uses the actual package name from GOPATH, so this only changes
the fallback path. The fallback path is what currently executes
when using modules (because they are not in GOPATH).
Change-Id: I3d48517583eae9431e139371d363ce354c89340a
Reviewed-on: https://go-review.googlesource.com/122616
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The current implementation uses the added import specs EndPos to fixup
the comments position after import specs is sorted. If two or more
import specs have the same EndPos, a comment associated with one of them
is always added to the last import spec.
This commit uses the current import spec position to compute new
position for next import spec. So there is never two or more specs have
the same EndPos.
Fixesgolang/go#23709
Change-Id: I60ace9431d871e94a2b3d90892aa80d0671aeea0
Reviewed-on: https://go-review.googlesource.com/121878
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
These are both vgo module cache locations (originally v, soon to be mod).
Vgo dumps a lot of code into these directories.
If goimports walks in there, it takes forever.
Change-Id: I667b0a4979bf6a6b71c3651d25ec29777ff15301
Reviewed-on: https://go-review.googlesource.com/119337
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Before this change, findImportGoPath used a field within the
(otherwise read-only) structs in the dirScan map to cache the distance
from the importing package to the candidate package to be imported. As
a result, the top-level imports.Process function was not safe to call
concurrently: one goroutine could overwrite the distances while
another was attempting to sort by them. Furthermore, there were some
internal write-after-write races (writing the same cached distance to
the same address) that otherwise violate the Go memory model.
This change fixes those races, simplifies the concurrency patterns,
and clarifies goroutine lifetimes. The functions in the imports
package now wait for the goroutines they spawn to finish before
returning, eliminating the need for an awkward test-only mutex that
could otherwise mask real races in the production code paths.
See also:
https://golang.org/wiki/CodeReviewComments#goroutine-lifetimeshttps://golang.org/wiki/CodeReviewComments#synchronous-functionsFixesgolang/go#25030.
Change-Id: I8fec735e0d4ff7abab406dea9d0c11d1bd93d775
Reviewed-on: https://go-review.googlesource.com/109156
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
