design/51430: add missing statement count for legacy format
fix some typos
Change-Id: Ic4290481cd7cb007aaec10cf4c67e61a2e7f57cd
GitHub-Last-Rev: 921891168b9f5ad12600dfda0bab95213b6f73c9
GitHub-Pull-Request: golang/proposal#46
Reviewed-on: https://go-review.googlesource.com/c/proposal/+/411814
Reviewed-by: Than McIntosh <thanm@google.com>
diff --git a/design/51430-revamp-code-coverage.md b/design/51430-revamp-code-coverage.md
index 7d167f1..99e0d55 100644
--- a/design/51430-revamp-code-coverage.md
+++ b/design/51430-revamp-code-coverage.md
@@ -16,7 +16,7 @@
### Current support for coverage testing
The Go toolchain currently includes support for collecting and reporting
-coverage data for Golang unit tests; this facility is made available via the "go
+coverage data for Go unit tests; this facility is made available via the "go
test -cover" and "go tool cover" commands.
The current workflow for collecting coverage data is baked into "go test"
@@ -356,7 +356,7 @@
$
```
-In the invocation above, the Go tool reports coverage for package 'p1' and for all packages under 'p2', but not for any other packages (for example, any of the various packages imported by 'p1').
+In the invocation above, the Go tool reports coverage for package `p1` and for all packages under `p2`, but not for any other packages (for example, any of the various packages imported by `p1`).
When building applications for coverage, the default will be to instrument all packages in the main module for the application being built.
Here is an example using the "delve" debugger (a Go application):
@@ -414,7 +414,7 @@
L15: }
```
-Consider the `{` and '}' tokens on lines 12 and 14. While the compiler will accept these tokens, it will not necessarily create explicit representations for them (with detailed line/column source positions) in its IR, because once parsing is complete (and no syntax errors are reported), there isn't any need to keep this information around (it would just be a waste of memory).
+Consider the `{` and `}` tokens on lines 12 and 14. While the compiler will accept these tokens, it will not necessarily create explicit representations for them (with detailed line/column source positions) in its IR, because once parsing is complete (and no syntax errors are reported), there isn't any need to keep this information around (it would just be a waste of memory).
This is a problem for code coverage meta-data generation, since we'd like to record these sorts of source positions for reporting purposes later on (for example, during HTML generation).
@@ -427,7 +427,7 @@
The `cmd/cover` tool will be modified to operate at the package level and not at the level of an individual source file; the output from the instrumentation process will be a series of modified source files, plus summary file containing things like the the names of generated variables create during instrumentation.
This generated file will be passed to the compiler when the instrumented package is compiled.
-The new style of instrumentation will segregate coverage meta-data and coverage counters, so as to allow the compiler to place emta-data into the read-only data section of the instrumented binary.
+The new style of instrumentation will segregate coverage meta-data and coverage counters, so as to allow the compiler to place meta-data into the read-only data section of the instrumented binary.
This segregation will continue when the instrumented program writes out coverage data files at program termination: meta-data and counter data will be written to distinct output files.
@@ -667,8 +667,8 @@
```
Each line is a package path, source position info (file/line/col) for a basic
-block, and an execution count (or 1/0 boolean value indicating "hit" or "not
-hit").
+block, statement count, and an execution count (or 1/0 boolean value indicating
+"hit" or "not hit").
This format is simple and straightforward to digest for reporting tools, but is
also somewhat space-inefficient.
