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>
Rename to avoid imports/import stutter and export.
It will be used soon by guru's referrers command.
This work supported by Sourcegraph.
Change-Id: Ibfc39d061d6269a336a59d9b6979188a94537d94
Reviewed-on: https://go-review.googlesource.com/108877
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
It is going to be used by a new tool.
Moved to an internal package so it does not become a publicly supported
api.
Modified the tests so they don't depend on the fix_test infrastructure.
Change-Id: Ib8ebef24dc23e180960af04aa3d06b5f41a7c02b
Reviewed-on: https://go-review.googlesource.com/99678
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The comment of Process() implies src can be nil, but it didn't handle
nil src correctly before because parse() doesn't expect nil src.
Passing []byte(nil) to parser.ParseFile() results in error and parse()
tries to parse again by modifying src if src is statement list.
This problem isn't related with cmd/goimports because goimports doesn't
pass []byte(nil) to Process() as src.
Fixesgolang/go#19676
Change-Id: Idbaa6646c3907690763eabc798860c56bb9963d4
Reviewed-on: https://go-review.googlesource.com/38613
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Make it so that import prefixes specified using the -local flag are considered
a match for an import path if the prefix ends with a '/' and the import path
matches exactly the prefix without a slash. For example, specifying
"golang.org/x/tools/" as a prefix would match the import for the package
"golang.org/x/tools".
Fixesgolang/go#24368
Change-Id: I0302db72fda63ad24d7b964aa73f78aa0ebccb37
Reviewed-on: https://go-review.googlesource.com/100460
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
If the test fails, it tries to print a million characters.
This limits it to just the start of got and want, which is enough to see
the imports block anyway.
Change-Id: I2c58db8e96e73da436ca16fa8a57c820a95242ca
Reviewed-on: https://go-review.googlesource.com/100216
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In cmd/goimports, allow for the -local flag to accept a comma-separated
list of import path prefixes. Also, update the imports package
accordingly to support this.
Fixesgolang/go#19188
Change-Id: I083d584df8c3a77532f0f66e9c5d970960180e0d
Reviewed-on: https://go-review.googlesource.com/85397
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In cmd/present, a mode was being passed to the function parse, but it
wasn't actually being used. Use it.
In go/ssa, checkFinalInstr received an idx integer but it doesn't
actually need it. Get rid of it.
Lastly, in imports, findImportStdlib always returned rename==false. Get
rid of that result parameter.
Change-Id: I719006b69ee80a3ef4b0ea24c1c206016a7e304b
Reviewed-on: https://go-review.googlesource.com/93596
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Previous work to resolvegolang/go#18201 increased the maximum line
length that goimports could handle to 1MiB (CL83800), but generated code
can result in Go files with longer lines. Use a bufio.Reader instead of
a bufio.Scanner to support arbitrarily long lines, as permitted by the
Go spec.
Change-Id: If719e531859804304d60a8c00db6304ab3d5fe5e
Reviewed-on: https://go-review.googlesource.com/93439
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
When selecting a sibling's import, the unresolved reference must have
been also used otherwise use the normal search to determine the best
possible package to import.
Fixesgolang/go#23001
Change-Id: I38a983569991464970ad5921fe7f280dd3e35a2c
Reviewed-on: https://go-review.googlesource.com/82875
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
This change set fixes the issue by specifying a max buffer size of ~1 megabyte for Scanner.
Previously the max was not set resulting in the default max which is ~64k. This increased max should not increase
memory use for smaller, normal files because it is a max and the code expands the buffer as needed for large tokens.
The change set includes an additional change to return an error from the Scanner which was ignored previously.
Fixesgolang/go#18201
Change-Id: I11be39af74d5eb3b353ad81ba1cb5404207aa65d
Reviewed-on: https://go-review.googlesource.com/83800
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The following tag
// +build linux,!appengine darwin
Translated to (linux AND !appengine) OR (darwin)
Causing issues on darwin when attempting to run dev_appserver.
Change this to always exclude these files from appengine builds.
Change-Id: Ifd63a884747001797d0b0e828f0c9c391bc7c73c
Reviewed-on: https://go-review.googlesource.com/60911
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>
Before this change, astutil would only do a prefix match of a new import
with all the existing ones, to try to place it in the correct group. If
none was found, the new import would be placed at the beginning of the
first import group.
This works well for new std imports, but it doesn't work well for new
third-party packages that don't share any prefix with any of the
existing imports.
Example:
import (
"time"
"github.com/golang/snappy"
)
When adding "golang.org/x/sys/unix" with astutil.AddImport, the import
is inserted as follows:
import (
"golang.org/x/sys/unix"
"time"
"github.com/golang/snappy"
)
And goimports reorganizes the imports to separate std and third-party
packages:
import (
"time"
"golang.org/x/sys/unix"
"github.com/golang/snappy"
)
We usually don't want to introduce a new import group; in most cases,
the desired behavior is separating std from third-party packages.
With this CL, new imports that don't share prefix with any existing ones
will be placed with the first group of third-party imports, if any
exist. If no third-party import group exists, a new one will be added.
In the case of our example above, this will be the new outcome:
import (
"time"
"github.com/golang/snappy"
"golang.org/x/sys/unix"
)
Fixesgolang/go#19190.
Change-Id: Id4630015c029bd815234a6c8726cb97f4af16f1c
Reviewed-on: https://go-review.googlesource.com/37552
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
The import path is ambiguous in the presence of vendoring (e.g. golang/go#20610)
Change-Id: I22f372b233b8554e3d9210b383a7df7a6a0f3eee
Reviewed-on: https://go-review.googlesource.com/53470
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We're at beta 2 already, so the API is likely stable.
If anything gets rolled back, we can update imports again.
Change-Id: I87e0adde062e45cab16e2bee2f929c1ac1bb828d
Reviewed-on: https://go-review.googlesource.com/49150
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Don't panic when reading from stdin on Windows. This is a regression
from https://golang.org/cl/43454
Also fix some weird behavior with stdin processing I noticed during
reviewing the code: don't allow the -w (write) flag, and adust the
filename shown with the -d (diff) flag.
Fixesgolang/go#20941
Change-Id: I73d0a1dc74c919238a3bb72823585bbf1b7daba1
Reviewed-on: https://go-review.googlesource.com/47810
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Jones <rbjones@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
golint suggested:
comment on exported var LocalPrefix should be of the form "LocalPrefix ..."
Change-Id: I1d2f92ba76e3c091440f676936dbb1fc1ce07f3a
Reviewed-on: https://go-review.googlesource.com/46432
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Adds an Imports field to packageInfo with the imports used by sibling
files, and uses it preferentially if it matches a missing import.
Example: if foo/foo.go imports "local/log", it's a reasonable assumption
that foo/bar.go will also want "local/log" instead of "log".
Change-Id: Ifb504ed5e00ff18459f19d8598cc2c94099ae563
Reviewed-on: https://go-review.googlesource.com/43454
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
In some cases walkFn is being called after the fastWalk function has
returned. This often happens when an error was encountered early on in
scanning directories with many entries.
It is caused by fastWalk not waiting for its workers to complete their
work. A sync.WaitGroup is used to wait for all workers to finish when
the function returns.
Updates golang/go#16399
Change-Id: I695d30c18e4878b789520b9d8a650f9688d896ac
Reviewed-on: https://go-review.googlesource.com/40092
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change the shouldTraverse function to no longer keep a global map of
which inodes it's seen. Instead, whenever a symlink is seen for a path
name, check every directory entry in that path name and see if any are
the same inode as the current one, detecting any loop just from the
name itself.
More details of why the test was flaky are in the bug.
Fixesgolang/go#18142
Change-Id: I869f7a13d130c63d78b7af81802a16c4b4b2f3bd
Reviewed-on: https://go-review.googlesource.com/37947
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change remove an unnecessary string conversion of
a variable that is already a string.
Change-Id: I64d9a6c059276fa22f1be9f2dba02bbeb63cb8fb
Reviewed-on: https://go-review.googlesource.com/35560
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL only copies files and updates build tags.
Substantive changes will come in follow-ups.
This is a workaround for git's lack of rename/copy tracking.
Tested with go1.6, go1.7, and tip (go1.8).
Change-Id: Id88a05273fb963586b228d5e5dfacab32133a960
Reviewed-on: https://go-review.googlesource.com/32630
Reviewed-by: Robert Griesemer <gri@golang.org>
