This should have been included in
https://go-review.googlesource.com/c/tools/+/410138
Change-Id: Ic8a4f1b5dbcdb320fb872b24484b830dcb56fd41
Reviewed-on: https://go-review.googlesource.com/c/tools/+/410123
Run-TryBot: Alan Donovan <adonovan@google.com>
Reviewed-by: Tim King <taking@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Zvonimir Pavlinovic <zpavlinovic@google.com>
This test produces apparent file corruption on all of the
windows/arm64 builders. I suspect that this is a low-level bug (in
either the platform itself or the Go standard library on
windows/arm64).
Since windows/arm64 is not yet a first-class port, this test can be
skipped for now. However, if windows/arm64 becomes a first-class port
the underlying file-corruption bug should be investigated and fixed.
Updates golang/go#50706.
Change-Id: I0bc80cefee50895d40acc658286eb7ef8790493a
Reviewed-on: https://go-review.googlesource.com/c/tools/+/397996
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We don't know whether this failure is due to a Go bug or a platform
bug, so we'll skip it on the one builder to reduce noise, but not the
GOOS/GOARCH as a whole. If we do not observe failures on other
windows/arm64 builders, we can perhaps chalk it up to a platform bug.
If we do observe failures on other builders, then we'll have more data
to investigate with.
For golang/go#50706
Change-Id: I52511dd4a5cff80953823d9cf901975ff4657457
Reviewed-on: https://go-review.googlesource.com/c/tools/+/379734
Trust: Bryan Mills <bcmills@google.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild
Not strictly necessary but will avoid gofmt changes later
as people edit these files.
Change-Id: I20749ed82e18938a305d9425d0739f0ea7bd24c0
Reviewed-on: https://go-review.googlesource.com/c/tools/+/294414
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
gopls-CI: kokoro <noreply+kokoro@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Some users may set GO111MODULE=on, and we will eventually want to be able to
build x/tools itself in module mode.
Updates golang/go#27858
Updates golang/go#27852
Change-Id: Iaf488b2a89e6526471530245cb580f1f0391a770
Reviewed-on: https://go-review.googlesource.com/137815
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
go1.10 and earlier versions of go list do not report test main packages.
Furthermore, go/packages has errors in its Imports under go1.10.
The long-term fix is for go/packages to synthesize test main packages
when working with older versions of the go command, but in the
meantime we will disable the tests.
Updates golang/go#11811
Change-Id: Ifd5e37d5b68a01134e911fda90e30a39fc25b88d
Reviewed-on: https://go-review.googlesource.com/129175
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Because go/packages presents each synthesized test main package
as a first-class package, the tests now analyze all of the dependencies
of "testing", which they previously avoided. This makes the tests
slower and the resulting call graph much larger,
so they now look for a subset match, not an exact match,
on the set of graph edges.
Change-Id: I9d7acf420e41cbffc03ca8423f5afb3ef671d775
Reviewed-on: https://go-review.googlesource.com/128695
Reviewed-by: Ian Cottrell <iancottrell@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Supporting user-defined TestMain functions requires that we generate a
"testmain" package for each testable package, rather than a single one
for the entire program. This entails these API changes:
1. (*ssa.Program).{CreateTestMainPackage,FindTests} both now
accept only a single package. Existing clients that pass them
multiple packages must call them from a loop.
2. (*ssa.Program).FindTests returns an additional result, the the
optional TestMain *ssa.Function. Existing clients may discard it.
Also:
- Test the new logic using the SSA interpreter
- add ssautil.MainPackages helper
- callgraph: allow multiple main packages, and analyze them all
- ssadump -run: allow multiple main/test packages, and run each in a new interpreter
- minor simplifications to some callers (e.g. guru)
Fixesgolang/go#9553
Change-Id: Ia7de9bd27448fb08b8d172ba5cdbcf37a762b7a0
Reviewed-on: https://go-review.googlesource.com/25102
Reviewed-by: Robert Griesemer <gri@golang.org>
...to avoid namespace conflicts.
Also make its name "main", since it defines func main().
And fix 2 typos.
Change-Id: I7cf7894d6bed134907b3d2742255e5a82426071b
Reviewed-on: https://go-review.googlesource.com/3150
Reviewed-by: Robert Griesemer <gri@golang.org>
(This functionality is provided by the oracle, but its output
format is inflexible, and the functionality is better suited
to a shell utility. I may remove the oracle 'callgraph' feature.)
See Usage for details.
+ Test.
LGTM=sameer
R=sameer
CC=golang-codereviews, gri
https://golang.org/cl/164460044
Alan Donovan
Bryan C. Mills
Russ Cox
Robert Griesemer