The previous implementation would cause the graph to contain
many duplicate edges resulting in very large cross products,
so that for some inputs (and random map iteration orders) the
running time of DeleteSyntheticNodes was many minutes---more
than the pointer analysis!
Duplicate edges can arise from an interface call that
dispatches to several different wrapper functions each
wrapping the same declared method.
For example, in the callgraph for go/types, a call to
Object.Pos() dispatches to the synthetic functions (*Type).Pos
and (*Var).Pos, each of which wrap (*object).Pos(). After
DeleteSyntheticNodes, Object.Pos() appeared to call
(*object).Pos() twice.
This change builds the set of all edges and avoids adding
edges already in the set.
Also, document findings.
LGTM=crawshaw
R=crawshaw
CC=golang-codereviews
https://golang.org/cl/96100043
The old code printed the underlying type; e.g., the type
of time.Millisecond was reported to be int64 rather than
time.Duration.
Testsuite (and corresponding tests) in progress (another CL).
LGTM=adonovan
R=adonovan, dsymonds
CC=golang-codereviews
https://golang.org/cl/94770045
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
Method expressions T.f are reported as having type (T)func(T),
i.e. T appears twice, as a receiver and a regular parameter.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/96780044
During block optimization, degenerate conditional logic such
as "false && x" may result in single-predecessor blocks
containing φ-nodes. (Ideally such φ-nodes would be replaced
by their sole operand, but that requires Referrers information
which isn't computed until later.) It is obviously not safe
to fuse such blocks, so now we don't.
Fixesgolang/go#7840
LGTM=gri
R=gri
CC=golang-codereviews, pcc
https://golang.org/cl/90620043
(The test thread is racing with the analysis thread, which
takes around 4ms on this input.)
LGTM=gri
R=gri, bradfitz
CC=golang-codereviews
https://golang.org/cl/89780044
GccgoInstallation.InitFromDriver currently parses
the output of gccgo -### to get the gcc version,
target triple, and library paths. At least with
Ubuntu's stock libgo5 package, the search path for
.gox files derived from the version is incorrect.
gccgo uses the DEFAULT_TARGET_VERSION macro when
constructing the search path; this value can be
retrieved from gccgo via the "-dumpversion" flag.
Fixesgolang/go#7772.
LGTM=iant, gri
R=golang-codereviews, iant, gri
CC=golang-codereviews
https://golang.org/cl/88150043
The text and images are "baked in" to the godoc executable's
rodata section (~300KB) and are accessible from the godoc
server itself at /lib/godoc/analysis/help.html.
In due course, the page will become visible at
http://golang.org/lib/godoc/analysis/help.html, which will be
the canonical location for this doc (in announcements, etc).
The page is temporarily visible here, for those on the Google corp network:
http://172.26.104.127:7777/lib/godoc/analysis/help.html
Also:
- add link to new doc from source view pages.
- document -analysis flag in cmd/godoc/doc.go
- fix indentation of -analysis flag's help string
LGTM=gri
R=gri, bgarcia, r
CC=golang-codereviews
https://golang.org/cl/87110045
Also:
- remove stale comment about line numbers.
- log a warning if file's package root not found.
LGTM=bgarcia
R=bgarcia
CC=golang-codereviews
https://golang.org/cl/88510044
Otherwise on Windows the enumerated package "net\\http" will
be distinct from the imported package "net/http" leading to
strange errors. (A similar bug was fixed in go/ssa/stdlib_test.go.)
Fixesgolang/go#7189
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/86170043
These were removed when adding the -analysis flag (CL
60540044), ostensibly for performance, but I can't reproduce
the serious slowdowns I saw then. In any case, they are
needed for certain URLs.
Fixesgolang/go#7743
LGTM=bgarcia
R=bgarcia
CC=golang-codereviews
https://golang.org/cl/86150043
If $GOPATH was large, or $GOPATH was $HOME and $HOME/src had
many files, the unbounded concurrency in loadPkgIndex/loadPkg
could make the operating system unhappy with so many
threads. (sigh once again for no async file IO and needing
threads for file operations)
In addition, don't call go/build.Context.Import on directories
that we've already determined to have no go files in them.
It's just a waste of time. Makes it about 3x faster on my
machine with hot caches and a big $HOME/src.
Fixesgolang/go#7731
LGTM=iant, adg
R=golang-codereviews, iant, adg
CC=david.crawshaw, golang-codereviews
https://golang.org/cl/85670044
