This CL aims to fix the problem described here:
https://groups.google.com/forum/#!topic/golang-nuts/R6ms1n9KjiY
This makes it easier to parse via external tools such as editors. Editors can
show each function in a list and jump directly to each function with this
additional information. This pattern can be seen in other Go tools such as "go
test" in the form of:
--- FAIL: TestCover (0.52 seconds)
cover_test.go:43: example error
LGTM=adg
R=r, adg, josharian, dave
CC=golang-codereviews
https://golang.org/cl/131820043
We want to make an if look like two blocks and have the coverage
report for the else block decorate the "else" keyword with the right
color. To do this, we adjust the apparent starting point of the else
block to include the "else".
The previous code assumed the way to do this was to move the
width of "else " backwards from the else block's opening brace, but
that assumes there is a space there. Instead, we now just start the
else block exactly at the end of the if block. Simpler, cleaner, and
fixes a bug.
Fixesgolang/go#8557.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/127620043
As requested on Stack Overflow: http://goo.gl/ams9fY
(Kudos to sberry for his JavaScript solution, provided there.
This change does the same thing on the server side.)
LGTM=r
R=r
CC=golang-codereviews
https://golang.org/cl/127030043
Split the profile parsing code out of cmd/cover into
a reusable package, to support third-party coverage
tools.
R=golang-dev, r, adg
CC=golang-dev
https://golang.org/cl/36050045
Break the basic block at the function literal. The code to do this analysis
was already there; this CL just factors it out more nicely and uses it in
one new place. Also adds a test.
Fixesgolang/go#6555.
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/14601043
Present the files in lexical order so the output is reproducible
and easier to navigate. Do a little type rearrangement to simplify
things while we're there.
R=adg
CC=golang-dev
https://golang.org/cl/14357043
Phrases like "returns whether or not the image is opaque" could be
describing what the function does (it always returns, regardless of
the opacity) or what it returns (a boolean indicating the opacity).
Even when the "or not" is missing, the phrasing is bizarre.
Go with "reports whether", which is still clunky but at least makes
it clear we're talking about the return value.
R=golang-dev, dsymonds
CC=golang-dev
https://golang.org/cl/11458046
This requires a little more tree rewriting to put a block around the if of an "else if".
More tests too.
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/11042045
Need the ./ for the path. Quick fix to get the build green, but what really is the right answer for Windows?
R=golang-dev
CC=golang-dev
https://golang.org/cl/10359044
Test the statistics work as expected for a simple program, which can be extended as needed. This is all a bit meta.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/10392050
This number will allow us to give a conventional meaning to "coverage":
the percentage of executable statements visited by the test.
R=adonovan
CC=golang-dev
https://golang.org/cl/10271045
We are going to need one more piece of data, so rather than create
a third variable let's just put it all in one struct. The interface gets
easier too.
R=adonovan
CC=golang-dev
https://golang.org/cl/10271044
This is just the tool proper; stitching into "go test" will be a separate CL.
Tests are missing - they'll come once it's integrated - but it can handle,
perhaps correctly, all of src/pkg/...
The basic approach is to rewrite the source to add annotations that will
track coverage; the rewritten source must of course be compiled and
run after this tool has done its job.
R=adonovan
CC=golang-dev
https://golang.org/cl/10102043
