cmd/go/internal/work: fix a couple typos

Change-Id: I357669d8c9bc004031b17f057803c9b152edefee
Reviewed-on: https://go-review.googlesource.com/c/go/+/178057
Reviewed-by: Ian Lance Taylor <iant@golang.org>

diff --git a/src/cmd/go/internal/work/buildid.go b/src/cmd/go/internal/work/buildid.go
index 1a98980915167c3b889261e9ee2ed833335bdc2f..1f6d1e8e779a3160165796e2adc9e43962cae690 100644 (file)
--- a/src/cmd/go/internal/work/buildid.go
+++ b/src/cmd/go/internal/work/buildid.go
@@ -159,7 +159,7 @@ func hashToString(h [cache.HashSize]byte) string {
 // which influences the action ID half of the build ID, is based on the content ID,
 // then the Linux compiler binary and Mac compiler binary will have different tool IDs
 // and therefore produce executables with different action IDs.
-// To avoids this problem, for releases we use the release version string instead
+// To avoid this problem, for releases we use the release version string instead
 // of the compiler binary's content hash. This assumes that all compilers built
 // on all different systems are semantically equivalent, which is of course only true
 // modulo bugs. (Producing the exact same executables also requires that the different
@@ -215,7 +215,7 @@ func (b *Builder) toolID(name string) string {
 }
 
 // gccToolID returns the unique ID to use for a tool that is invoked
-// by the GCC driver. This is in particular gccgo, but this can also
+// by the GCC driver. This is used particularly for gccgo, but this can also
 // be used for gcc, g++, gfortran, etc.; those tools all use the GCC
 // driver under different names. The approach used here should also
 // work for sufficiently new versions of clang. Unlike toolID, the