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
