If you have multiple runs in old.txt and new.txt
the default behavior is to match them up pairwise
and compare successive pairs (and if you have a
different number of runs in each file, benchcmp
refuses to do anything).
The new -best flag changes the behavior to instead
compare the fastest run of each benchmark from
the two files. This makes sense if you believe that
the fastest speed is the 'actual' speed and the slower
results are due to the computer spending time doing
non-benchmark work while the benchmark was
running.
LGTM=josharian
R=golang-codereviews, josharian
CC=golang-codereviews
https://golang.org/cl/102890047
Programs such as this cause the PtrTo solver to attempt to
enumerate an infinite set of types {T, *T, ..., *******T, etc}.
t := reflect.TypeOf(T{})
for {
t = reflect.PtrTo(t)
}
The fix is to bound the depth of reflectively created types at
about 4 map/chan/slice/pointer constructors.
+ test.
LGTM=gri
R=gri
CC=crawshaw, golang-codereviews
https://golang.org/cl/102030044
This consistently yields better performance with go/pointer.
Also: return int not word from ntz().
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/97570044
go/types doesn't correctly round the largest possible
float32 literal values and fails. Instead of relying
on Rat.Float64 and float32 conversion, we need a
Rat.Float32 implementation with correct rounding.
LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/96540045
They were disabled by mistake during the move to go.tools.
LGTM=dan.kortschak
R=golang-codereviews, dan.kortschak
CC=golang-codereviews
https://golang.org/cl/98440048
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
(I forgot about this when we added support for negative elements generally.)
We use floating point for negative numbers. The order of the
output is reversed from the previous (little-endian) behaviour
since it makes for more readable floating point.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/95570043
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
It was very ugly; a little tweaking helps godoc parse it better.
Also make unsafeptr.go not own the package doc (add a blank line)
and put one more sentence about that check into doc.go.
Fixesgolang/go#7925.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/98370044
This is both easier to read and 25% shorter (helpful when
using String() as a map key for interning sets).
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/96370045
Very long instructions caused the printf width spec to go
negative, which causes right-padding, often several lines'
worth.
Also: print the basic block comment once on the RHS. It's too
verbose to print it each time we mention the block.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/97490046
intsets.Sparse is a sparse bit vector. It uses space proportional
to the number of elements, not the maximum element (as is the case for a dense bit vector).
A forthcoming CL will make use of it in go/pointer, where it reduces
solve time by 78%. A similar representation is used for Andersen's
analysis in gcc and LLVM.
+ Tests.
LGTM=sameer, crawshaw, gri
R=gri
CC=crawshaw, golang-codereviews, sameer
https://golang.org/cl/10837043
Ignore calls to various flavours of atomic.AddInt with a wrong
number of arguments.
LGTM=r
R=golang-codereviews, r
CC=golang-codereviews
https://golang.org/cl/91370045
This CL moves code from code.google.com/p/dvyukov-go-perf-dashboard,
which was previously reviewed.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/96170043
This CL moves code from code.google.com/p/dvyukov-go-perf-dashboard,
which was previously reviewed.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/96180043
This CL moves code from code.google.com/p/dvyukov-go-perf-dashboard,
which was previously reviewed.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/97250044
This CL moves code from code.google.com/p/dvyukov-go-perf-dashboard,
which was previously reviewed.
UI part will be submitted separately.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/97260043
This CL moves code from code.google.com/p/dvyukov-go-perf-dashboard,
which was previously reviewed.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/95190043
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
