Go 1.10 adds caching of successful test results & runs vet automatically during tests
© Shutterstock / gguy
The wait is over! Go 1.10 is finally here and it comes bearing gifts (a.k.a. changes). Read on to find out what’s new.
According to the release notes, Go 1.10 improves caching of built packages, adds caching of successful test results, runs vet automatically during tests, and permits passing string values directly between Go and C using cgo.
There are no significant changes to the language specification.
Go 1.10 highlights
It’s that time of year again — another Go version has just been released. Although there aren’t any significant changes to the language specification, there are some minor alterations such as
- A corner case involving shifts by untyped constants has been clarified. The compilers have been updated to allow the index expression
sis an untyped constant [the go/types package already did].
- The grammar for method expressions has been updated to relax the syntax to allow any type expression as a receiver; this matches what the compilers were already implementing.
Build & Install
Good news! The
build command now detects out-of-date packages purely based on the content of source files, specified build flags, and metadata stored in the compiled packages, according to the Go 1.10 release notes.
You don’t have to follow the old advice to add
-a to force a rebuild in cases where the modification times were misleading for one reason or another (for example, changes in build flags) anymore. As of now, builds always detect when packages must be rebuilt.
-ldflags options apply by default only to the packages listed directly on the command line. The
build command maintains a cache of recently built packages, separate from the installed packages in
$GOPATH/pkg. The goal is to speed builds which don’t explicitly install packages or when switching between different copies of source code. You can now ignore the old advice to add the
-i flag for speed, as in
-i since builds run just as fast without
As of now, the
install command installs only the packages and commands listed directly on the command line. The result is that future commands will run as quickly as if the dependencies had been installed. If you want to force the installation of dependencies, you’ll have to use the new
SEE ALSO: Go 1.9 is here
As of Go 1.10, the
test command caches test results. Therefore, if the test executable and command line match a previous run and the files and environment variables consulted by that run have not changed either,
test will print the previous test output, replacing the elapsed time with the string “(cached).”
However, keep in mind that test caching applies only to successful test results; only to
test commands with an explicit list of packages; and only to command lines using a subset of the
-v test flags. The idiomatic way to bypass test caching is to use
What’s more, it automatically runs
vet on the package being tested in order to pinpoint significant problems before running the test. If you’d like to disable the running of
-json flag filters test output through the new command
test2json to produce a machine-readable JSON-formatted description of test execution.
As far as the
vet command is concerned, there’s [constant] access to complete, up-to-date type information when checking packages, even for packages using cgo or vendored imports. However, it should be noted that only
vet has access to this information; the more low-level
vet does not and should be avoided except when working on
Two changes have been made to the default formatting of Go source code:
- Certain complex three-index slice expressions previously formatted like
j:k]and now format with more consistent spacing:
- Single-method interface literals written on a single line, which are sometimes used in type assertions, are no longer split onto multiple lines.
The behavior of nested calls to
UnlockOSThread has changed. These functions control whether a goroutine is locked to a specific operating system thread, so that the goroutine only runs on that thread, and the thread only runs that goroutine.
Previously, there was no difference between calling
LockOSThread once or more than once in a row and a single
UnlockOSThread always unlocked the thread. Now, the calls nest: if
LockOSThread is called multiple times,
UnlockOSThread must be called the same number of times in order to unlock the thread. Existing code that was careful not to nest these calls will remain correct. Existing code that incorrectly assumed the calls nested will become correct. Most uses of these functions in public Go source code falls into the second category.
Since a common use of
UnlockOSThread is to allow Go code to reliably modify thread-local state, the runtime now treats locked threads as unsuitable for reuse or for creating new threads.
Furthermore, stack traces only include implicit wrapper functions (previously marked
<autogenerated>) if a fault or panic happens in the wrapper itself. Therefore, skip counts passed to functions like
Caller should now always match the structure of the code as written [and should not depend on optimization decisions and implementation details].
The garbage collector now uses a smaller fraction of the overall CPU when running, but at the same time, it may run more of the time. The total CPU consumed by the garbage collector has not changed significantly.
GOROOT function now defaults (when the
$GOROOT environment variable is not set) to the
GOROOT_FINAL in effect at the time the calling program was compiled. The
GOROOT_FINAL was used in effect at the time the toolchain that compiled the calling program was compiled.
Check out the release notes here.