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