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 option uses Variable Type Analysis, a refinement of CHA
suitable for partial programs.
Change-Id: I6c8b074e915d29eb9425656f345e8160417ba594
Reviewed-on: https://go-review.googlesource.com/c/tools/+/410138
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Alan Donovan <adonovan@google.com>
Reviewed-by: Zvonimir Pavlinovic <zpavlinovic@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
Monomorphize the instantiation of generic functions. Applies type
substitution while building the function instantiation.
Adds a new BuilderMode, ssa.InstantiateGenerics, to enable
monomorphization. InstantiateGenerics is turned on by the flag 'G' in
tools that specify the BuilderMode.
Adds a parameterized field to Program to detect when a MethodValue is
parameterized.
Thunk creation creates new MethodExpr selections. Adds a new methodExpr
type to construct a MethodExpr from outside of types, and selection
interface to generalize a *methodExpr and *types.Selection.
Tests x/tools/go/ssa/interp against the runnable examples in
$GOROOT/test/typeparam/*.go. Some additional models to support files.
Misc. cleanup:
- adding (*canonizer).instantiateMethod to create a canonical
representative of a method.
- documenting builder.go
- adding (*subster).types that applies type substitution to a list.
Updates golang/go#48525
Change-Id: I885a4223900feaa3664e35caf8618d11ba16a2a7
Reviewed-on: https://go-review.googlesource.com/c/tools/+/356315
Reviewed-by: Dominik Honnef <dominik@honnef.co>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Zvonimir Pavlinovic <zpavlinovic@google.com>
Run-TryBot: Tim King <taking@google.com>
gopls-CI: kokoro <noreply+kokoro@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
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>
In go1.10, go/packages falls back to loading all packages
from source but not typechecking function bodies for imports.
The ssautil.Packages function would nonetheless provide
the partially-typed ASTs to the SSA builder, which would crash.
Now Packages only passes syntax trees to the SSA builder for
the initial packages, which are the only ones guaranteed to be
fully typed.
It is impossible to discern whether the caller of Packages intends to
build SSA code for dependencies, as in some clients such as
cmd/callgraph, so we add a new function, AllPackages, that expresses
this intent.
Fixesgolang/go#28106
Change-Id: I6a88b7c7545e9de90b61f5bee0e6de3d2e21b548
Reviewed-on: https://go-review.googlesource.com/c/141686
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <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>
Errors relating to a particular package (as opposed to the Load
operation as a whole) are now only recorded in the Errors
field of the corresponding Package.
Clients are responsible for printing or otherwise handling errors.
This is a breaking API change.
The PrintErrors function prints all accumulated errors,
dependencies first, and is provided for convenience.
PrintErrors is based on Visit, another helper function, which
visits each Package in an import graph.
Also:
- add an Example documenting typical use.
- update clients to handle errors explicitly.
Depends on https://go-review.googlesource.com/c/tools/+/130576
Change-Id: I39407ab7f46dae2f0dd0fdde21080e172e1258aa
Reviewed-on: https://go-review.googlesource.com/131015
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>
Caller is *ssa.Function. Its Pkg field is *ssa.Package. But ssa.Package
struct doesn't contain either field or method named Object.
So one gets the following error:
$ callgraph -format '{{.Caller.Pkg.Object.Path}} -> {{.Callee.Pkg.Object.Path}}' \
$(go env GOROOT)/src/net/http/triv.go | sort | uniq
callgraph: template: -format:1:9: executing "-format" at <.Caller.Pkg.Object.P...>: can't evaluate field Object in type *ssa.Package
ssa.Package contains Pkg field:
Pkg *types.Package // the corresponding go/types.Package
types.Package contains Path() method that returns the package path.
That appears to be the right way to get the "import path of the
enclosing package" with the current x/tools/go/ssa API.
Fixesgolang/go#20459.
Change-Id: I3cb7b61b767148f5c771d57f8f5e7e6ab20aea87
Reviewed-on: https://go-review.googlesource.com/43812
Reviewed-by: Avelino <t@avelino.xxx>
Reviewed-by: Alan Donovan <adonovan@google.com>
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>
Since this tool is a handy way to run the pointer analysis during debugging.
Change-Id: If9a62f71dd8651ad6c782ead85bb84f09c703cba
Reviewed-on: https://go-review.googlesource.com/17382
Reviewed-by: Robert Griesemer <gri@golang.org>
And add a TODO.
Change-Id: I51c63b32e9ac4309cdfb8228348a5d528f36a919
Reviewed-on: https://go-review.googlesource.com/10489
Reviewed-by: Robert Griesemer <gri@golang.org>
The loader package now loads, parses, and type-checks a whole program
from source, and that is all.
Also:
- simplified loader logic
- ssa.Create is gone; use ssautil.CreateProgram.
- ssautil.LoadPackage renamed to BuildPackage.
It is now independent of go/types' Import hook and the Packages map.
- ssadump: -importbin flag removed.
The value of this flag was that it caused the tool to print IR
for only a single package; this is now the normal behaviour.
Fixes#9955
Change-Id: I4571118258ab1a46dccece3241b7dc51401a3acc
Reviewed-on: https://go-review.googlesource.com/8953
Reviewed-by: Robert Griesemer <gri@golang.org>
...since the zero value is more useful by far.
This is a breaking API change, obviously. (One or two tests in this
CL have intentional been left using the zero value, i.e., they now
load source.)
Change-Id: I42287bfcdb1afef8ee84e5eac12534dd0a1fd5d2
Reviewed-on: https://go-review.googlesource.com/5653
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>
"static" ignores dynamic calls altogether.
"cha" uses Class Hierarchy Analysis, which assumes that a
dynamic call may dispatch to any func or method that satisfies
the type.
Both these algorithms can work on partial programs,
e.g. libraries without a main function or tests.
(This feature was requested after my talk last night.)
+ Tests.
LGTM=sameer
R=sameer, minux
CC=golang-codereviews, gri
https://golang.org/cl/176780043
Such messages are more informative when the error occurs deep within a script.
Also: add tool name to digraph's usage messages.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/173380043
(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
Tim King
Bryan C. Mills
Zvonimir Pavlinovic
Russ Cox
phillc
Michael Matloob
Dmitri Shuralyov
David R. Jenni
Robert Griesemer
David Symonds