From 23aefcd9aee4ad7fe3d4139c60fc773b0ae23953 Mon Sep 17 00:00:00 2001
From: Russ Cox
-TODO: default GOROOT changes in cmd/go
-TODO: computed GOROOT change
+If the environment variable
@@ -145,7 +151,7 @@ back and forth between different branches in a version control system).
The old advice to add the
@@ -406,17 +412,10 @@ a repository is not âproperly formattedâ is inherently fragile and not recom
If multiple programs must agree about which version of gofmt is used to format a source file,
we recommend that they do this by arranging to invoke the same gofmt binary.
-For example, in the Go open source repository, we arrange for goimports and
-our Git pre-commit hook to agree about source code formatting by having both
-invoke the gofmt binary found in the current path.
-TODO: Make goimports actually do that. #22695.
-As another example, inside Google we arrange that source code presubmit
-checks run a gofmt binary maintained at a fixed path in a shared, distributed file system;
-that on engineering workstations Default GOROOT & GOTMPDIR
$GOROOT
is unset,
+the go tool previously used the default GOROOT
+set during toolchain compilation.
+Now, before falling back to that default, the go tool attempts to
+deduce GOROOT
from its own executable path.
+This allows binary distributions to be unpacked anywhere in the
+file system and then be used without setting GOROOT
+explicitly.
-i
flag for speed, as in go
build
-i
or go
test
-i
,
is no longer necessary: builds run just as fast without -i
.
-For more details, see go
help
cache
.
+For more details, see go
help
cache
.
/usr/bin/gofmt
-is a symbolic link to that same path;
-and that all editor integrations used for Google development
-explicitly invoke /usr/bin/gofmt.
-TODO: TMI?
+For example, in the Go open source repository, our Git pre-commit hook is written in Go
+and could import go/format
directly but instead invokes the gofmt
+binary found in the current path, so that the pre-commit hook need not be recompiled
+each time gofmt
changes.
Compiler Toolchain
@@ -578,12 +577,23 @@ optimization decisions and implementation details.
-There is no longer a limit on the GOMAXPROCS
setting.
-(In Go 1.9 the limit was 1024.)
+The garbage collector has been modified to reduce its impact on allocation latency.
+It now uses a smaller fraction of the overall CPU when running, but it may run more of the time.
+The total CPU consumed by the garbage collector has not changed significantly.
-TODO: Anything about CL 59970: "runtime: separate soft and hard heap limits"?
+The GOROOT
function
+now defaults (when the $GOROOT
environment variable is not set)
+to the GOROOT
or GOROOT_FINAL
in effect
+at the time the calling program was compiled.
+Previously it used the GOROOT
or GOROOT_FINAL
in effect
+at the time the toolchain that compiled the calling program was compiled.
+
+There is no longer a limit on the GOMAXPROCS
setting.
+(In Go 1.9 the limit was 1024.)
{{"{{break}}"}}
and {{"{{continue}}"}}
break out of the innermost {{"{{range"}}
...}}
loop,
like the corresponding Go statements.
--TODO: something about the AddParseTree problem (#21844). -