go/doc/go1.4.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
and contains only one tiny language change,
a possibly breaking change to the compiler,
a backwards-compatible simple form of <code>for</code>-<code>range</code> loop.
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
and TODO.
The release also adds support for ARM processors on Android and Native Client (NaCl)
and AMD64 on Plan 9.
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 k, v := range x {
	...
}
</pre>

<p>
and
</p>

<pre>
for k := 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="http://code.google.com/p/go.mobile">go.mobile</a> repository.
A brief description of the plans for this experimental port are available
<a href="/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>
Up 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="/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 to 2048 bytes from 8192 bytes.
TODO: It may be bumped to 4096 for the release.
</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>
TODO gccgo news
</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="http://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>
Further information is in
<a href="http://golang.org/s/go14customimport">the design document</a>.
</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/code.google.com/p/go.tools/cmd/stringer">stringer</a>
tool in the <code>go.tools</code> repository.
</p>

<p>
For more information, see the 
<a href="http://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="godoc">Changes to godoc</h3>
<p>
TODO godoc news
</p>

<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 sub-repositories such as <code>go.tools</code>.
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="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="https://code.google.com/p/go-wiki/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>

<p>
TODO major changes
</p>

<pre>
encoding/gob: remove unsafe (CL 102680045)
syscall: now frozen (CL 129820043); go.sys subrepo created: http://golang.org/s/go1.4-syscall
</pre>

<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> TODO changes
</li>
</ul>

<pre>

cmd/6l, liblink: use pc-relative addressing for all memory references, so that linking Go binaries at high addresses works (CL 125140043). This cuts the maximum size of a Go binary's text+data+bss from 4GB to 2GB.

bufio: handling of empty tokens at EOF changed, may require scanner change (CL 145390043)
compress/flate, compress/gzip, compress/zlib: Reset support (https://codereview.appspot.com/97140043)
crypto/tls: add support for ALPN (RFC 7301) (CL 108710046)
crypto/tls: support programmatic selection of server certificates (CL 107400043)
encoding/asn1: optional elements with a default value will now only be omitted if they have that value (CL 86960045)
fmt: print type *map[T]T as &amp;map[k:v] (CL 154870043)
encoding/csv: do not quote empty strings, quote \. (CL 164760043)
net/http: add Request.BasicAuth method (CL 76540043)
net/http: add Transport.DialTLS hook (CL 137940043)
net/http/httputil: add ReverseProxy.ErrorLog (CL 132750043)
os: implement symlink support for windows (CL 86160044)
reflect: add type.Comparable (CL 144020043)
reflect: Value is one word smaller
runtime: implement monotonic clocks on windows (CL 108700045)
runtime: MemStats.Mallocs now counts very small allocations missed in Go 1.3. This may break tests using runtime.ReadMemStats or testing.AllocsPerRun by giving a more accurate answer than Go 1.3 did (CL 143150043).
runtime/race: freebsd is supported (CL 107270043)
runtime: add PauseEnd array to MemStats and GCStats (CL 153670043)
swig: Due to runtime changes Go 1.4 will require SWIG 3.0.3 (not yet released)
sync/atomic: add Value (CL 136710045)
syscall: Setuid, Setgid are disabled on linux platforms. On linux those syscalls operate on the calling thread, not the whole process. This does not match the semantics of other platforms, nor the expectations of the caller, so the operations have been disabled until issue 1435 is resolved (CL 106170043)
testing: add Coverage (CL 98150043)
testing: add TestMain support (CL 148770043)
text/scanner: add IsIdentRune field of Scanner. (CL 108030044)
text/template: allow comparison of signed and unsigned integers (CL 149780043)
time: use the micro symbol (µ (U+00B5)) to print microsecond duration (CL 105030046)
</pre>