mirror of
https://github.com/golang/go
synced 2024-09-05 16:04:50 +00:00
![Shenghou Ma](/assets/img/avatar_default.png)
Change-Id: I5bfeeef53665b1ef79ec0e4a6ae0eb4aa3e95603 Signed-off-by: Shenghou Ma <minux@golang.org> Reviewed-on: https://go-review.googlesource.com/8021 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
897 lines
33 KiB
HTML
897 lines
33 KiB
HTML
<!--{
|
|
"Title": "Go 1.4 Release Notes",
|
|
"Path": "/doc/go1.4",
|
|
"Template": true
|
|
}-->
|
|
|
|
<h2 id="introduction">Introduction to Go 1.4</h2>
|
|
|
|
<p>
|
|
The latest Go release, version 1.4, arrives as scheduled six months after 1.3.
|
|
</p>
|
|
|
|
<p>
|
|
It contains only one tiny language change,
|
|
in the form of a backwards-compatible simple variant of <code>for</code>-<code>range</code> loop,
|
|
and a possibly breaking change to the compiler involving methods on pointers-to-pointers.
|
|
</p>
|
|
|
|
<p>
|
|
The release focuses primarily on implementation work, improving the garbage collector
|
|
and preparing the ground for a fully concurrent collector to be rolled out in the
|
|
next few releases.
|
|
Stacks are now contiguous, reallocated when necessary rather than linking on new
|
|
"segments";
|
|
this release therefore eliminates the notorious "hot stack split" problem.
|
|
There are some new tools available including support in the <code>go</code> command
|
|
for build-time source code generation.
|
|
The release also adds support for ARM processors on Android and Native Client (NaCl)
|
|
and for AMD64 on Plan 9.
|
|
</p>
|
|
|
|
<p>
|
|
As always, Go 1.4 keeps the <a href="/doc/go1compat.html">promise
|
|
of compatibility</a>,
|
|
and almost everything
|
|
will continue to compile and run without change when moved to 1.4.
|
|
</p>
|
|
|
|
<h2 id="language">Changes to the language</h2>
|
|
|
|
<h3 id="forrange">For-range loops</h3>
|
|
<p>
|
|
Up until Go 1.3, <code>for</code>-<code>range</code> loop had two forms
|
|
</p>
|
|
|
|
<pre>
|
|
for i, v := range x {
|
|
...
|
|
}
|
|
</pre>
|
|
|
|
<p>
|
|
and
|
|
</p>
|
|
|
|
<pre>
|
|
for i := range x {
|
|
...
|
|
}
|
|
</pre>
|
|
|
|
<p>
|
|
If one was not interested in the loop values, only the iteration itself, it was still
|
|
necessary to mention a variable (probably the <a href="/ref/spec#Blank_identifier">blank identifier</a>, as in
|
|
<code>for</code> <code>_</code> <code>=</code> <code>range</code> <code>x</code>), because
|
|
the form
|
|
</p>
|
|
|
|
<pre>
|
|
for range x {
|
|
...
|
|
}
|
|
</pre>
|
|
|
|
<p>
|
|
was not syntactically permitted.
|
|
</p>
|
|
|
|
<p>
|
|
This situation seemed awkward, so as of Go 1.4 the variable-free form is now legal.
|
|
The pattern arises rarely but the code can be cleaner when it does.
|
|
</p>
|
|
|
|
<p>
|
|
<em>Updating</em>: The change is strictly backwards compatible to existing Go
|
|
programs, but tools that analyze Go parse trees may need to be modified to accept
|
|
this new form as the
|
|
<code>Key</code> field of <a href="/pkg/go/ast/#RangeStmt"><code>RangeStmt</code></a>
|
|
may now be <code>nil</code>.
|
|
</p>
|
|
|
|
<h3 id="methodonpointertopointer">Method calls on **T</h3>
|
|
|
|
<p>
|
|
Given these declarations,
|
|
</p>
|
|
|
|
<pre>
|
|
type T int
|
|
func (T) M() {}
|
|
var x **T
|
|
</pre>
|
|
|
|
<p>
|
|
both <code>gc</code> and <code>gccgo</code> accepted the method call
|
|
</p>
|
|
|
|
<pre>
|
|
x.M()
|
|
</pre>
|
|
|
|
<p>
|
|
which is a double dereference of the pointer-to-pointer <code>x</code>.
|
|
The Go specification allows a single dereference to be inserted automatically,
|
|
but not two, so this call is erroneous according to the language definition.
|
|
It has therefore been disallowed in Go 1.4, which is a breaking change,
|
|
although very few programs will be affected.
|
|
</p>
|
|
|
|
<p>
|
|
<em>Updating</em>: Code that depends on the old, erroneous behavior will no longer
|
|
compile but is easy to fix by adding an explicit dereference.
|
|
</p>
|
|
|
|
<h2 id="os">Changes to the supported operating systems and architectures</h2>
|
|
|
|
<h3 id="android">Android</h3>
|
|
|
|
<p>
|
|
Go 1.4 can build binaries for ARM processors running the Android operating system.
|
|
It can also build a <code>.so</code> library that can be loaded by an Android application
|
|
using the supporting packages in the <a href="https://golang.org/x/mobile">mobile</a> subrepository.
|
|
A brief description of the plans for this experimental port are available
|
|
<a href="https://golang.org/s/go14android">here</a>.
|
|
</p>
|
|
|
|
<h3 id="naclarm">NaCl on ARM</h3>
|
|
|
|
<p>
|
|
The previous release introduced Native Client (NaCl) support for the 32-bit x86
|
|
(<code>GOARCH=386</code>)
|
|
and 64-bit x86 using 32-bit pointers (GOARCH=amd64p32).
|
|
The 1.4 release adds NaCl support for ARM (GOARCH=arm).
|
|
</p>
|
|
|
|
<h3 id="plan9amd64">Plan9 on AMD64</h3>
|
|
|
|
<p>
|
|
This release adds support for the Plan 9 operating system on AMD64 processors,
|
|
provided the kernel supports the <code>nsec</code> system call and uses 4K pages.
|
|
</p>
|
|
|
|
<h2 id="compatibility">Changes to the compatibility guidelines</h2>
|
|
|
|
<p>
|
|
The <a href="/pkg/unsafe/"><code>unsafe</code></a> package allows one
|
|
to defeat Go's type system by exploiting internal details of the implementation
|
|
or machine representation of data.
|
|
It was never explicitly specified what use of <code>unsafe</code> meant
|
|
with respect to compatibility as specified in the
|
|
<a href="go1compat.html">Go compatibility guidelines</a>.
|
|
The answer, of course, is that we can make no promise of compatibility
|
|
for code that does unsafe things.
|
|
</p>
|
|
|
|
<p>
|
|
We have clarified this situation in the documentation included in the release.
|
|
The <a href="go1compat.html">Go compatibility guidelines</a> and the
|
|
docs for the <a href="/pkg/unsafe/"><code>unsafe</code></a> package
|
|
are now explicit that unsafe code is not guaranteed to remain compatible.
|
|
</p>
|
|
|
|
<p>
|
|
<em>Updating</em>: Nothing technical has changed; this is just a clarification
|
|
of the documentation.
|
|
</p>
|
|
|
|
|
|
<h2 id="impl">Changes to the implementations and tools</h2>
|
|
|
|
<h3 id="runtime">Changes to the runtime</h3>
|
|
|
|
<p>
|
|
Prior to Go 1.4, the runtime (garbage collector, concurrency support, interface management,
|
|
maps, slices, strings, ...) was mostly written in C, with some assembler support.
|
|
In 1.4, much of the code has been translated to Go so that the garbage collector can scan
|
|
the stacks of programs in the runtime and get accurate information about what variables
|
|
are active.
|
|
This change was large but should have no semantic effect on programs.
|
|
</p>
|
|
|
|
<p>
|
|
This rewrite allows the garbage collector in 1.4 to be fully precise,
|
|
meaning that it is aware of the location of all active pointers in the program.
|
|
This means the heap will be smaller as there will be no false positives keeping non-pointers alive.
|
|
Other related changes also reduce the heap size, which is smaller by 10%-30% overall
|
|
relative to the previous release.
|
|
</p>
|
|
|
|
<p>
|
|
A consequence is that stacks are no longer segmented, eliminating the "hot split" problem.
|
|
When a stack limit is reached, a new, larger stack is allocated, all active frames for
|
|
the goroutine are copied there, and any pointers into the stack are updated.
|
|
Performance can be noticeably better in some cases and is always more predictable.
|
|
Details are available in <a href="https://golang.org/s/contigstacks">the design document</a>.
|
|
</p>
|
|
|
|
<p>
|
|
The use of contiguous stacks means that stacks can start smaller without triggering performance issues,
|
|
so the default starting size for a goroutine's stack in 1.4 has been reduced from 8192 bytes to 2048 bytes.
|
|
</p>
|
|
|
|
<p>
|
|
As preparation for the concurrent garbage collector scheduled for the 1.5 release,
|
|
writes to pointer values in the heap are now done by a function call,
|
|
called a write barrier, rather than directly from the function updating the value.
|
|
In this next release, this will permit the garbage collector to mediate writes to the heap while it is running.
|
|
This change has no semantic effect on programs in 1.4, but was
|
|
included in the release to test the compiler and the resulting performance.
|
|
</p>
|
|
|
|
<p>
|
|
The implementation of interface values has been modified.
|
|
In earlier releases, the interface contained a word that was either a pointer or a one-word
|
|
scalar value, depending on the type of the concrete object stored.
|
|
This implementation was problematical for the garbage collector,
|
|
so as of 1.4 interface values always hold a pointer.
|
|
In running programs, most interface values were pointers anyway,
|
|
so the effect is minimal, but programs that store integers (for example) in
|
|
interfaces will see more allocations.
|
|
</p>
|
|
|
|
<p>
|
|
As of Go 1.3, the runtime crashes if it finds a memory word that should contain
|
|
a valid pointer but instead contains an obviously invalid pointer (for example, the value 3).
|
|
Programs that store integers in pointer values may run afoul of this check and crash.
|
|
In Go 1.4, setting the <a href="/pkg/runtime/"><code>GODEBUG</code></a> variable
|
|
<code>invalidptr=0</code> disables
|
|
the crash as a workaround, but we cannot guarantee that future releases will be
|
|
able to avoid the crash; the correct fix is to rewrite code not to alias integers and pointers.
|
|
</p>
|
|
|
|
<h3 id="asm">Assembly</h3>
|
|
|
|
<p>
|
|
The language accepted by the assemblers <code>cmd/5a</code>, <code>cmd/6a</code>
|
|
and <code>cmd/8a</code> has had several changes,
|
|
mostly to make it easier to deliver type information to the runtime.
|
|
</p>
|
|
|
|
<p>
|
|
First, the <code>textflag.h</code> file that defines flags for <code>TEXT</code> directives
|
|
has been copied from the linker source directory to a standard location so it can be
|
|
included with the simple directive
|
|
</p>
|
|
|
|
<pre>
|
|
#include "textflag.h"
|
|
</pre>
|
|
|
|
<p>
|
|
The more important changes are in how assembler source can define the necessary
|
|
type information.
|
|
For most programs it will suffice to move data
|
|
definitions (<code>DATA</code> and <code>GLOBL</code> directives)
|
|
out of assembly into Go files
|
|
and to write a Go declaration for each assembly function.
|
|
The <a href="/doc/asm#runtime">assembly document</a> describes what to do.
|
|
</p>
|
|
|
|
<p>
|
|
<em>Updating</em>:
|
|
Assembly files that include <code>textflag.h</code> from its old
|
|
location will still work, but should be updated.
|
|
For the type information, most assembly routines will need no change,
|
|
but all should be examined.
|
|
Assembly source files that define data,
|
|
functions with non-empty stack frames, or functions that return pointers
|
|
need particular attention.
|
|
A description of the necessary (but simple) changes
|
|
is in the <a href="/doc/asm#runtime">assembly document</a>.
|
|
</p>
|
|
|
|
<p>
|
|
More information about these changes is in the <a href="/doc/asm">assembly document</a>.
|
|
</p>
|
|
|
|
<h3 id="gccgo">Status of gccgo</h3>
|
|
|
|
<p>
|
|
The release schedules for the GCC and Go projects do not coincide.
|
|
GCC release 4.9 contains the Go 1.2 version of gccgo.
|
|
The next release, GCC 5, will likely have the Go 1.4 version of gccgo.
|
|
</p>
|
|
|
|
<h3 id="internalpackages">Internal packages</h3>
|
|
|
|
<p>
|
|
Go's package system makes it easy to structure programs into components with clean boundaries,
|
|
but there are only two forms of access: local (unexported) and global (exported).
|
|
Sometimes one wishes to have components that are not exported,
|
|
for instance to avoid acquiring clients of interfaces to code that is part of a public repository
|
|
but not intended for use outside the program to which it belongs.
|
|
</p>
|
|
|
|
<p>
|
|
The Go language does not have the power to enforce this distinction, but as of Go 1.4 the
|
|
<a href="/cmd/go/"><code>go</code></a> command introduces
|
|
a mechanism to define "internal" packages that may not be imported by packages outside
|
|
the source subtree in which they reside.
|
|
</p>
|
|
|
|
<p>
|
|
To create such a package, place it in a directory named <code>internal</code> or in a subdirectory of a directory
|
|
named internal.
|
|
When the <code>go</code> command sees an import of a package with <code>internal</code> in its path,
|
|
it verifies that the package doing the import
|
|
is within the tree rooted at the parent of the <code>internal</code> directory.
|
|
For example, a package <code>.../a/b/c/internal/d/e/f</code>
|
|
can be imported only by code in the directory tree rooted at <code>.../a/b/c</code>.
|
|
It cannot be imported by code in <code>.../a/b/g</code> or in any other repository.
|
|
</p>
|
|
|
|
<p>
|
|
For Go 1.4, the internal package mechanism is enforced for the main Go repository;
|
|
from 1.5 and onward it will be enforced for any repository.
|
|
</p>
|
|
|
|
<p>
|
|
Full details of the mechanism are in
|
|
<a href="https://golang.org/s/go14internal">the design document</a>.
|
|
</p>
|
|
|
|
<h3 id="canonicalimports">Canonical import paths</h3>
|
|
|
|
<p>
|
|
Code often lives in repositories hosted by public services such as <code>github.com</code>,
|
|
meaning that the import paths for packages begin with the name of the hosting service,
|
|
<code>github.com/rsc/pdf</code> for example.
|
|
One can use
|
|
<a href="/cmd/go/#hdr-Remote_import_paths">an existing mechanism</a>
|
|
to provide a "custom" or "vanity" import path such as
|
|
<code>rsc.io/pdf</code>, but
|
|
that creates two valid import paths for the package.
|
|
That is a problem: one may inadvertently import the package through the two
|
|
distinct paths in a single program, which is wasteful;
|
|
miss an update to a package because the path being used is not recognized to be
|
|
out of date;
|
|
or break clients using the old path by moving the package to a different hosting service.
|
|
</p>
|
|
|
|
<p>
|
|
Go 1.4 introduces an annotation for package clauses in Go source that identify a canonical
|
|
import path for the package.
|
|
If an import is attempted using a path that is not canonical,
|
|
the <a href="/cmd/go/"><code>go</code></a> command
|
|
will refuse to compile the importing package.
|
|
</p>
|
|
|
|
<p>
|
|
The syntax is simple: put an identifying comment on the package line.
|
|
For our example, the package clause would read:
|
|
</p>
|
|
|
|
<pre>
|
|
package pdf // import "rsc.io/pdf"
|
|
</pre>
|
|
|
|
<p>
|
|
With this in place,
|
|
the <code>go</code> command will
|
|
refuse to compile a package that imports <code>github.com/rsc/pdf</code>,
|
|
ensuring that the code can be moved without breaking users.
|
|
</p>
|
|
|
|
<p>
|
|
The check is at build time, not download time, so if <code>go</code> <code>get</code>
|
|
fails because of this check, the mis-imported package has been copied to the local machine
|
|
and should be removed manually.
|
|
</p>
|
|
|
|
<p>
|
|
To complement this new feature, a check has been added at update time to verify
|
|
that the local package's remote repository matches that of its custom import.
|
|
The <code>go</code> <code>get</code> <code>-u</code> command will fail to
|
|
update a package if its remote repository has changed since it was first
|
|
downloaded.
|
|
The new <code>-f</code> flag overrides this check.
|
|
</p>
|
|
|
|
<p>
|
|
Further information is in
|
|
<a href="https://golang.org/s/go14customimport">the design document</a>.
|
|
</p>
|
|
|
|
<h3 id="subrepo">Import paths for the subrepositories</h3>
|
|
|
|
<p>
|
|
The Go project subrepositories (<code>code.google.com/p/go.tools</code> and so on)
|
|
are now available under custom import paths replacing <code>code.google.com/p/go.</code> with <code>golang.org/x/</code>,
|
|
as in <code>golang.org/x/tools</code>.
|
|
We will add canonical import comments to the code around June 1, 2015,
|
|
at which point Go 1.4 and later will stop accepting the old <code>code.google.com</code> paths.
|
|
</p>
|
|
|
|
<p>
|
|
<em>Updating</em>: All code that imports from subrepositories should change
|
|
to use the new <code>golang.org</code> paths.
|
|
Go 1.0 and later can resolve and import the new paths, so updating will not break
|
|
compatibility with older releases.
|
|
Code that has not updated will stop compiling with Go 1.4 around June 1, 2015.
|
|
</p>
|
|
|
|
<h3 id="gogenerate">The go generate subcommand</h3>
|
|
|
|
<p>
|
|
The <a href="/cmd/go/"><code>go</code></a> command has a new subcommand,
|
|
<a href="/cmd/go/#hdr-Generate_Go_files_by_processing_source"><code>go generate</code></a>,
|
|
to automate the running of tools to generate source code before compilation.
|
|
For example, it can be used to run the <a href="/cmd/yacc"><code>yacc</code></a>
|
|
compiler-compiler on a <code>.y</code> file to produce the Go source file implementing the grammar,
|
|
or to automate the generation of <code>String</code> methods for typed constants using the new
|
|
<a href="http://godoc.org/golang.org/x/tools/cmd/stringer">stringer</a>
|
|
tool in the <code>golang.org/x/tools</code> subrepository.
|
|
</p>
|
|
|
|
<p>
|
|
For more information, see the
|
|
<a href="https://golang.org/s/go1.4-generate">design document</a>.
|
|
</p>
|
|
|
|
<h3 id="filenames">Change to file name handling</h3>
|
|
|
|
<p>
|
|
Build constraints, also known as build tags, control compilation by including or excluding files
|
|
(see the documentation <a href="/pkg/go/build/"><code>/go/build</code></a>).
|
|
Compilation can also be controlled by the name of the file itself by "tagging" the file with
|
|
a suffix (before the <code>.go</code> or <code>.s</code> extension) with an underscore
|
|
and the name of the architecture or operating system.
|
|
For instance, the file <code>gopher_arm.go</code> will only be compiled if the target
|
|
processor is an ARM.
|
|
</p>
|
|
|
|
<p>
|
|
Before Go 1.4, a file called just <code>arm.go</code> was similarly tagged, but this behavior
|
|
can break sources when new architectures are added, causing files to suddenly become tagged.
|
|
In 1.4, therefore, a file will be tagged in this manner only if the tag (architecture or operating
|
|
system name) is preceded by an underscore.
|
|
</p>
|
|
|
|
<p>
|
|
<em>Updating</em>: Packages that depend on the old behavior will no longer compile correctly.
|
|
Files with names like <code>windows.go</code> or <code>amd64.go</code> should either
|
|
have explicit build tags added to the source or be renamed to something like
|
|
<code>os_windows.go</code> or <code>support_amd64.go</code>.
|
|
</p>
|
|
|
|
<h3 id="gocmd">Other changes to the go command</h3>
|
|
|
|
<p>
|
|
There were a number of minor changes to the
|
|
<a href="/cmd/go/"><code>cmd/go</code></a>
|
|
command worth noting.
|
|
</p>
|
|
|
|
<ul>
|
|
|
|
<li>
|
|
Unless <a href="/cmd/cgo/"><code>cgo</code></a> is being used to build the package,
|
|
the <code>go</code> command now refuses to compile C source files,
|
|
since the relevant C compilers
|
|
(<a href="/cmd/6c/"><code>6c</code></a> etc.)
|
|
are intended to be removed from the installation in some future release.
|
|
(They are used today only to build part of the runtime.)
|
|
It is difficult to use them correctly in any case, so any extant uses are likely incorrect,
|
|
so we have disabled them.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/cmd/go/#hdr-Test_packages"><code>go</code> <code>test</code></a>
|
|
subcommand has a new flag, <code>-o</code>, to set the name of the resulting binary,
|
|
corresponding to the same flag in other subcommands.
|
|
The non-functional <code>-file</code> flag has been removed.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/cmd/go/#hdr-Test_packages"><code>go</code> <code>test</code></a>
|
|
subcommand will compile and link all <code>*_test.go</code> files in the package,
|
|
even when there are no <code>Test</code> functions in them.
|
|
It previously ignored such files.
|
|
</li>
|
|
|
|
<li>
|
|
The behavior of the
|
|
<a href="/cmd/go/#hdr-Test_packages"><code>go</code> <code>build</code></a>
|
|
subcommand's
|
|
<code>-a</code> flag has been changed for non-development installations.
|
|
For installations running a released distribution, the <code>-a</code> flag will no longer
|
|
rebuild the standard library and commands, to avoid overwriting the installation's files.
|
|
</li>
|
|
|
|
</ul>
|
|
|
|
<h3 id="pkg">Changes to package source layout</h3>
|
|
|
|
<p>
|
|
In the main Go source repository, the source code for the packages was kept in
|
|
the directory <code>src/pkg</code>, which made sense but differed from
|
|
other repositories, including the Go subrepositories.
|
|
In Go 1.4, the<code> pkg</code> level of the source tree is now gone, so for example
|
|
the <a href="/pkg/fmt/"><code>fmt</code></a> package's source, once kept in
|
|
directory <code>src/pkg/fmt</code>, now lives one level higher in <code>src/fmt</code>.
|
|
</p>
|
|
|
|
<p>
|
|
<em>Updating</em>: Tools like <code>godoc</code> that discover source code
|
|
need to know about the new location. All tools and services maintained by the Go team
|
|
have been updated.
|
|
</p>
|
|
|
|
|
|
<h3 id="swig">SWIG</h3>
|
|
|
|
<p>
|
|
Due to runtime changes in this release, Go 1.4 requires SWIG 3.0.3.
|
|
</p>
|
|
|
|
<h3 id="misc">Miscellany</h3>
|
|
|
|
<p>
|
|
The standard repository's top-level <code>misc</code> directory used to contain
|
|
Go support for editors and IDEs: plugins, initialization scripts and so on.
|
|
Maintaining these was becoming time-consuming
|
|
and needed external help because many of the editors listed were not used by
|
|
members of the core team.
|
|
It also required us to make decisions about which plugin was best for a given
|
|
editor, even for editors we do not use.
|
|
</p>
|
|
|
|
<p>
|
|
The Go community at large is much better suited to managing this information.
|
|
In Go 1.4, therefore, this support has been removed from the repository.
|
|
Instead, there is a curated, informative list of what's available on
|
|
a <a href="//golang.org/wiki/IDEsAndTextEditorPlugins">wiki page</a>.
|
|
</p>
|
|
|
|
<h2 id="performance">Performance</h2>
|
|
|
|
<p>
|
|
Most programs will run about the same speed or slightly faster in 1.4 than in 1.3;
|
|
some will be slightly slower.
|
|
There are many changes, making it hard to be precise about what to expect.
|
|
</p>
|
|
|
|
<p>
|
|
As mentioned above, much of the runtime was translated to Go from C,
|
|
which led to some reduction in heap sizes.
|
|
It also improved performance slightly because the Go compiler is better
|
|
at optimization, due to things like inlining, than the C compiler used to build
|
|
the runtime.
|
|
</p>
|
|
|
|
<p>
|
|
The garbage collector was sped up, leading to measurable improvements for
|
|
garbage-heavy programs.
|
|
On the other hand, the new write barriers slow things down again, typically
|
|
by about the same amount but, depending on their behavior, some programs
|
|
may be somewhat slower or faster.
|
|
</p>
|
|
|
|
<p>
|
|
Library changes that affect performance are documented below.
|
|
</p>
|
|
|
|
<h2 id="library">Changes to the standard library</h2>
|
|
|
|
<h3 id="new_packages">New packages</h3>
|
|
|
|
<p>
|
|
There are no new packages in this release.
|
|
</p>
|
|
|
|
<h3 id="major_library_changes">Major changes to the library</h3>
|
|
|
|
<h4 id="scanner">bufio.Scanner</h4>
|
|
|
|
<p>
|
|
The <a href="/pkg/bufio/#Scanner"><code>Scanner</code></a> type in the
|
|
<a href="/pkg/bufio/"><code>bufio</code></a> package
|
|
has had a bug fixed that may require changes to custom
|
|
<a href="/pkg/bufio/#SplitFunc"><code>split functions</code></a>.
|
|
The bug made it impossible to generate an empty token at EOF; the fix
|
|
changes the end conditions seen by the split function.
|
|
Previously, scanning stopped at EOF if there was no more data.
|
|
As of 1.4, the split function will be called once at EOF after input is exhausted,
|
|
so the split function can generate a final empty token
|
|
as the documentation already promised.
|
|
</p>
|
|
|
|
<p>
|
|
<em>Updating</em>: Custom split functions may need to be modified to
|
|
handle empty tokens at EOF as desired.
|
|
</p>
|
|
|
|
<h4 id="syscall">syscall</h4>
|
|
|
|
<p>
|
|
The <a href="/pkg/syscall/"><code>syscall</code></a> package is now frozen except
|
|
for changes needed to maintain the core repository.
|
|
In particular, it will no longer be extended to support new or different system calls
|
|
that are not used by the core.
|
|
The reasons are described at length in <a href="https://golang.org/s/go1.4-syscall">a
|
|
separate document</a>.
|
|
</p>
|
|
|
|
<p>
|
|
A new subrepository, <a href="https://golang.org/x/sys">golang.org/x/sys</a>,
|
|
has been created to serve as the location for new developments to support system
|
|
calls on all kernels.
|
|
It has a nicer structure, with three packages that each hold the implementation of
|
|
system calls for one of
|
|
<a href="http://godoc.org/golang.org/x/sys/unix">Unix</a>,
|
|
<a href="http://godoc.org/golang.org/x/sys/windows">Windows</a> and
|
|
<a href="http://godoc.org/golang.org/x/sys/plan9">Plan 9</a>.
|
|
These packages will be curated more generously, accepting all reasonable changes
|
|
that reflect kernel interfaces in those operating systems.
|
|
See the documentation and the article mentioned above for more information.
|
|
</p>
|
|
|
|
<p>
|
|
<em>Updating</em>: Existing programs are not affected as the <code>syscall</code>
|
|
package is largely unchanged from the 1.3 release.
|
|
Future development that requires system calls not in the <code>syscall</code> package
|
|
should build on <code>golang.org/x/sys</code> instead.
|
|
</p>
|
|
|
|
<h3 id="minor_library_changes">Minor changes to the library</h3>
|
|
|
|
<p>
|
|
The following list summarizes a number of minor changes to the library, mostly additions.
|
|
See the relevant package documentation for more information about each change.
|
|
</p>
|
|
|
|
<ul>
|
|
|
|
<li>
|
|
The <a href="/pkg/archive/zip/"><code>archive/zip</code></a> package's
|
|
<a href="/pkg/archive/zip/#Writer"><code>Writer</code></a> now supports a
|
|
<a href="/pkg/archive/zip/#Writer.Flush"><code>Flush</code></a> method.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/compress/flate/"><code>compress/flate</code></a>,
|
|
<a href="/pkg/compress/gzip/"><code>compress/gzip</code></a>,
|
|
and <a href="/pkg/compress/zlib/"><code>compress/zlib</code></a>
|
|
packages now support a <code>Reset</code> method
|
|
for the decompressors, allowing them to reuse buffers and improve performance.
|
|
The <a href="/pkg/compress/gzip/"><code>compress/gzip</code></a> package also has a
|
|
<a href="/pkg/compress/gzip/#Reader.Multistream"><code>Multistream</code></a> method to control support
|
|
for multistream files.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/crypto/"><code>crypto</code></a> package now has a
|
|
<a href="/pkg/crypto/#Signer"><code>Signer</code></a> interface, implemented by the
|
|
<code>PrivateKey</code> types in
|
|
<a href="/pkg/crypto/ecdsa"><code>crypto/ecdsa</code></a> and
|
|
<a href="/pkg/crypto/rsa"><code>crypto/rsa</code></a>.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/crypto/tls/"><code>crypto/tls</code></a> package
|
|
now supports ALPN as defined in <a href="http://tools.ietf.org/html/rfc7301">RFC 7301</a>.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/crypto/tls/"><code>crypto/tls</code></a> package
|
|
now supports programmatic selection of server certificates
|
|
through the new <a href="/pkg/crypto/tls/#Config.CertificateForName"><code>CertificateForName</code></a> function
|
|
of the <a href="/pkg/crypto/tls/#Config"><code>Config</code></a> struct.
|
|
</li>
|
|
|
|
<li>
|
|
Also in the crypto/tls package, the server now supports
|
|
<a href="https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00">TLS_FALLBACK_SCSV</a>
|
|
to help clients detect fallback attacks.
|
|
(The Go client does not support fallback at all, so it is not vulnerable to
|
|
those attacks.)
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/database/sql/"><code>database/sql</code></a> package can now list all registered
|
|
<a href="/pkg/database/sql/#Drivers"><code>Drivers</code></a>.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/debug/dwarf/"><code>debug/dwarf</code></a> package now supports
|
|
<a href="/pkg/debug/dwarf/#UnspecifiedType"><code>UnspecifiedType</code></a>s.
|
|
</li>
|
|
|
|
<li>
|
|
In the <a href="/pkg/encoding/asn1/"><code>encoding/asn1</code></a> package,
|
|
optional elements with a default value will now only be omitted if they have that value.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/encoding/csv/"><code>encoding/csv</code></a> package no longer
|
|
quotes empty strings but does quote the end-of-data marker <code>\.</code> (backslash dot).
|
|
This is permitted by the definition of CSV and allows it to work better with Postgres.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/encoding/gob/"><code>encoding/gob</code></a> package has been rewritten to eliminate
|
|
the use of unsafe operations, allowing it to be used in environments that do not permit use of the
|
|
<a href="/pkg/unsafe/"><code>unsafe</code></a> package.
|
|
For typical uses it will be 10-30% slower, but the delta is dependent on the type of the data and
|
|
in some cases, especially involving arrays, it can be faster.
|
|
There is no functional change.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/encoding/xml/"><code>encoding/xml</code></a> package's
|
|
<a href="/pkg/encoding/xml/#Decoder"><code>Decoder</code></a> can now report its input offset.
|
|
</li>
|
|
|
|
<li>
|
|
In the <a href="/pkg/fmt/"><code>fmt</code></a> package,
|
|
formatting of pointers to maps has changed to be consistent with that of pointers
|
|
to structs, arrays, and so on.
|
|
For instance, <code>&map[string]int{"one":</code> <code>1}</code> now prints by default as
|
|
<code>&map[one:</code> <code>1]</code> rather than as a hexadecimal pointer value.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/image/"><code>image</code></a> package's
|
|
<a href="/pkg/image/#Image"><code>Image</code></a>
|
|
implementations like
|
|
<a href="/pkg/image/#RGBA"><code>RGBA</code></a> and
|
|
<a href="/pkg/image/#Gray"><code>Gray</code></a> have specialized
|
|
<a href="/pkg/image/#RGBA.RGBAAt"><code>RGBAAt</code></a> and
|
|
<a href="/pkg/image/#Gray.GrayAt"><code>GrayAt</code></a> methods alongside the general
|
|
<a href="/pkg/image/#Image.At"><code>At</code></a> method.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/image/png/"><code>image/png</code></a> package now has an
|
|
<a href="/pkg/image/png/#Encoder"><code>Encoder</code></a>
|
|
type to control the compression level used for encoding.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/math/"><code>math</code></a> package now has a
|
|
<a href="/pkg/math/#Nextafter32"><code>Nextafter32</code><a/> function.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/net/http/"><code>net/http</code></a> package's
|
|
<a href="/pkg/net/http/#Request"><code>Request</code></a> type
|
|
has a new <a href="/pkg/net/http/#Request.BasicAuth"><code>BasicAuth</code></a> method
|
|
that returns the username and password from authenticated requests using the
|
|
HTTP Basic Authentication
|
|
Scheme.
|
|
</li>
|
|
|
|
<li>The <a href="/pkg/net/http/"><code>net/http</code></a> package's
|
|
<a href="/pkg/net/http/#Request"><code>Transport</code></a> type
|
|
has a new <a href="/pkg/net/http/#Transport.DialTLS"><code>DialTLS</code></a> hook
|
|
that allows customizing the behavior of outbound TLS connections.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/net/http/httputil/"><code>net/http/httputil</code></a> package's
|
|
<a href="/pkg/net/http/httputil/#ReverseProxy"><code>ReverseProxy</code></a> type
|
|
has a new field,
|
|
<a href="/pkg/net/http/#ReverseProxy.ErrorLog"><code>ErrorLog</code></a>, that
|
|
provides user control of logging.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/os/"><code>os</code></a> package
|
|
now implements symbolic links on the Windows operating system
|
|
through the <a href="/pkg/os/#Symlink"><code>Symlink</code></a> function.
|
|
Other operating systems already have this functionality.
|
|
There is also a new <a href="/pkg/os/#Unsetenv"><code>Unsetenv</code></a> function.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/reflect/"><code>reflect</code></a> package's
|
|
<a href="/pkg/reflect/#Type"><code>Type</code></a> interface
|
|
has a new method, <a href="/pkg/reflect/#type.Comparable"><code>Comparable</code></a>,
|
|
that reports whether the type implements general comparisons.
|
|
</li>
|
|
|
|
<li>
|
|
Also in the <a href="/pkg/reflect/"><code>reflect</code></a> package, the
|
|
<a href="/pkg/reflect/#Value"><code>Value</code></a> interface is now three instead of four words
|
|
because of changes to the implementation of interfaces in the runtime.
|
|
This saves memory but has no semantic effect.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/runtime/"><code>runtime</code></a> package
|
|
now implements monotonic clocks on Windows,
|
|
as it already did for the other systems.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/runtime/"><code>runtime</code></a> package's
|
|
<a href="/pkg/runtime/#MemStats.Mallocs"><code>Mallocs</code></a> counter
|
|
now counts very small allocations that were missed in Go 1.3.
|
|
This may break tests using <a href="/pkg/runtime/#ReadMemStats"><code>ReadMemStats</code></a>
|
|
or <a href="/pkg/testing/#AllocsPerRun"><code>AllocsPerRun</code></a>
|
|
due to the more accurate answer.
|
|
</li>
|
|
|
|
<li>
|
|
In the <a href="/pkg/runtime/"><code>runtime</code></a> package,
|
|
an array <a href="/pkg/runtime/#MemStats.PauseEnd"><code>PauseEnd</code></a>
|
|
has been added to the
|
|
<a href="/pkg/runtime/#MemStats"><code>MemStats</code></a>
|
|
and <a href="/pkg/runtime/#GCStats"><code>GCStats</code></a> structs.
|
|
This array is a circular buffer of times when garbage collection pauses ended.
|
|
The corresponding pause durations are already recorded in
|
|
<a href="/pkg/runtime/#MemStats.PauseNs"><code>PauseNs</code></a>
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/runtime/race/"><code>runtime/race</code></a> package
|
|
now supports FreeBSD, which means the
|
|
<a href="/pkg/cmd/go/"><code>go</code></a> command's <code>-race</code>
|
|
flag now works on FreeBSD.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/sync/atomic/"><code>sync/atomic</code></a> package
|
|
has a new type, <a href="/pkg/sync/atomic/#Value"><code>Value</code></a>.
|
|
<code>Value</code> provides an efficient mechanism for atomic loads and
|
|
stores of values of arbitrary type.
|
|
</li>
|
|
|
|
<li>
|
|
In the <a href="/pkg/syscall/"><code>syscall</code></a> package's
|
|
implementation on Linux, the
|
|
<a href="/pkg/syscall/#Setuid"><code>Setuid</code></a>
|
|
and <a href="/pkg/syscall/#Setgid"><code>Setgid</code></a> have been disabled
|
|
because those system calls operate on the calling thread, not the whole process, which is
|
|
different from other platforms and not the expected result.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/testing/"><code>testing</code></a> package
|
|
has a new facility to provide more control over running a set of tests.
|
|
If the test code contains a function
|
|
<pre>
|
|
func TestMain(m *<a href="/pkg/testing/#M"><code>testing.M</code></a>)
|
|
</pre>
|
|
|
|
that function will be called instead of running the tests directly.
|
|
The <code>M</code> struct contains methods to access and run the tests.
|
|
</li>
|
|
|
|
<li>
|
|
Also in the <a href="/pkg/testing/"><code>testing</code></a> package,
|
|
a new <a href="/pkg/testing/#Coverage"><code>Coverage</code></a>
|
|
function reports the current test coverage fraction,
|
|
enabling individual tests to report how much they are contributing to the
|
|
overall coverage.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/text/scanner/"><code>text/scanner</code></a> package's
|
|
<a href="/pkg/text/scanner/#Scanner"><code>Scanner</code></a> type
|
|
has a new function,
|
|
<a href="/pkg/text/scanner/#Scanner.IsIdentRune"><code>IsIdentRune</code></a>,
|
|
allowing one to control the definition of an identifier when scanning.
|
|
</li>
|
|
|
|
<li>
|
|
The <a href="/pkg/text/template/"><code>text/template</code></a> package's boolean
|
|
functions <code>eq</code>, <code>lt</code>, and so on have been generalized to allow comparison
|
|
of signed and unsigned integers, simplifying their use in practice.
|
|
(Previously one could only compare values of the same signedness.)
|
|
All negative values compare less than all unsigned values.
|
|
</li>
|
|
|
|
<li>
|
|
The <code>time</code> package now uses the standard symbol for the micro prefix,
|
|
the micro symbol (U+00B5 'µ'), to print microsecond durations.
|
|
<a href="/pkg/time/#ParseDuration"><code>ParseDuration</code></a> still accepts <code>us</code>
|
|
but the package no longer prints microseconds as <code>us</code>.
|
|
<br>
|
|
<em>Updating</em>: Code that depends on the output format of durations
|
|
but does not use ParseDuration will need to be updated.
|
|
</li>
|
|
|
|
</ul>
|