go vet detected that the value of pkgIndexOnce
is copied through assignments in the test.
This patch fixes that by converting it to *sync.Once instead.
Change-Id: I90b2252942625b2f8a93eb5da24d16c6a8a56e4e
Reviewed-on: https://go-review.googlesource.com/20910
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
These changes will need to be reverted once we use
vendoring in the stdlib again, but it's trivial to
do so when the time comes.
TBR=adonovan
Fixes#14823.
Change-Id: I2173c48d5466874492affc679332f6484bf96592
Reviewed-on: https://go-review.googlesource.com/20695
Reviewed-by: Robert Griesemer <gri@golang.org>
DeleteNamedImport deletes the import with a given
name and path from a parsed file, if present.
imports uses this function to delete named imports.
Fixesgolang/go#8149.
Change-Id: I84539d5627191c45f06db2d008507aee4d3b1eb2
Reviewed-on: https://go-review.googlesource.com/19951
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Editor modes that invoke the goimports command on temporary copies
of actual source files will need to invoke goimports -srcdir now to say
where the real source directory is. Otherwise goimports will not consider
vendored or internal packages when looking for new imports.
In lieu of a test for cmd/goimports (because it has no tests),
a command transcript:
$ cd /tmp
$ cat x.go
package p
var _ = hpack.HuffmanDecode
$
$ GOPATH= goimports < x.go
package p
var _ = hpack.HuffmanDecode
$ GOPATH= goimports x.go
package p
var _ = hpack.HuffmanDecode
$
But with the new flag:
$ GOPATH= goimports -srcdir $GOROOT/src/math < x.go
package p
import "golang.org/x/net/http2/hpack"
var _ = hpack.HuffmanDecode
$ GOPATH= goimports -srcdir $GOROOT/src/math x.go
package p
import "golang.org/x/net/http2/hpack"
var _ = hpack.HuffmanDecode
$
The tests in this CL and the above transcript assume that
$GOROOT/src/vendor/golang.org/x/net/http2/hpack exists.
It did in 40a26c9, but it does not today.
It will again soon (once Go 1.7 opens).
For golang/go#12278 (original request).
Change-Id: I27b136041f54edcde4bf474215b48ebb0417f34d
Reviewed-on: https://go-review.googlesource.com/17728
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
AddImport and AddNamedImport attempt to place new
imports in roughly the correct place--and thus the
correct group--by matching prefixes. Matching prefixes
byte-by-byte led to "regexp" being grouped with "rsc.io/p".
Instead, match prefixes by segments.
Fixesgolang/go#9961.
Change-Id: I52b7c58a9a2fbe85c2b5297e50c87d409364bda3
Reviewed-on: https://go-review.googlesource.com/8090
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Fixes 7866. Adds a test case.
When trying to add newlines before certain imports via text manipulation,
a regex is used to iterate over all imports. The regex failed to match
dot imports because \w doesn't match a literal dot. This changes the regex
to accept a dot as well.
LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/99400043
The issue occurs only when deleting an import that has a blank line immediately preceding,
and other imports before that.
Currently, DeleteImport assumes there's a blank line-sized hole left behind
where the import was, and always deletes it. That blank line-sized hole is there in all cases
except the above edge case.
This fix checks for that edge case, and does not remove the blank line-sized hole.
The CL also adds a previously failing test case that catches this scenario. After the change to
DeleteImport, the new test passes (along with all other tests).
Fixesgolang/go#7679.
Note that there is no attempt to ensure the result *ast.File and *token.FileSet are perfectly
matching to what you would get if you printed the AST and parsed it back. This is how the
rest of the package and the current tests work (i.e., they only check that printing the AST gives
the correct output).
Changing that is very hard, if not impossible, at least not
without resorting to manipulating AST via printing, text manipulation and parsing.
This is okay for most usages, but it does create potential problems. For example,
astutil.Imports() currently only works correctly on freshly parsed AST. If that AST
is manipulated via astutil funcs, then Imports() may not always generate correct
output. However, thas is a separate issue and should be treated as such.
LGTM=bradfitz
R=golang-codereviews, gobot, adonovan, bradfitz
CC=golang-codereviews
https://golang.org/cl/92250045
Assuming:
1) package declaration does not exist
2) the Fragment option is set
3) a main function exists
We will assume it is a main package and add the declaration.
This change also sets the Fragment option in goimports.
LGTM=crawshaw, bradfitz
R=bradfitz, crawshaw
CC=golang-codereviews
https://golang.org/cl/96850044
goimports to use the package name as a local qualifier in an import.
For example, if findImports("pkg", "X") returns ("foo/bar",
rename=true), then goimports adds the import line:
import pkg "foo/bar"
to satisfy uses of pkg.X in the file.
This change doesn't add any implementations of rename=true, though one
is sketched in a TODO.
LGTM=crawshaw
R=crawshaw, rsc
CC=bradfitz, golang-codereviews
https://golang.org/cl/76400050
Because goimports also sorts stdlib-vs-external differently
(whereas gofmt just sorts string-wise), we need to put a blank
line between imports of different classes. This happened in
some cases, but not all.
Fixesgolang/go#7132
LGTM=kamil.kisiel
R=golang-codereviews, kamil.kisiel
CC=golang-codereviews
https://golang.org/cl/60870047
Fast path for the common case. Avoids scanning GOPATH usually.
LGTM=r, crawshaw
R=david.crawshaw, adg, r, crawshaw
CC=golang-codereviews
https://golang.org/cl/56820043
