This happens whenever we load standard library information from export
data, and prevents the editor from understanding the file names
Change-Id: If5c04176a3e669ba396f322275993616e51ec097
Reviewed-on: https://go-review.googlesource.com/c/149612
Run-TryBot: Ian Cottrell <iancottrell@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
We use the custom marker support to allow us to simplify the
annotations, making it much easier to understand the tests.
Change-Id: Id818a286e4e85f48cfe505f14ec82a80498e494c
Reviewed-on: https://go-review.googlesource.com/c/149611
Run-TryBot: Ian Cottrell <iancottrell@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This exposes the ability to add markers to the public interface, and
changes the way markers are collected to make it so a standard call to
Expect can replicate the internal behaviour.
This allows custom rules to also add marks.
Also add a special EOF identifier that acts like a mark at the end of
the file in which it occurs.
Change-Id: Ic5e41cbc5b7ae3c4d1c5b8baba980147c1d22ef1
Reviewed-on: https://go-review.googlesource.com/c/149610
Run-TryBot: Ian Cottrell <iancottrell@google.com>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Delivering each message in a go routine turned out to be problematic, there are some messages
that must be fully processed before later messages are started, and there was no way to guarantee that.
We now push concurrence handling up to the higher level, this has the disadvantage of not being able to guarantee
we respond to call messages correctly, but its a small price to pay.
The LSP currently processes each message fully in order blocking the handler, while we still work on basic
functionality.
Change-Id: If0648c77713ddbe4fed69da97a57696f433b8002
Reviewed-on: https://go-review.googlesource.com/c/149497
Run-TryBot: Ian Cottrell <iancottrell@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This change causes singlechecker and multichecker to exit with the
correct error code: 0 for success, 1 for load/analysis and other
errors, 3 for diagnostics. (We avoid 2 because the flag package uses
it.)
In JSON mode, errors in package loading, parsing, typechecking and
analysis are successfully in JSON format, with exit code 0.
+ Test.
Change-Id: Iaf130ed3d4cb3e747a628af6da8dc97d065aa869
Reviewed-on: https://go-review.googlesource.com/c/149603
Run-TryBot: Alan Donovan <adonovan@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Type.String prints named types using the complete package path: "dir/pkg.T"
The notation used by canonicalMethod, and the cmd/vet/all whitelist,
and the one users want to see, uses only the package name: "pkg.T".
Change-Id: If2334a8cca1fb80e947cb105530b946a5a8dec7b
Reviewed-on: https://go-review.googlesource.com/c/149597
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Michael Matloob <matloob@golang.org>
Vet issues a warning (non-error diagnostic) when, for example, it
cannot check an assembly file because the Go and asm symbols are in
different packages. The new analysis API has no concept of warnings:
any diagnostic always causes a non-zero exit.
This change turns the asmdecl diagnostics back into warnings using
log.Print, which is not ideal, but is necessary to pacify cmd/vet/all
and its whitelist during the transition. Better solutions would be for
the new analysis API to have a concept of warning, or for asmdecl to
be silent and cmd/vet/all's whitelist not to expect these messages.
Also, fix a bug in the "cross-check" predicate: cmd/vet confuses the
name of a package and its path. The a∕b∕c names (using Unicode
division slash) that appear in assembly correspond directly to the
path.
The only effective test of this change will be cmd/vet/all itself.
Change-Id: I2e402d48717df723e2efdc2379636ec9b204031d
Reviewed-on: https://go-review.googlesource.com/c/149598
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Michael Matloob <matloob@golang.org>
Now that vet can rely on go/types, there's no reason to do extra work to
avoid using it. The rewrite lets us get rid of the field list flattening
code, as well as the slight verbosity that comes with go/printer.
While at it, make the testdata/method.go expected errors be more
specific, to make sure that we're not breaking the warnings that are
printed.
This change was originally made to cmd/vet in
https://go-review.googlesource.com/c/148919
Change-Id: I123e64d369e521199712c9807583c53d428534ac
Reviewed-on: https://go-review.googlesource.com/c/149418
Reviewed-by: Michael Matloob <matloob@golang.org>
Add SignatureHelp functionality to source package. Tests will be added
in a subsequent change.
Change-Id: Ia43280946d96a984c5741273a00c12255d637b2a
Reviewed-on: https://go-review.googlesource.com/c/149177
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Pointers to compound objects (structs, slices, arrays, maps) are only
followed by fmt if the pointer is at the top level of an argument. This
is to minimise the chances of fmt running into loops.
However, vet did not follow this rule. It likely doesn't help that fmt
does not document that restriction well, which is being tracked in
#28625.
This change was originally made to cmd/vet as
https://go-review.googlesource.com/c/147997.
Updates #27672.
Change-Id: I65944cf355baedb4578af57046e2bbfd3fe6a9dc
Reviewed-on: https://go-review.googlesource.com/c/149319
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Some of the Analyzers' names were changed during the refactoring.
These legacy flags ensure the old names continue to work.
Change-Id: I466aa38ec55071c944fb73571915aa7afb42dbc2
Reviewed-on: https://go-review.googlesource.com/c/149417
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
fmt's godoc reads:
For compound objects, the elements are printed using these
rules, recursively, laid out like this:
struct: {field0 field1 ...}
array, slice: [elem0 elem1 ...]
maps: map[key1:value1 key2:value2 ...]
pointer to above: &{}, &[], &map[]
That is, a pointer to a struct, array, slice, or map, can be correctly
printed by fmt if the type pointed to can be printed without issues.
vet was only following this rule for pointers to structs, omitting
arrays, slices, and maps. Fix that, and add tests for all the
combinations.
This change was originally made to cmd/vet in
https://go-review.googlesource.com/c/147758
Updates #27672.
Change-Id: I7e25ecaeed619ae8b6ada79bccacba6b67171733
Reviewed-on: https://go-review.googlesource.com/c/149318
Reviewed-by: Michael Matloob <matloob@golang.org>
Per discussion with Russ,
the -all/-source/-v flags now silently do nothing, and
the -printffuncs (et al) shims now silently delegate to -printf.funcs, and
the -NAME.enable (et al) flags are now called just -NAME.
Various minor tweaks to command-line help messages.
Change-Id: If6587937f58446e605eca4d3a5be0aaf6287065d
Reviewed-on: https://go-review.googlesource.com/c/148879
Reviewed-by: Russ Cox <rsc@golang.org>
x/tools only supports Go 1.10 and Go 1.11, but it's such a simple fix to
support 1.9, so change from strings.Builder to bytes.Buffer.
Change-Id: Ie37d6c7da7ce7dbbd4e9ec933e1eff3304142a59
Reviewed-on: https://go-review.googlesource.com/c/149178
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This is a workaround for a go list regression that broke
go/packages but went unnoticed by because of a missing
call to packages.PrintErrors, added here.
Updates golang/go#28749
Change-Id: I1819a6143134a422791106ac037d3458ef864322
Reviewed-on: https://go-review.googlesource.com/c/149237
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Until the index is read completely, search requests will serve
an "indexing in progress" message. We make this synchronous
to allow the index to be read completely before starting to serve
requests.
Fixesgolang/go#24965
Change-Id: I6b094374a9c5cc923f0582107dde2b652e64fd96
Reviewed-on: https://go-review.googlesource.com/c/148998
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This makes the format code use the AST that is already cached on the file to do
the formatting. It also moves the core format code into the source directory.
Change-Id: Iaa79169708e92525cce326ea094ab98144fe1011
Reviewed-on: https://go-review.googlesource.com/c/148198
Run-TryBot: Ian Cottrell <iancottrell@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Use the packagestest framework to test completion. Add support for a
slice of token.Position to packagestest to support this.
Change-Id: Ie5ddece4446a3c74419727461a77faa3788cb040
Reviewed-on: https://go-review.googlesource.com/c/148197
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
The fallback driver wasn't returning the roots in a
deterministic order because it was using sticking them in
a map and then iterating over that map to get each element.
Put them into a slice instead (and make a few small
associated changes) to preserve behavior.
Fixesgolang/go#28040Fixesgolang/go#28609
Change-Id: Ib8f8c88d65b7a48b2b04ca91e2d3c316d5bb5803
Reviewed-on: https://go-review.googlesource.com/c/148880
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This mainly entails writing compiler output files to a temporary
directory, as well as the corrupted files in TestVersionHandling.
This is a backport of CL 146119.
Fixesgolang/go#28644
Change-Id: I5701fe3fda7d6364411eef8265c575c279dbf9a1
Reviewed-on: https://go-review.googlesource.com/c/149017
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This change adds to the list of standard library functions known to be
print or printf wrappers.
Although the printf Analyzer is capable of identifying wrapper
functions in the standard library, some drivers (e.g. Bazel) do not
apply analyzers to the standard packages. Really this is a bug
in those drivers but it is not likely to be fixed for a while.
Change-Id: I2032d0cb5fcb50e7b9933a75809becdd680380ec
Reviewed-on: https://go-review.googlesource.com/c/148572
Run-TryBot: Alan Donovan <adonovan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Details:
- Add -source, -v, and -all flags to vet-lite.
These have no effect and issue a warning.
- Add usage message to vet-lite that lists all
analyzers and explains -foo.enable and other flags.
- Factor this help message (common to vet-lite and
multichecker) into analysisflags.
- Add legacy aliases of new flags.
e.g. -printfuncs is now -printf.funcs
The old names work but issue a warning when used.
Also: update comments to say -vettool not$GOVETTOOL
I think we should probably do away with singlechecker
in a follow-up: a singleton multichecker is good enough,
and will allow us to remove cases in the flag-processing
logic.
Change-Id: Ib62f16b5e2f4c382a29e6300a6246b2db9e08049
Reviewed-on: https://go-review.googlesource.com/c/148559
Reviewed-by: Michael Matloob <matloob@golang.org>
When main.main returns, the process exits, so there's no need to cancel contexts.
This CL was originally reviewed as
https://go-review.googlesource.com/c/go/+/106915
and then retried in
https://go-review.googlesource.com/c/go/+/148758
but then reverted due to an embarrassing sequence
of careless moves.
Change-Id: Icdee0650996a442023e030697f10d2c31fd5fdff
Reviewed-on: https://go-review.googlesource.com/c/148877
Run-TryBot: Alan Donovan <adonovan@google.com>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
This enables bundling of programs with `main` method to single file.
I used this to upload code for the new codejam.
Change-Id: I9e65ba8717c1d81d6fb9bef8f234c21fc5b91421
GitHub-Last-Rev: 5d0d623c46ff1629e7371693ddf0916df328e319
GitHub-Pull-Request: golang/tools#32
Reviewed-on: https://go-review.googlesource.com/c/105515
Reviewed-by: Alan Donovan <adonovan@google.com>
In vet, the shadow check is experimental, meaning not on by default.
The new analysis API has no concept of experimental, but you can
easily supply a different checker. By providing a shadow command, we
make it easy for users that want it to run it:
$ go install golang.org/x/tools/go/analysis/passes/shadow/cmd/shadow
$ go vet -vettool $(which shadow) my/project
Change-Id: I25dc7f3c830296121c7217e4615e8ff90e1b7c79
Reviewed-on: https://go-review.googlesource.com/c/148565
Reviewed-by: Michael Matloob <matloob@golang.org>
The printf checker is in the passes/ subdirectory.
Change-Id: I0a912231280bc954fee3088050541ba5ecb17dde
Reviewed-on: https://go-review.googlesource.com/c/148571
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
The cgocall analyzer was originally written in vet to analyze "raw" cgo files,
which are type-checked on a best-effort basis. However, the go/analysis
API presents analyzers with "cooked" cgo files, which are well-typed
legal Go but obscure the relationship between a call C.f(...) and its arguments.
Prior to this CL, cgocall attempted to "uncook" the file, which was
as predictably fragile as it sounds, and it rapidly broke as the cgo
recipe evolved.
This change causes cgocall to parse, modify, type-check and analyze "raw"
cgo files. The approach (based on dot-importing the "cooked" package)
is rather too clever but should be more robust than the one it replaces.
Fixesgolang/go#28566
Change-Id: I3092a313c64d27153eaaa115fe8635abfed17023
Reviewed-on: https://go-review.googlesource.com/c/147317
Reviewed-by: Michael Matloob <matloob@golang.org>
The completion function belongs in internal/lsp/source, so move it
there. Some small refactoring of completion, by moving each type of
completion into helper functions that append to the list of results.
Change-Id: I8599092906609591d499183657fe2d21d1f74df1
Reviewed-on: https://go-review.googlesource.com/c/148397
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
TryBot-Result: Gobot Gobot <gobot@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>
This change makes AddNamedImport more symmetrical to DeleteNamedImport
in behavior, signature, and documentation.
In Go, it is valid to import a package (identified by an import path)
with different names in a single .go file¹. For example, this is ok,
and the program will build as long as there are no unused imports²:
import (
"path"
. "path"
_ "path"
pathpkg "path"
)
The four imports (represented by ast.ImportSpec type) have the same
import path, but different names.
It's currently possible to use DeleteNamedImport to delete the exact
{name, import path} ast.ImportSpec from an AST.
Previously, it wasn't possible to use AddNamedImport to add an exact
{name, import path} ast.ImportSpec if the AST already has another
ast.ImportSpec with the same import path (but different name).
This change fixes that, making it possible to use AddNamedImport as
expected.
Rename the ipath parameter to path in AddNamedImport for consistency
with DeleteNamedImport. Also change the language used in its
documentation to be more precise and consistent with DeleteNamedImport.
Add test cases for this behavior. The DeleteNamedImport test cases
were passing before any changes to the astutil code.
Add test coverage for the return bool value of {Add,Delete}NamedImport.
Document the behavior of DeleteNamedImport when there are duplicate
matching imports.
Simplify string(buf.Bytes()) to buf.String() in test helper code.
¹ https://golang.org/ref/spec#Import_declarations
² https://play.golang.org/p/bi6L34rQbcDFixesgolang/go#28605Fixesgolang/go#16411
Change-Id: I70e887f5174764ab1cf32a761c8c734e216eea67
Reviewed-on: https://go-review.googlesource.com/c/147448
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
This will allow Sizes to be marshalled and unmarshalled. All the Sizes
we care about ane StdSizes anyways.
Change-Id: I79d1dcaebba32f7730de4375945e372eeefa78fe
Reviewed-on: https://go-review.googlesource.com/c/147978
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
go list in module mode doesn't like looking at vendor directories in
GOROOT. Skip them.
Change-Id: Iec501fbab70914ea6dd76dcbed97ecda461358d0
Reviewed-on: https://go-review.googlesource.com/c/148159
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
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>
This enables go to definition for the lsp.
It has one known non working case (where the filenames have $GOROOT in them)
Change-Id: I142c6e04b8691c5076dfcd55592ea710b4b361a4
Reviewed-on: https://go-review.googlesource.com/c/148158
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
I realized this was a mistake, we should try to keep the source
directory independent of the LSP protocol itself, and adapt in
the outer layer.
This will keep us honest about capabilities, let us add the
caching and conversion layers easily, and also allow for a future
where we expose the source directory as a supported API for other
tools.
The outer lsp package then becomes the adapter from the core
features to the specifics of the LSP protocol.
Change-Id: I68fd089f1b9f2fd38decc1cbc13c6f0f86157b94
Reviewed-on: https://go-review.googlesource.com/c/148157
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
Add an autocompletion implementation to the LSP. Also, add a function
that type-checks a package at a certain position, returning an *ast.File
and token.Pos for querying completion.
Change-Id: I288d4e6ed168e6014e79a4436f31f5b4a99b7139
Reviewed-on: https://go-review.googlesource.com/c/147657
Run-TryBot: Rebecca Stambler <rstambler@golang.org>
Reviewed-by: Ian Cottrell <iancottrell@google.com>
This is more reliable than looking in the environment.
Change-Id: I96c093b89faaece6b6256eefb4a4aac4d66b9cc9
Reviewed-on: https://go-review.googlesource.com/c/146757
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alan Donovan <adonovan@google.com>
A file is strongly associated with a view, and knows how to manage it's own
contents.
We can also now track files that are not "active"
Change-Id: Ib9474cd40e5caa3db6596548612a9f90168b8a19
Reviewed-on: https://go-review.googlesource.com/c/147204
Run-TryBot: Ian Cottrell <iancottrell@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
This allows us to write the lsp verbs in terms of a stable underlying source
management layer.
This should make it easier to refactor the underlying layer to add more powerful
caching and incremental modes as we go.
Change-Id: Iab97b061d80394a6fa6748a93a4c68f2deb46129
Reviewed-on: https://go-review.googlesource.com/c/147201
Reviewed-by: Rebecca Stambler <rstambler@golang.org>
