Add tests for recently introduced asm error checks in vet.
This adds tests for the new warnings about functions that
don't store to their return slot before returning or that
store to SP-relative addresses in or beyond the argument
frame. It also adds a test for leaf function handling on arm,
where the link register is not implicitly saved.
LGTM=rsc
R=rsc
CC=adg, golang-codereviews, r
https://golang.org/cl/166040044
vet now includes function names in its error messages about
assembly code. Update the error test patterns to account for
this and expand some patterns to check that go vet discovers
the function name correctly.
Fixesgolang/go#9041
LGTM=r
R=adg, r, rsc
CC=golang-codereviews
https://golang.org/cl/170940044
(They may contain any character, after all.)
Also, allow but don't require parens and stars.
e.g. (*"encoding/json".Decoder).Decode or "encoding/json".Decoder.Decode
but not encoding/json.Decoder.Decode.
Since -from queries are now Go expressions, we use the Go parser.
(Thanks to Rog Peppe for the suggestion.)
LGTM=sameer
R=sameer
CC=golang-codereviews, gri, rogpeppe
https://golang.org/cl/154610043
This adds support for checking moves to the return value stack
slot (from rsc), adds support for checking power64x assembly,
fixes argument offset checking and leaf function support on
platforms with a link register (arm and power64).
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/166920043
The sendPerfFailMail function populated a dummy commit value and
then calls commonNotify, which then updated and stored that dummy
commit, hosing the original commit entity.
LGTM=rsc
R=rsc, bradfitz, dvyukov
CC=golang-codereviews
https://golang.org/cl/164960043
See regression test for explanation.
I audited the code for similar issues and found none.
Many thanks to Daniel Morsing for providing a small
reproducible test case, a rarity for PTA bugs!
Fixesgolang/go#9002
LGTM=crawshaw
R=crawshaw
CC=daniel.morsing, golang-codereviews
https://golang.org/cl/163350043
solaris-amd64-solaris11 has been the most stable builder,
by far, over the last 9 months. solaris-amd64-smartos is
stable too and it's our fastest builder.
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=adg, dave, golang-codereviews
https://golang.org/cl/163280043
When the tree is particularly broken,
even the first invocation of bench binary that queries list
of benchmarks can hang.
Fixesgolang/go#8844.
LGTM=bradfitz
R=adg, bradfitz
CC=golang-codereviews
https://golang.org/cl/162160043
Current response logging logs either nil or pointer value
(e.g. "dash -> {0xc20802e058}"). Not very useful.
Log actual response data.
LGTM=bradfitz
R=adg, bradfitz
CC=golang-codereviews
https://golang.org/cl/163860043
The bug it refers to is now fixed, and the alternative
implementation it suggests is not an improvement.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/151620044
Also removes a potential race condition regarding the
used flag of Var objects when type-checking packages
concurrently.
Implementation: Rather than marking all used dot-imported
objects and then deduce which corresponding package was used,
now we consider all dot-imported packages as unused and remove
each package from the unused packages map as objects are used.
Now only objects that can be marked as used have a used field
(variables, labels, and packages).
As a result, the code became cleaner and simpler.
Fixesgolang/go#8969.
LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/163740043
Example: show the transitive closure of imports of the digraph tool itself:
% go list -f '{{.ImportPath}}{{.Imports}}' ... | tr '[]' ' ' |
digraph forward code.google.com/p/go.tools/cmd/digraph
+ basic test.
LGTM=gri
R=gri, sameer
CC=golang-codereviews
https://golang.org/cl/161760043
Revision 184f9219148f (from review 152790043) introduced a new image,
linux-x86-clang, and the url is missing the `s` for TLS.
LGTM=adg
R=bradfitz, golang-codereviews, adg
CC=golang-codereviews
https://golang.org/cl/156480043
1. Add missing comma to empty records after addition of Ann column.
2. Fix off-by-one in commit range calculation.
Release tags refer to the last commit of the release,
so there is no need to subtract 1 from them.
TBR=adg
R=adg, bradfitz
CC=golang-codereviews
https://golang.org/cl/157120043
1. Don't interpolate missing data points,
instead just use the previous value for missing points.
Interpolation hides significant line jumps,
making it look like the jump is a result of several small changes.
2. Add annotations for significant changes.
LGTM=adg
R=adg
CC=golang-codereviews, iant, rsc
https://golang.org/cl/154360046
Use single query to fetch commit runs and metric runs (instead of individual selects).
Hopefully this enables some kind of prefetching.
But more importantly it allows to work around "gaps" in commit nums,
as we only fetch data that is actually in the database
and don't try to query all commit runs in the "gap".
LGTM=adg
R=adg
CC=golang-codereviews, rsc
https://golang.org/cl/159910045
Several changes as per Russ and Ian requests:
1. Fix almost broken ZoomIn/ZoomOut/Newer/Older with ability zoom in/out and move left/right w/o reloading (the 'explorer' attribute on graph).
2. Start the graph from the current release by default.
3. Allow to select the range of commits by specifying release range (e.g. go1.1 to go1.3 or go1.3 to tip).
4. Make it visually clear that you can select several benchmarks/metrics (replace select with a set of checkboxes).
5. Remove the "absolute" mode. Instead normalize all metrics to the start of the release (start becomes 1.0) and all subsequent changes are relative to it.
LGTM=adg
R=adg
CC=golang-codereviews, iant, rsc
https://golang.org/cl/159980043
As per Ian request:
>> Let's clearly separate the build numbers from the runtime numbers.
>> The build numbers are interesting but there are many things that
>> affect them. The runtime numbers are presumably stable.
LGTM=adg
R=adg
CC=golang-codereviews, iant, rsc
https://golang.org/cl/154440043
Initially both positive and negative changes had solid background (green and red).
Then we removed background of positive changes due to:
https://code.google.com/p/go/issues/detail?id=8624
However, Ian noted:
"I did intuitively understand that + was an increase and - was a
decrease. I did not notice how the numbers were segregated between
the third and fourth columns. Now that you point it out, it is
obvious. It would be more obvious if the numbers in the fourth column
were highlighted in green."
Give positive changes green *border* (not background),
so they are still visually distinguishable from negative even in grayscale.
This is especially beneficial for perf detail view,
because currently it looks like everything is either
negative or neutral in that view (only red and black).
LGTM=adg
R=adg
CC=golang-codereviews, iant, rsc
https://golang.org/cl/159970043
Initializing the unused variable formatterType (it will be used soon) was
panicking if the import couldn't be done, but vet shouldn't be so fragile.
LGTM=gri
R=gri
CC=dsymonds, golang-codereviews
https://golang.org/cl/153480044
The previous logic would descend into (e.g.) .git repositories
and vendored packages with "_"-prefixed names.
Fixesgolang/go#8907
LGTM=gri
R=gri
CC=golang-codereviews, shurcool
https://golang.org/cl/157800043
