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
