Compare commits

..

39 Commits

Author SHA1 Message Date
Andrew Gerrand
1cdd48c8a2 go1.3
LGTM=rsc
R=golang-codereviews, minux, rsc
CC=golang-codereviews
https://golang.org/cl/104250043
2014-06-19 10:20:01 +10:00
Andrew Gerrand
89a95c92a3 doc: document Go 1.3
TBR=r
R=golang-codereviews
CC=golang-codereviews
https://golang.org/cl/101370043
2014-06-19 09:54:26 +10:00
Andrew Gerrand
0a164d2333 [release-branch.go1.3] fmt: fix signs when zero padding.
««« CL 103480043 / 777dd5a434db
fmt: fix signs when zero padding.
Bug was introduced recently. Add more tests, fix the bugs.
Suppress + sign when not required in zero padding.
Do not zero pad infinities.
All old tests still pass.
This time for sure!
Fixes #8217.

LGTM=rsc
R=golang-codereviews, dan.kortschak, rsc
CC=golang-codereviews
https://golang.org/cl/103480043
»»»

LGTM=r, rsc
R=r, rsc
CC=golang-codereviews
https://golang.org/cl/110040043
2014-06-19 09:54:17 +10:00
Russ Cox
9d7a83a04b [release-branch.go1.3] go/build: update doc.go for go1.3 build tag.
««« CL 102470045 / f15ad332ce13
go/build: update doc.go for go1.3 build tag.

LGTM=bradfitz
R=adg, rsc, bradfitz
CC=golang-codereviews
https://golang.org/cl/102470045

»»»

LGTM=bradfitz
R=bradfitz
CC=golang-codereviews
https://golang.org/cl/105310044
2014-06-18 09:05:24 -07:00
Andrew Gerrand
60b7cd2c85 [release-branch.go1.3] doc: link to new downloads page
««« CL 102340044 / 951cc5f6d52f
doc: link to new downloads page

LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews
https://golang.org/cl/102340044
»»»

TBR=rsc
CC=golang-codereviews
https://golang.org/cl/105300045
2014-06-18 08:47:25 +10:00
Andrew Gerrand
2ae4c996a1 [release-branch.go1.3] doc: add release note for 'godoc -analysis'
««« CL 88560044 / d011c0dcae9c
doc: add release note for 'godoc -analysis'

Contains a link to /lib/godoc/analysis/help.html
which is not yet live.

LGTM=r
R=r, adg
CC=golang-codereviews
https://golang.org/cl/88560044
»»»

TBR=rsc
R=golang-codereviews
CC=golang-codereviews
https://golang.org/cl/104150043
2014-06-18 08:46:31 +10:00
Andrew Gerrand
2a3daa8bdd go1.3rc2
LGTM=minux, rsc
R=golang-codereviews, minux, rsc
CC=golang-codereviews
https://golang.org/cl/105170044
2014-06-13 13:24:50 +10:00
Russ Cox
64de40a551 [release-branch.go1.3] runtime: revise CL 105140044 (defer nil) to work on Windows
««« CL 105120044 / 824ea5943ba8
runtime: revise CL 105140044 (defer nil) to work on Windows

It appears that something about Go on Windows
cannot handle the fault cause by a jump to address 0.
The way Go represents and calls functions, this
never happened at all, until CL 105140044.

This CL changes the code added in CL 105140044
to make jump to 0 impossible once again.

Fixes #8047. (again, on Windows)

TBR=bradfitz
R=golang-codereviews, dave
CC=adg, golang-codereviews, iant, r
https://golang.org/cl/105120044
»»»

LGTM=bradfitz
R=golang-codereviews, bradfitz, alex.brainman
CC=adg, golang-codereviews
https://golang.org/cl/108890045
2014-06-12 21:52:52 -04:00
Andrew Gerrand
69616e4e5b revert go1.3rc2
The Windows build is still bad. The previous CL is not go1.3rc2.

TBR=bradfitz
R=golang-codereviews
CC=golang-codereviews
https://golang.org/cl/107050043
2014-06-13 10:12:29 +10:00
Andrew Gerrand
4dc991cd3f go1.3rc2
LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/103420043
2014-06-13 09:41:58 +10:00
Russ Cox
1305c4ce9d [release-branch.go1.3] runtime: do not trace past jmpdefer during pprof traceback on arm
««« CL 107970043 / b336da131a84
runtime: do not trace past jmpdefer during pprof traceback on arm

jmpdefer modifies PC, SP, and LR, and not atomically,
so walking past jmpdefer will often end up in a state
where the three are not a consistent execution snapshot.
This was causing warning messages a few frames later
when the traceback realized it was confused, but given
the right memory it could easily crash instead.

Update #8153

LGTM=minux, iant
R=golang-codereviews, minux, iant
CC=golang-codereviews, r
https://golang.org/cl/107970043
»»»

LGTM=r
R=golang-codereviews, r
CC=adg, golang-codereviews, iant
https://golang.org/cl/101260043
2014-06-12 16:55:36 -04:00
Russ Cox
5c196b842a [release-branch.go1.3] runtime: fix defer of nil func
««« CL 105140044 / c2832405e9b9
runtime: fix defer of nil func

Fixes #8047.

LGTM=r, iant
R=golang-codereviews, r, iant
CC=dvyukov, golang-codereviews, khr
https://golang.org/cl/105140044
»»»

LGTM=r
R=golang-codereviews, r
CC=adg, golang-codereviews, iant
https://golang.org/cl/103370044
2014-06-12 16:55:24 -04:00
Russ Cox
ad02e9ade5 [release-branch.go1.3] doc: link to release history from /doc/
««« CL 107950043 / 593f58ee96da
doc: link to release history from /doc/

Fixes #8168.

TBR=bradfitz
R=golang-codereviews
CC=golang-codereviews
https://golang.org/cl/107950043
»»»

LGTM=r
R=golang-codereviews, r
CC=adg, golang-codereviews, iant
https://golang.org/cl/105910043
2014-06-12 16:55:11 -04:00
Russ Cox
e0d5179635 [release-branch.go1.3] runtime: add test for issue 8047.
««« CL 108840043 / 3a2306461574
runtime: add test for issue 8047.

Make sure stack copier doesn't barf on a nil defer.
Bug was fixed in https://golang.org/cl/101800043
This change just adds a test.

Fixes #8047

LGTM=dvyukov, rsc
R=dvyukov, rsc
CC=golang-codereviews
https://golang.org/cl/108840043

»»»

TBR=adg
CC=golang-codereviews
https://golang.org/cl/102320043
2014-06-11 20:42:13 -04:00
Russ Cox
23f6bc5ed8 [release-branch.go1.3] net/http: fix double Content-Length in response
««« CL 105040043 / ef8878dbed3b
net/http: fix double Content-Length in response

Fixes #8180

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/105040043
»»»

TBR=bradfitz
R=golang-codereviews
CC=bradfitz, golang-codereviews, iant
https://golang.org/cl/102300046
2014-06-11 17:02:43 -04:00
Russ Cox
74183c5b06 [release-branch.go1.3] doc/install.html: fix erroneous HTML annotation
««« CL 106910044 / ac907318915d
doc/install.html: fix erroneous HTML annotation
align=middle is invalid; use align=center

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/106910044
»»»

LGTM=r
R=golang-codereviews, r
CC=bradfitz, golang-codereviews, iant
https://golang.org/cl/108860047
2014-06-11 17:00:27 -04:00
Russ Cox
8ef4135731 [release-branch.go1.3] cmd/gc: two escape analysis fixes
««« CL 108860043 / f153208c0a0e
cmd/gc: fix escape analysis for &x inside switch x := v.(type)

The analysis for &x was using the loop depth on x set
during x's declaration. A type switch creates a list of
implicit declarations that were not getting initialized
with loop depths.

Fixes #8176.

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/108860043
»»»

««« CL 108870044 / 331dbd4a6334
cmd/gc: fix &result escaping into result

There is a hierarchy of location defined by loop depth:

        -1 = the heap
        0 = function results
        1 = local variables (and parameters)
        2 = local variable declared inside a loop
        3 = local variable declared inside a loop inside a loop
        etc

In general if an address from loopdepth n is assigned to
something in loop depth m < n, that indicates an extended
lifetime of some form that requires a heap allocation.

Function results can be local variables too, though, and so
they don't actually fit into the hierarchy very well.
Treat the address of a function result as level 1 so that
if it is written back into a result, the address is treated
as escaping.

Fixes  issue 8185 .

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/108870044
»»»

LGTM=r
R=golang-codereviews, r
CC=bradfitz, golang-codereviews, iant
https://golang.org/cl/107930044
2014-06-11 17:00:17 -04:00
Russ Cox
16367614fb [release-branch.go1.3] cmd/ld: fix PC deltas in DWARF line number table
««« CL 104950045 / 87daa424d96a
cmd/ld: fix PC deltas in DWARF line number table

The putpclcdelta function set the DWARF line number PC to
s->value + pcline->pc, which is correct, but the code then set
the local variable pc to epc, which can be a different value.
This caused the next delta in the DWARF table to be wrong.

Fixes #8098.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/104950045
»»»

LGTM=r
R=golang-codereviews, r
CC=bradfitz, golang-codereviews, iant
https://golang.org/cl/107900045
2014-06-11 16:55:38 -04:00
Russ Cox
cbffba160c [release-branch.go1.3] nacltest.bash, misc/nacl/README: update NaCl docs.
««« CL 105030043 / 6146799f32ed
nacltest.bash, misc/nacl/README: update NaCl docs.

LGTM=rsc
R=dave, rsc
CC=golang-codereviews
https://golang.org/cl/105030043
»»»

LGTM=r
R=golang-codereviews, r
CC=bradfitz, golang-codereviews, iant
https://golang.org/cl/105020044
2014-06-11 16:55:24 -04:00
Russ Cox
37a84af3d3 [release-branch.go1.3] docs: link to the assembler document from the Documents tab
««« CL 108840045 / 087e446f2c41
docs: link to the assembler document from the Documents tab

Fixes #8156.

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/108840045
»»»

LGTM=r
R=golang-codereviews, r
CC=bradfitz, golang-codereviews, iant
https://golang.org/cl/101170045
2014-06-11 16:55:04 -04:00
Russ Cox
c70654f7e1 [release-branch.go1.3] runtime: fix panic stack during runtime.Goexit during panic
««« CL 102220043 / 00224712f89e
runtime: fix panic stack during runtime.Goexit during panic

A runtime.Goexit during a panic-invoked deferred call
left the panic stack intact even though all the stack frames
are gone when the goroutine is torn down.
The next goroutine to reuse that struct will have a
bogus panic stack and can cause the traceback routines
to walk into garbage.

Most likely to happen during tests, because t.Fatal might
be called during a deferred func and uses runtime.Goexit.

This "not enough cleared in Goexit" failure mode has
happened to us multiple times now. Clear all the pointers
that don't make sense to keep, not just gp->panic.

Fixes #8158.

LGTM=iant, dvyukov
R=iant, dvyukov
CC=golang-codereviews
https://golang.org/cl/102220043
»»»

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, r
https://golang.org/cl/108780044
2014-06-06 22:07:32 -04:00
Russ Cox
e16c88a5e7 [release-branch.go1.3] cmd/6g: fix stack zeroing on native client
««« CL 108740047 / c8e9255aed3f
cmd/6g: fix stack zeroing on native client

I am not sure what the rounding here was
trying to do, but it was skipping the first
pointer on native client.

The code above the rounding already checks
that xoffset is widthptr-aligned, so the rnd
was a no-op everywhere but on Native Client.
And on Native Client it was wrong.

Perhaps it was supposed to be rounding down,
not up, but zerorange handles the extra 32 bits
correctly, so the rnd does not seem to be necessary
at all.

This wouldn't be worth doing for Go 1.3 except
that it can affect code on the playground.

Fixes #8155.

LGTM=r, iant
R=golang-codereviews, r, iant
CC=dvyukov, golang-codereviews, khr
https://golang.org/cl/108740047
»»»

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, r
https://golang.org/cl/107830044
2014-06-06 22:07:21 -04:00
Russ Cox
2dbe352b0f [release-branch.go1.3] doc: fix happens-before rules for buffered channels
««« CL 101980047 / 12c9a9ff50d8
doc: fix happens-before rules for buffered channels
The current wording is reversed in 2 places.
Not sure how it got 4 LGTMs (mine was there as well).
Update #6242.

LGTM=dan.kortschak, r, rsc
R=golang-codereviews, 0xjnml, dan.kortschak, r, rsc
CC=golang-codereviews
https://golang.org/cl/101980047
»»»

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, r
https://golang.org/cl/106830047
2014-06-06 22:07:11 -04:00
Russ Cox
dd58096ae6 [release-branch.go1.3] cmd/cgo: for typedef of untagged struct, use typedef name in C code
««« CL 103080043 / 5e058e21b67d
cmd/cgo: for typedef of untagged struct, use typedef name in C code

Fixes #8148.

LGTM=cookieo9, rsc
R=rsc, cookieo9
CC=golang-codereviews
https://golang.org/cl/103080043
»»»

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, r
https://golang.org/cl/103900046
2014-06-06 22:06:57 -04:00
Shenghou Ma
e1e3e705a6 [release-branch.go1.3] doc/install-source.html: document that GO386 will be auto-detected when building on both 386 and amd64.
««« CL 102150046 / ccf7893cc2f0
doc/install-source.html: document that GO386 will be auto-detected when building on both 386 and amd64.
Fixes #8152.

LGTM=iant
R=iant
CC=golang-codereviews
https://golang.org/cl/102150046
»»»

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/105830044
2014-06-04 21:19:54 -04:00
David Symonds
d7f399919e [release-branch.go1.3] debug/elf: support DWARF that needs relocs for 386
««« CL 96680045 / 5439c77d4acb
debug/elf: support DWARF that needs relocs for 386

It's not clear how widespread this issue is, but we do have a
test case generated by a development version of clang.

I don't know whether this should go into 1.3 or not; happy to
hear arguments either way.

LGTM=rsc
R=golang-codereviews, bradfitz, rsc
CC=golang-codereviews
https://golang.org/cl/96680045
»»»

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/102140043
2014-06-04 11:23:24 +10:00
David Symonds
6e3d786dbf [release-branch.go1.3] compress/gzip: allow Reset on Reader without NewReader
««« CL 103020044 / 318b56ffe04b
compress/gzip: allow Reset on Reader without NewReader

Fixes #8126.

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/103020044
»»»

TBR=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/105820043
2014-06-04 11:21:08 +10:00
Russ Cox
764cb069db [release-branch.go1.3] crypto/tls: fix typo referencing the required Config field
««« CL 107740043 / d86ec79a5f30
crypto/tls: fix typo referencing the required Config field

Thanks to Frithjof Schulze for noticing.

LGTM=adg
R=adg
CC=agl, golang-codereviews, r
https://golang.org/cl/107740043

»»»

LGTM=r
R=golang-codereviews, r
CC=bradfitz, golang-codereviews, iant
https://golang.org/cl/103020043
2014-06-03 14:44:25 -04:00
Russ Cox
9381fe2d1d [release-branch.go1.3] cmd/gc: fix escape analysis of func returning indirect of parameter
««« CL 102040046 / a078b2056ebc
cmd/gc: fix escape analysis of func returning indirect of parameter

I introduced this bug when I changed the escape
analysis to run in phases based on call graph
dependency order, in order to be more precise about
inputs escaping back to outputs (functions returning
their arguments).

Given

        func f(z **int) *int { return *z }

we were tagging the function as 'z does not escape
and is not returned', which is all true, but not
enough information.

If used as:

        var x int
        p := &x
        q := &p
        leak(f(q))

then the compiler might try to keep x, p, and q all
on the stack, since (according to the recorded
information) nothing interesting ends up being
passed to leak.

In fact since f returns *q = p, &x is passed to leak
and x needs to be heap allocated.

To trigger the bug, you need a chain that the
compiler wants to keep on the stack (like x, p, q
above), and you need a function that returns an
indirect of its argument, and you need to pass the
head of the chain to that function. This doesn't
come up very often: this bug has been present since
June 2012 (between Go 1 and Go 1.1) and we haven't
seen it until now. It helps that most functions that
return indirects are getters that are simple enough
to be inlined, avoiding the bug.

Earlier versions of Go also had the benefit that if
&x really wasn't used beyond x's lifetime, nothing
broke if you put &x in a heap-allocated structure
accidentally. With the new stack copying, though,
heap-allocated structures containing &x are not
updated when the stack is copied and x moves,
leading to crashes in Go 1.3 that were not crashes
in Go 1.2 or Go 1.1.

The fix is in two parts.

First, in the analysis of a function, recognize when
a value obtained via indirect of a parameter ends up
being returned. Mark those parameters as having
content escape back to the return results (but we
don't bother to write down which result).

Second, when using the analysis to analyze, say,
f(q), mark parameters with content escaping as
having any indirections escape to the heap. (We
don't bother trying to match the content to the
return value.)

The fix could be less precise (simpler).
In the first part we might mark all content-escaping
parameters as plain escaping, and then the second
part could be dropped. Or we might assume that when
calling f(q) all the things pointed at by q escape
always (for any f and q).

The fix could also be more precise (more complex).
We might record the specific mapping from parameter
to result along with the number of indirects from the
parameter to the thing being returned as the result,
and then at the call sites we could set up exactly the
right graph for the called function. That would make
notleaks(f(q)) be able to keep x on the stack, because
the reuslt of f(q) isn't passed to anything that leaks it.

The less precise the fix, the more stack allocations
become heap allocations.

This fix is exactly as precise as it needs to be so that
none of the current stack allocations in the standard
library turn into heap allocations.

Fixes #8120.

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, khr, r
https://golang.org/cl/102040046
»»»

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/103870043
2014-06-03 14:42:14 -04:00
David Symonds
53479b823c [release-branch.go1.3] time: support version 3 zone records
««« CL 100930044 / fde405c62fca
time: support version 3 zone records

Fixes #8134

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews, r, rsc
https://golang.org/cl/100930044
»»»

LGTM=rsc
R=adg, rsc
CC=golang-codereviews
https://golang.org/cl/96690043
2014-06-03 16:13:38 +10:00
David Symonds
a1fa208f79 [release-branch.go1.3] cmd/gc: fix liveness for address-taken variables in inlined functions
««« CL 96670046 / 1bec455e95f1
cmd/gc: fix liveness for address-taken variables in inlined functions

The 'address taken' bit in a function variable was not
propagating into the inlined copies, causing incorrect
liveness information.

LGTM=dsymonds, bradfitz
R=golang-codereviews, bradfitz
CC=dsymonds, golang-codereviews, iant, khr, r
https://golang.org/cl/96670046
»»»

TBR=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/103810046
2014-06-03 11:30:20 +10:00
David Symonds
f096cad531 [release-branch.go1.3] runtime: fix 1-byte return during x.(T) for 0-byte T
««« CL 100940043 / 93baf7bea171
runtime: fix 1-byte return during x.(T) for 0-byte T

The 1-byte write was silently clearing a byte on the stack.
If there was another function call with more arguments
in the same stack frame, no harm done.
Otherwise, if the variable at that location was already zero,
no harm done.
Otherwise, problems.

Fixes #8139.

LGTM=dsymonds
R=golang-codereviews, dsymonds
CC=golang-codereviews, iant, r
https://golang.org/cl/100940043
»»»

TBR=adg
CC=golang-codereviews
https://golang.org/cl/105760045
2014-06-03 11:20:32 +10:00
David Symonds
f34a051afc [release-branch.go1.3] cmd/gc: don't generate zillions of linehists for wrapper functions
««« CL 104840043 / 876107512a67
cmd/gc: don't generate zillions of linehists for wrapper functions
This is a workaround - the code should be better than this - but the
fix avoids generating large numbers of linehist entries for the wrapper
functions that enable interface conversions. There can be many of
them, they all happen at the end of compilation, and they can all
share a linehist entry.
Avoids bad n^2 behavior in liblink.
Test case in issue 8135 goes from 64 seconds to 2.5 seconds (still bad
but not intolerable).

Fixes #8135.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/104840043
»»»

TBR=adg
CC=golang-codereviews
https://golang.org/cl/102070045
2014-06-03 11:19:11 +10:00
David Symonds
e82cde2d5d [release-branch.go1.3] cmd/cgo: use same Go type for typedef to anonymous struct
««« CL 102080043 / 256d975c53cb
cmd/cgo: use same Go type for typedef to anonymous struct

If we see a typedef to an anonymous struct more than once,
presumably in two different Go files that import "C", use the
same Go type name.

Fixes #8133.

LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/102080043
»»»

TBR=adg
CC=golang-codereviews
https://golang.org/cl/102100043
2014-06-03 11:18:01 +10:00
David Symonds
4aea3f6fee [release-branch.go1.3] doc: mention WriteHeapDump in 1.3 release notes
««« CL 103810044 / 603f6c3b152c
doc: mention WriteHeapDump in 1.3 release notes

LGTM=r
R=khr, r
CC=golang-codereviews
https://golang.org/cl/103810044
»»»

TBR=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/99700043
2014-06-03 11:16:35 +10:00
Andrew Gerrand
a5565ec7d9 go1.3rc1
LGTM=minux
R=golang-codereviews, minux
CC=golang-codereviews
https://golang.org/cl/102920050
2014-06-02 14:34:50 +10:00
Andrew Gerrand
f2277d7722 [release-branch.go1.3] misc/nacl: remove cmd/link from testzip.proto
There's no cmd/link in this branch.

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/102050043
2014-06-02 13:37:16 +10:00
Andrew Gerrand
d00442aba8 [release-branch.go1.3] remove package debug/goobj and copy functionality to cmd/nm
https://golang.org/cl/103760043/
2014-06-02 13:04:43 +10:00
Andrew Gerrand
f40040b093 [release-branch.go1.3] remove cmd/link
https://golang.org/cl/106740043
2014-06-02 13:04:00 +10:00
3826 changed files with 358694 additions and 435887 deletions

10
.gitattributes vendored
View File

@@ -1,10 +0,0 @@
# Treat all files in the Go repo as binary, with no git magic updating
# line endings. Windows users contributing to Go will need to use a
# modern version of git and editors capable of LF line endings.
#
# We'll prevent accidental CRLF line endings from entering the repo
# via the git-review gofmt checks.
#
# See golang.org/issue/9281
* -text

52
.gitignore vendored
View File

@@ -1,52 +0,0 @@
.DS_Store
*.[5689ao]
*.a[5689o]
*.so
*.pyc
._*
.nfs.*
[5689a].out
*~
*.orig
*.rej
*.exe
.*.swp
core
*.cgo*.go
*.cgo*.c
_cgo_*
_obj
_test
_testmain.go
build.out
test.out
doc/articles/wiki/*.bin
include/plan9/libc_plan9.h
misc/cgo/life/run.out
misc/cgo/stdio/run.out
misc/cgo/testso/main
misc/dashboard/builder/builder
src/liblink/anames?.c
src/cmd/*/y.output
src/cmd/cgo/zdefaultcc.go
src/cmd/dist/dist.dSYM
src/cmd/gc/mkbuiltin1
src/cmd/gc/opnames.h
src/cmd/go/zdefaultcc.go
src/cmd/internal/obj/zbootstrap.go
src/go/doc/headscan
src/runtime/mkversion
src/runtime/zaexperiment.h
src/runtime/zversion.go
src/unicode/maketables
src/*.*/
test/pass.out
test/run.out
test/times.out
test/garbage/*.out
goinstall.log
last-change
VERSION.cache
bin/
pkg/

63
.hgignore Normal file
View File

@@ -0,0 +1,63 @@
syntax:glob
.DS_Store
.git
.gitignore
*.[568ao]
*.a[568o]
*.so
*.pyc
._*
.nfs.*
[568a].out
*~
*.orig
*.rej
*.exe
.*.swp
core
*.cgo*.go
*.cgo*.c
_cgo_*
_obj
_test
_testmain.go
build.out
test.out
doc/tmpltohtml
doc/articles/wiki/*.bin
include/plan9/libc_plan9.h
misc/cgo/life/run.out
misc/cgo/stdio/run.out
misc/cgo/testso/main
misc/dashboard/builder/builder
misc/goplay/goplay
misc/osx/*.pkg
misc/osx/*.dmg
src/cmd/?a/y.output
src/liblink/anames?.c
src/cmd/cc/y.output
src/cmd/cgo/zdefaultcc.go
src/cmd/dist/dist.dSYM
src/cmd/gc/mkbuiltin1
src/cmd/gc/opnames.h
src/cmd/gc/y.output
src/cmd/go/zdefaultcc.go
src/pkg/go/doc/headscan
src/pkg/runtime/goc2c
src/pkg/runtime/mkversion
src/pkg/runtime/z*
src/pkg/unicode/maketables
src/pkg/*.*/
test/pass.out
test/run.out
test/times.out
test/garbage/*.out
goinstall.log
last-change
VERSION.cache
syntax:regexp
^bin/
^pkg/
^src/cmd/(.*)/6?\1$
^.*/core.[0-9]*$

130
.hgtags Normal file
View File

@@ -0,0 +1,130 @@
1f0a01c93d305f1ab636c68b67346659c5b957f7 weekly.2009-11-06
64e703cb307da550861fe740ff70a482a2c14819 weekly.2009-11-10
b51fd2d6c16034480f26c96ba32a11c598e4638e weekly.2009-11-10.1
cb140bac9ab0fd9f734ee443cea9ebadc9c99737 weekly.2009-11-12
d1b75410b793309532352a6fb6b44453f052f3f4 weekly.2009-11-17
e205103b02e7393d4719df5faac2dac808234d3f weekly.2009-12-07
3a47d2e3882bb12129de05382a2c131bb0c00964 weekly.2009-12-09
a6fcf4303b0a92cce4011556b1c96044252d93af weekly.2009-12-22
3887d4d81bca78b63d620985d93f1cc06c063871 weekly.2010-01-05
40dd722155f6d0c83fa572c1a5abf7c6ff35049f weekly.2010-01-13
0a2770db06efe92b08b5c6f30e14b7e8db012538 weekly.2010-01-27
db4262ce882d8445764312d41547ee8f11a7f7a9 weekly.2010-02-04
53fec18b83e2b93baafba4733b59bb86b8c1988e weekly.2010-02-17
4a0661b86e50eae734dbe43ed1312c4a0304676b weekly.2010-02-23
a215d03e7ee1013b2abe3f1e2c84457ec51c68e4 weekly.2010-03-04
194d473264c1a015803d07bed200e0c312aca43e weekly.2010-03-15
9482fde11a02ffd57ba0561dc8a4ac338061a3ae weekly.2010-03-22
57380d620ee6b65eb88da1c52784b62c94d7e72e weekly.2010-03-30
f98f784927abc56a61501eba0cf225966f2b0142 weekly.2010-04-13
6cc6c0d85fc3234fc0a5ec0a8777aa9d59d05ae8 weekly.2010-04-27
17ded5ad443b41ac05924864798f1bd8750da344 weekly.2010-05-04
a85ad0a640154b5d33626ad8ea15ed17e3828178 weekly.2010-05-27
f776656df34c009f2aad142bf7b34a778404acd1 weekly.2010-06-09
113ec27f29f18825444f6f8a3cdc156c1df28e87 weekly.2010-06-21
b761e0299e9bf66298778cf170b0f64216e3cf7d weekly.2010-07-01
5992bf56aa72efcea87d8dff14985fc8fcc68575 weekly.2010-07-14
db904d88dc0ebf6ee5b55e44088915695c1223ee weekly.2010-07-29
8884f7b4c7750481ed246c249db47b61fe752c56 weekly.2010-08-04
07d3a97302be88af68acff34c8a089589da21d18 weekly.2010-08-11
18926649cda7498b8aa539b3a611abcff548f09f weekly.2010-08-25
92fcf05736e8565a485adc52da1894270e06ed09 weekly.2010-09-06
9329773e204fed50ec686ee78cc715b624bf1b1d weekly.2010-09-15
1eec33c03bceef5d7607ea4636185f7bf773e0e4 weekly.2010-09-22
c2b8c9f13fb8ad2b56920d9da2928c5314ebf725 weekly.2010-09-29
7c2e97710bf49cdbe388260958a6674afefb6c0f weekly.2010-10-13
ca4f9687cec0b9c4732afd57b8c2786c7fe242de weekly.2010-10-13.1
79997f0e5823ee9d13a34ca9971a9d8811df1c4a weekly.2010-10-20
4d5b0816392116d3a3452bb275b6dab6c6456278 weekly.2010-10-27
c627e23260c7ddf4a1fcda6ef3197c98fa22551d weekly.2010-11-02
a7800e20064a39585aa3ee339c2b7454ae1ce6d5 weekly.2010-11-10
c5287468fcff0f8a7bb9ffaece2a4863e7e5d83e weekly.2010-11-23
f7e692dc29b02fba8e5d59b967880a347b53607c weekly.2010-12-02
56e39c466cc1c49b587eb56dc2166d61151637df weekly.2010-12-08
26f4898dc1ca18bb77f9968aca23773637e34f0d weekly.2010-12-15
61b2c52b0d2246430395f2869d7b34e565333cf5 weekly.2010-12-15.1
51c777dbccb9f537ebffb99244f521c05bf65df6 weekly.2010-12-22
8eeee945e358f19405e81792db0e16a1cad14bc0 weekly.2011-01-06
514c7ba501a1dd74d69ea2d0a2b4116802ada2b5 weekly.2011-01-12
72f9cb714f08b98c6a65ab2f2256fad6bb16967a weekly.2011-01-19
d8ba80011a986470a54e5262ec125105aa4adc34 weekly.2011-01-20
5b98b59dd37292e36afb24babb2d22758928e13d weekly.2011-02-01
867d37fb41a4d96ab7a6202fd6ad54c345494051 weekly.2011-02-01.1
b2be017f91348d5f8cbaf42f77a99fc905044b59 weekly.2011-02-15
322350d6fdbf11d9c404d6fc766349d824031339 weekly.2011-02-24
21848430d60167817ca965c813a2118068ca660f weekly.2011-03-07
c5c62aeb6267e124cf05f9622e28dbd0dc6b971d weekly.2011-03-07.1
c5c62aeb6267e124cf05f9622e28dbd0dc6b971d release.r56
3b4e9c85b643a35860805718323b05186dd7f235 weekly.2011-03-15
b84e614e25161f626a6102813c41a80a15e3a625 weekly.2011-03-28
cd89452cfea3d125aaf75a1ec8004e2f6a868d38 weekly.2011-04-04
d6903b7fbff40c13ee7ea3177c0ae54c7f89d2e6 weekly.2011-04-13
2f0fa51fa2da6ab50fcebba526326153da8ed999 weekly.2011-04-27
8493bb64e5592bd20c0e60e78e7f8052c1276fcf release.r57
95d2ce135523c96c4cea049af94ce76dd8c7d981 release.r57.1
c98449d685d2b6aa1df9bfd2e1cce9307efb6e00 weekly.2011-05-22
3418f22c39eb8299053ae681199ee90f8cd29c6d weekly.2011-06-02
c81944152e973a917797679055b8fcdc70fbc802 weekly.2011-06-09
9d7967223815ef6415ff01aa0fe6ad38cdbc7810 release.r57.2
dac76f0b1a18a5de5b54a1dc0b231aceaf1c8583 weekly.2011-06-16
541c445d6c1353fbfa39df7dc4b0eb27558d1fc1 weekly.2011-06-23
1b38d90eebcddefabb3901c5bb63c7e2b04a6ec5 release.r58
16bfa562ba767aefd82e598da8b15ee4729e23b0 weekly.2011-07-07
d292bc7886682d35bb391bf572be28656baee12d release.r58.1
3c21f37b25a3f7a1726265c5339c8a7b0b329336 weekly.2011-07-19
bb28251f6da4aca85658582c370c7df89d34efd4 weekly.2011-07-29
d5785050f61d973fc36775f7bd2e26689529cb3e release.r59
c17ce5ec06b4bd5cf6e7ff2ceb0a60c2e40e0b17 weekly.2011-08-10
6eb2b9dbe489acb57a2bfc1de31ec2239ed94326 weekly.2011-08-17
c934f6f5fe8b30b4b3210ee3f13669e6e4670c32 weekly.2011-09-01
c77997547d546c36c7b969586a36de7ceda74e33 weekly.2011-09-07
b0819469a6df6029a27192fe7b19a73d97404c63 release.r60
8a09ce0cefc64deab4e6d1ed59a08a53e879bbee weekly.2011-09-16
fd30c132d1bdeb79f8f111cb721fb1c78b767b27 release.r60.1
d7322ae4d055a4cf3efaf842d0717a41acd85bac weekly.2011-09-21
32a5db19629897641b2d488de4d1b998942ef80e release.r60.2
3bdabf483805fbf0c7ef013fd09bfd6062b9d3f2 weekly.2011-10-06
c1702f36df0397c19fc333571a771666029aa37e release.r60.3
acaddf1cea75c059d19b20dbef35b20fb3f38954 release.r58.2
6d7136d74b656ba6e1194853a9486375005227ef weekly.2011-10-18
941b8015061a0f6480954821dd589c60dfe35ed1 weekly.2011-10-25
7c1f789e6efd153951e85e3f28722fc69efc2af2 weekly.2011-10-26
e69e528f2afc25a8334cfb9359fa4fcdf2a934b6 weekly.2011-11-01
780c85032b174c9d4b42adf75d82bc85af7d78d1 weekly.2011-11-02
f4397ad6e87c7ce5feac9b01686f1ebd6cbaac4e weekly.2011-11-08
2f4482b89a6b5956828872137b6b96636cd904d3 weekly.2011-11-09
b4a91b6933748db1a7150c06a1b55ad506e52906 weekly.2011-11-18
80db2da6495a20ddff8305c236825811db8c8665 weekly.2011-12-01
0beb796b4ef8747af601ed5ea6766d5b1340086b weekly.2011-12-02
0c39eee85b0d1606b79c8ebcdeb3b67ed5849e39 weekly.2011-12-06
82fdc445f2ff2c85043446eb84a19cc999dfcb95 weekly.2011-12-14
4a82689277582a2a60f006e3f158985f2f8d1da3 weekly.2011-12-22
354b17404643c0f1a710bdc48927dff02f203ae3 weekly.2012-01-15
9f2be4fbbf690b9562c6e98b91daa0003f0913c7 weekly.2012-01-20
1107a7d3cb075836387adfab5ce56d1b3e56637d weekly.2012-01-27
52ba9506bd993663a0a033c2bd68699e25d061ab weekly.2012-02-07
43cf9b39b6477d3144b0353ee91096e55db6107f weekly.2012-02-14
96bd78e7d35e892113bdfa1bdc392d3a5f2e644b weekly.2012-02-22
f4470a54e6dbcdd52d8d404e12e4754adcd2c948 weekly.2012-03-04
3cdba7b0650c6c906ef3e782654f61701abd7dd2 weekly.2012-03-13
bce220d0377405146527ab9478867cbc572a6886 weekly.2012-03-22
dc5e410f0b4c32ab11dc992593a2bcf5f607381b weekly.2012-03-27
dc5e410f0b4c32ab11dc992593a2bcf5f607381b weekly
920e9d1ffd1f46665dd152aa9cf3c0f17d68dd88 go1
2ccfd4b451d319941bfe3e08037e1462d3c15093 go1.0.1
5e806355a9e1491aaab53d3612fed4c550b130c0 go1.0.2
2d8bc3c94ecb3ec8f70556d5fd237788903c7281 go1.0.3
35da6063e57f8cefc82ba1ea542c4d9393ea9dfd go1.1rc2
5a15f0dae37931da46f0356cf4cffe775a061c12 go1.1rc3
e570c2daeaca10663d36d6dee7f8d1d76e8f7b92 go1.1
a7bd9a33067b3537351276e0178a045748ad046a go1.1.1
414057ac1f1fc850957088e4c5e95cdbccd2d594 go1.1.2
45475ec7eab1c588fc4210b34d5901b15ca1e479 go1.2rc2
7422495a6bf9d5e84828ee466406293be84f565a go1.2rc3
94af58f9fd71feda5c316d791ed11aaf015f9e82 go1.2rc4
b3d5a20b070a92da2458c5788694d1359b353f4a go1.2rc5
87dea3f5ebe7510998c84dbeeec89382b7d42f9c go1.2
0ddbdc3c7ce27e66508fe58ab81ff29324786026 go1.2.1
9c4fdd8369ca4483fbed1cb8e67f02643ca10f79 go1.2.2
f8b50ad4cac4d4c4ecf48324b4f512f65e82cc1c go1.3beta1
9e1652c32289c164126b6171f024afad5665fc9e go1.3beta2

35
AUTHORS
View File

@@ -13,11 +13,8 @@ Abhinav Gupta <abhinav.g90@gmail.com>
Adrian Nos <nos.adrian@gmail.com>
Adrian O'Grady <elpollouk@gmail.com>
Adrien Bustany <adrien-xx-google@bustany.org>
Ahmed Waheed Moanes <oneofone@gmail.com>
Akshat Kumar <seed@mail.nanosouffle.net>
Alan Shreve <alan@inconshreveable.com>
Albert Strasheim <fullung@gmail.com>
Alberto Donizetti <alb.donizetti@gmail.com>
Alberto García Hierro <alberto@garciahierro.com> <alberto.garcia.hierro@gmail.com>
Aleksandar Dezelin <dezelin@gmail.com>
Alex A Skinner <alex@lx.lc>
@@ -37,7 +34,6 @@ Amrut Joshi <amrut.joshi@gmail.com>
Andrei Vieru <euvieru@gmail.com>
Andrew Balholm <andybalholm@gmail.com>
Andrew Bonventre <andybons@chromium.org>
Andrew Bursavich <abursavich@gmail.com>
Andrew Harding <andrew@spacemonkey.com>
Andrew Lutomirski <andy@luto.us>
Andrew Pritchard <awpritchard@gmail.com>
@@ -65,7 +61,6 @@ Aulus Egnatius Varialus <varialus@gmail.com>
Ben Olive <sionide21@gmail.com>
Benjamin Black <b@b3k.us>
Benny Siegert <bsiegert@gmail.com>
Benoit Sigoure <tsunanet@gmail.com>
Berengar Lehr <berengar.lehr@gmx.de>
Billie Harold Cleek <bhcleek@gmail.com>
Bjorn Tillenius <bjorn@tillenius.me>
@@ -92,7 +87,6 @@ Chris Farmiloe <chrisfarms@gmail.com>
Chris Howey <howeyc@gmail.com>
Chris Jones <chris@cjones.org>
Chris Lennert <calennert@gmail.com>
Chris McGee <sirnewton_01@yahoo.ca> <newton688@gmail.com>
Christian Himpel <chressie@googlemail.com>
Christine Hansmann <chhansmann@gmail.com>
Christoffer Buchholz <christoffer.buchholz@gmail.com>
@@ -104,7 +98,6 @@ Christopher Wedgwood <cw@f00f.org>
Clement Skau <clementskau@gmail.com>
Conrad Meyer <cemeyer@cs.washington.edu>
Corey Thomasson <cthom.lists@gmail.com>
Cristian Staretu <unclejacksons@gmail.com>
Damian Gryski <dgryski@gmail.com>
Dan Callahan <dan.callahan@gmail.com>
Dan Peterson <dpiddy@gmail.com>
@@ -122,12 +115,10 @@ David du Colombier <0intro@gmail.com>
David Forsythe <dforsythe@gmail.com>
David G. Andersen <dave.andersen@gmail.com>
David Jakob Fritz <david.jakob.fritz@gmail.com>
David Leon Gil <coruus@gmail.com>
David Thomas <davidthomas426@gmail.com>
David Titarenco <david.titarenco@gmail.com>
Dean Prichard <dean.prichard@gmail.com>
Denis Brandolini <denis.brandolini@gmail.com>
Derek Parker <parkerderek86@gmail.com>
Devon H. O'Dell <devon.odell@gmail.com>
Dhiru Kholia <dhiru.kholia@gmail.com>
Dimitri Tcaciuc <dtcaciuc@gmail.com>
@@ -145,7 +136,7 @@ Egon Elbre <egonelbre@gmail.com>
Ehren Kret <ehren.kret@gmail.com>
Eivind Uggedal <eivind@uggedal.com>
Elias Naur <elias.naur@gmail.com>
Emil Hessman <c.emil.hessman@gmail.com> <emil@hessman.se>
Emil Hessman <c.emil.hessman@gmail.com>
Eoghan Sherry <ejsherry@gmail.com>
Eric Clark <zerohp@gmail.com>
Eric Milliken <emilliken@gmail.com>
@@ -157,8 +148,6 @@ Evan Shaw <chickencha@gmail.com>
Ewan Chou <coocood@gmail.com>
Fabrizio Milo <mistobaan@gmail.com>
Fan Hongjian <fan.howard@gmail.com>
Fastly, Inc.
Fatih Arslan <fatih@arslan.io>
Fazlul Shahriar <fshahriar@gmail.com>
Felix Geisendörfer <haimuiba@gmail.com>
Firmansyah Adiputra <frm.adiputra@gmail.com>
@@ -168,7 +157,6 @@ Francisco Souza <franciscossouza@gmail.com>
Frederick Kelly Mayle III <frederickmayle@gmail.com>
Fredrik Enestad <fredrik.enestad@soundtrackyourbrand.com>
Frithjof Schulze <schulze@math.uni-hannover.de> <sfrithjof@gmail.com>
Gabriel Aszalos <gabriel.aszalos@gmail.com>
Gary Burd <gary@beagledreams.com>
Gautham Thambidorai <gautham.dorai@gmail.com>
Georg Reinke <guelfey@gmail.com>
@@ -186,8 +174,6 @@ Gustavo Niemeyer <gustavo@niemeyer.net>
Gwenael Treguier <gwenn.kahz@gmail.com>
Harley Laue <losinggeneration@gmail.com>
Hector Chu <hectorchu@gmail.com>
Hector Martin Cantero <hector@marcansoft.com>
Henning Schmiedehausen <henning@schmiedehausen.org>
Henrik Edwards <henrik.edwards@gmail.com>
Herbert Georg Fischer <herbert.fischer@gmail.com>
Hong Ruiqi <hongruiqi@gmail.com>
@@ -217,21 +203,17 @@ Jeff Hodges <jeff@somethingsimilar.com>
Jeff R. Allen <jra@nella.org>
Jeff Sickel <jas@corpus-callosum.com>
Jeff Wendling <jeff@spacemonkey.com>
Jens Frederich <jfrederich@gmail.com>
Jeremy Jackins <jeremyjackins@gmail.com>
Jim McGrath <jimmc2@gmail.com>
Jimmy Zelinskie <jimmyzelinskie@gmail.com>
Jingcheng Zhang <diogin@gmail.com>
Joakim Sernbrant <serbaut@gmail.com>
Joe Poirier <jdpoirier@gmail.com>
Joe Shaw <joe@joeshaw.org>
Joel Stemmer <stemmertech@gmail.com>
John Asmuth <jasmuth@gmail.com>
John C Barstow <jbowtie@amathaine.com>
John Graham-Cumming <jgc@jgc.org> <jgrahamc@gmail.com>
John Howard Palevich <jack.palevich@gmail.com>
John Shahid <jvshahid@gmail.com>
John Tuley <john@tuley.org>
Jonathan Gold <jgold.bg@gmail.com>
Jonathan Mark <jhmark@xenops.com>
Jonathan Rudenberg <jonathan@titanous.com>
@@ -243,7 +225,6 @@ Josh Bleecher Snyder <josharian@gmail.com>
Josh Goebel <dreamer3@gmail.com>
Josh Holland <jrh@joshh.co.uk>
Joshua Chase <jcjoshuachase@gmail.com>
JT Olds <jtolds@xnet5.com>
Jukka-Pekka Kekkonen <karatepekka@gmail.com>
Julian Phillips <julian@quantumfyre.co.uk>
Julien Schmidt <google@julienschmidt.com>
@@ -269,13 +250,10 @@ Lucio De Re <lucio.dere@gmail.com>
Luit van Drongelen <luitvd@gmail.com>
Luka Zakrajšek <tr00.g33k@gmail.com>
Luke Curley <qpingu@gmail.com>
Manuel Mendez <mmendez534@gmail.com>
Marc Weistroff <marc@weistroff.net>
Marco Hennings <marco.hennings@freiheit.com>
Mark Theunissen <mark.theunissen@gmail.com>
Marko Juhani Silokunnas <marko.silokunnas@gmail.com>
Marko Tiikkaja <marko@joh.to>
Markover Inc. DBA Poptip
Markus Duft <markus.duft@salomon.at>
Markus Sonderegger <marraison@gmail.com>
Markus Zimmermann <zimmski@gmail.com>
@@ -298,7 +276,6 @@ Michael Fraenkel <michael.fraenkel@gmail.com>
Michael Gehring <mg@ebfe.org> <gnirheg.leahcim@gmail.com>
Michael Hoisie <hoisie@gmail.com>
Michael Lewis <mikelikespie@gmail.com>
Michael MacInnis <Michael.P.MacInnis@gmail.com>
Michael Pearson <mipearson@gmail.com>
Michael Stapelberg <michael@stapelberg.de>
Michael Teichgräber <mteichgraeber@gmx.de>
@@ -318,7 +295,6 @@ Moriyoshi Koizumi <mozo@mozo.jp>
Môshe van der Sterre <moshevds@gmail.com>
Nan Deng <monnand@gmail.com>
Nathan John Youngman <nj@nathany.com>
Nathan P Finch <nate.finch@gmail.com>
ngmoco, LLC
Nicholas Katsaros <nick@nickkatsaros.com>
Nicholas Presta <nick@nickpresta.ca> <nick1presta@gmail.com>
@@ -349,7 +325,6 @@ Paul Lalonde <paul.a.lalonde@gmail.com>
Paul Sbarra <Sbarra.Paul@gmail.com>
Paul van Brouwershaven <paul@vanbrouwershaven.com>
Pavel Zinovkin <pavel.zinovkin@gmail.com>
Percy Wegmann <ox.to.a.cart@gmail.com>
Petar Maymounkov <petarm@gmail.com>
Peter Armitage <peter.armitage@gmail.com>
Peter Froehlich <peter.hans.froehlich@gmail.com>
@@ -365,7 +340,6 @@ Pietro Gagliardi <pietro10@mac.com>
Preetam Jinka <pj@preet.am>
Quan Yong Zhai <qyzhai@gmail.com>
Raif S. Naffah <go@naffah-raif.name>
Red Hat, Inc.
Rémy Oudompheng <oudomphe@phare.normalesup.org>
Richard Crowley <r@rcrowley.org>
Richard Eric Gavaletz <gavaletz@gmail.com>
@@ -382,7 +356,6 @@ Rodrigo Moraes de Oliveira <rodrigo.moraes@gmail.com>
Rodrigo Rafael Monti Kochenburger <divoxx@gmail.com>
Roger Pau Monné <royger@gmail.com>
Roger Peppe <rogpeppe@gmail.com>
Ron Hashimoto <mail@h2so5.net>
Ron Minnich <rminnich@gmail.com>
Ross Light <rlight2@gmail.com>
Rowan Worth <sqweek@gmail.com>
@@ -401,7 +374,6 @@ Shane Hansen <shanemhansen@gmail.com>
Shawn Smith <shawn.p.smith@gmail.com>
Shenghou Ma <minux.ma@gmail.com>
Shivakumar GN <shivakumar.gn@gmail.com>
Simon Whitehead <chemnova@gmail.com>
Sokolov Yura <funny.falcon@gmail.com>
Spring Mc <heresy.mc@gmail.com>
StalkR <stalkr@stalkr.net>
@@ -418,14 +390,10 @@ Tad Glines <tad.glines@gmail.com>
Taj Khattra <taj.khattra@gmail.com>
Tarmigan Casebolt <tarmigan@gmail.com>
Taru Karttunen <taruti@taruti.net>
Tetsuo Kiso <tetsuokiso9@gmail.com>
Thiago Fransosi Farina <thiago.farina@gmail.com>
Thomas Alan Copeland <talan.copeland@gmail.com>
Thomas Kappler <tkappler@gmail.com>
Timo Savola <timo.savola@gmail.com>
Timo Truyts <alkaloid.btx@gmail.com>
Tobias Columbus <tobias.columbus@gmail.com>
Tom Linford <tomlinford@gmail.com>
Tor Andersson <tor.andersson@gmail.com>
Travis Cline <travis.cline@gmail.com>
Tudor Golubenco <tudor.g@gmail.com>
@@ -444,7 +412,6 @@ Wei Guangjing <vcc.163@gmail.com>
Willem van der Schyff <willemvds@gmail.com>
William Josephson <wjosephson@gmail.com>
William Orr <will@worrbase.com> <ay1244@gmail.com>
Xia Bin <snyh@snyh.org>
Xing Xing <mikespook@gmail.com>
Yasuhiro Matsumoto <mattn.jp@gmail.com>
Yissakhar Z. Beck <yissakhar.beck@gmail.com>

View File

@@ -1,31 +0,0 @@
# Contributing to Go
Go is an open source project.
It is the work of hundreds of contributors. We appreciate your help!
## Filing issues
When filing an issue, make sure to answer these five questions:
1. What version of Go are you using (`go version`)?
2. What operating system and processor architecture are you using?
3. What did you do?
4. What did you expect to see?
5. What did you see instead?
General questions should go to the [golang-nuts mailing list](https://groups.google.com/group/golang-nuts) instead of the issue tracker.
The gophers there will answer or ask you to file an issue if you've tripped over a bug.
## Contributing code
Please read the [Contribution Guidelines](https://golang.org/doc/contribute.html)
before sending patches.
**We do not accept GitHub pull requests**
(we use [Gerrit](https://code.google.com/p/gerrit/) instead for code review).
Unless otherwise noted, the Go source files are distributed under
the BSD-style license found in the LICENSE file.

View File

@@ -38,12 +38,9 @@ Adam Langley <agl@golang.org>
Adrian Nos <nos.adrian@gmail.com>
Adrian O'Grady <elpollouk@gmail.com>
Adrien Bustany <adrien-xx-google@bustany.org>
Ahmed Waheed Moanes <oneofone@gmail.com>
Akshat Kumar <seed@mail.nanosouffle.net>
Alan Donovan <adonovan@google.com>
Alan Shreve <alan@inconshreveable.com>
Albert Strasheim <fullung@gmail.com>
Alberto Donizetti <alb.donizetti@gmail.com>
Alberto García Hierro <alberto@garciahierro.com> <alberto.garcia.hierro@gmail.com>
Aleksandar Dezelin <dezelin@gmail.com>
Alex A Skinner <alex@lx.lc>
@@ -66,10 +63,8 @@ Amrut Joshi <amrut.joshi@gmail.com>
Andrea Spadaccini <spadaccio@google.com>
Andreas Jellinghaus <andreas@ionisiert.de> <anj@google.com>
Andrei Vieru <euvieru@gmail.com>
Andres Erbsen <andreser@google.com>
Andrew Balholm <andybalholm@gmail.com>
Andrew Bonventre <andybons@chromium.org>
Andrew Bursavich <abursavich@gmail.com>
Andrew Gerrand <adg@golang.org>
Andrew Harding <andrew@spacemonkey.com>
Andrew Lutomirski <andy@luto.us>
@@ -96,7 +91,7 @@ Arvindh Rajesh Tamilmani <art@a-30.net>
Asim Shankar <asimshankar@gmail.com>
Ato Araki <ato.araki@gmail.com>
Aulus Egnatius Varialus <varialus@gmail.com>
Austin Clements <austin@google.com> <aclements@csail.mit.edu>
Austin Clements <aclements@csail.mit.edu>
Balazs Lecz <leczb@google.com>
Ben Eitzen <eitzenb@golang.org>
Ben Fried <ben.fried@gmail.com>
@@ -104,7 +99,6 @@ Ben Lynn <benlynn@gmail.com>
Ben Olive <sionide21@gmail.com>
Benjamin Black <b@b3k.us>
Benny Siegert <bsiegert@gmail.com>
Benoit Sigoure <tsunanet@gmail.com>
Berengar Lehr <Berengar.Lehr@gmx.de>
Bill Neubauer <wcn@golang.org> <wcn@google.com> <bill.neubauer@gmail.com>
Bill Thiede <couchmoney@gmail.com>
@@ -144,7 +138,6 @@ Chris Hundt <hundt@google.com>
Chris Jones <chris@cjones.org> <chris.jones.yar@gmail.com>
Chris Lennert <calennert@gmail.com>
Chris Manghane <cmang@golang.org>
Chris McGee <sirnewton_01@yahoo.ca> <newton688@gmail.com>
Christian Himpel <chressie@googlemail.com> <chressie@gmail.com>
Christine Hansmann <chhansmann@gmail.com>
Christoffer Buchholz <christoffer.buchholz@gmail.com>
@@ -159,9 +152,7 @@ Colby Ranger <cranger@google.com>
Conrad Meyer <cemeyer@cs.washington.edu>
Corey Thomasson <cthom.lists@gmail.com>
Cosmos Nicolaou <cnicolaou@google.com>
Cristian Staretu <unclejacksons@gmail.com>
Damian Gryski <dgryski@gmail.com>
Damien Neil <dneil@google.com>
Dan Callahan <dan.callahan@gmail.com>
Dan Peterson <dpiddy@gmail.com>
Dan Sinclair <dan.sinclair@gmail.com>
@@ -186,7 +177,6 @@ David du Colombier <0intro@gmail.com>
David Forsythe <dforsythe@gmail.com>
David G. Andersen <dave.andersen@gmail.com>
David Jakob Fritz <david.jakob.fritz@gmail.com>
David Leon Gil <coruus@gmail.com>
David McLeish <davemc@google.com>
David Presotto <presotto@gmail.com>
David Symonds <dsymonds@golang.org>
@@ -194,7 +184,6 @@ David Thomas <davidthomas426@gmail.com>
David Titarenco <david.titarenco@gmail.com>
Dean Prichard <dean.prichard@gmail.com>
Denis Brandolini <denis.brandolini@gmail.com>
Derek Parker <parkerderek86@gmail.com>
Devon H. O'Dell <devon.odell@gmail.com>
Dhiru Kholia <dhiru.kholia@gmail.com>
Dimitri Tcaciuc <dtcaciuc@gmail.com>
@@ -206,7 +195,6 @@ Dominik Honnef <dominik.honnef@gmail.com>
Donovan Hide <donovanhide@gmail.com>
Drew Hintz <adhintz@google.com>
Duncan Holm <mail@frou.org>
Dustin Long <dustmop@gmail.com>
Dustin Sallings <dsallings@gmail.com>
Dustin Shields-Cloues <dcloues@gmail.com>
Eden Li <eden.li@gmail.com>
@@ -214,7 +202,7 @@ Egon Elbre <egonelbre@gmail.com>
Ehren Kret <ehren.kret@gmail.com>
Eivind Uggedal <eivind@uggedal.com>
Elias Naur <elias.naur@gmail.com>
Emil Hessman <c.emil.hessman@gmail.com> <emil@hessman.se>
Emil Hessman <c.emil.hessman@gmail.com>
Eoghan Sherry <ejsherry@gmail.com>
Eric Clark <zerohp@gmail.com>
Eric Milliken <emilliken@gmail.com>
@@ -222,13 +210,11 @@ Eric Roshan-Eisner <eric.d.eisner@gmail.com>
Erik St. Martin <alakriti@gmail.com>
Erik Westrup <erik.westrup@gmail.com>
Esko Luontola <esko.luontola@gmail.com>
Evan Kroske <evankroske@google.com>
Evan Martin <evan.martin@gmail.com>
Evan Shaw <chickencha@gmail.com>
Ewan Chou <coocood@gmail.com>
Fabrizio Milo <mistobaan@gmail.com>
Fan Hongjian <fan.howard@gmail.com>
Fatih Arslan <fatih@arslan.io>
Fazlul Shahriar <fshahriar@gmail.com>
Felix Geisendörfer <haimuiba@gmail.com>
Firmansyah Adiputra <frm.adiputra@gmail.com>
@@ -242,14 +228,12 @@ Fredrik Enestad <fredrik.enestad@soundtrackyourbrand.com>
Frithjof Schulze <schulze@math.uni-hannover.de> <sfrithjof@gmail.com>
Fumitoshi Ukai <ukai@google.com>
Gaal Yahas <gaal@google.com>
Gabriel Aszalos <gabriel.aszalos@gmail.com>
Gary Burd <gary@beagledreams.com> <gary.burd@gmail.com>
Gautham Thambidorai <gautham.dorai@gmail.com>
Georg Reinke <guelfey@gmail.com>
Gerasimos Dimitriadis <gedimitr@gmail.com>
Gideon Jan-Wessel Redelinghuys <gjredelinghuys@gmail.com>
Giles Lean <giles.lean@pobox.com>
Glenn Lewis <gmlewis@google.com>
Gordon Klaus <gordon.klaus@gmail.com>
Graham King <graham4king@gmail.com>
Graham Miller <graham.miller@gmail.com>
@@ -259,12 +243,9 @@ Gustav Paul <gustav.paul@gmail.com>
Gustavo Franco <gustavorfranco@gmail.com>
Gustavo Niemeyer <gustavo@niemeyer.net> <n13m3y3r@gmail.com>
Gwenael Treguier <gwenn.kahz@gmail.com>
Hana Kim <hyangah@gmail.com>
Han-Wen Nienhuys <hanwen@google.com>
Harley Laue <losinggeneration@gmail.com>
Hector Chu <hectorchu@gmail.com>
Hector Martin Cantero <hector@marcansoft.com>
Henning Schmiedehausen <henning@schmiedehausen.org>
Henrik Edwards <henrik.edwards@gmail.com>
Herbert Georg Fischer <herbert.fischer@gmail.com>
Hong Ruiqi <hongruiqi@gmail.com>
@@ -283,7 +264,6 @@ James Fysh <james.fysh@gmail.com>
James Gray <james@james4k.com>
James Meneghello <rawrz0r@gmail.com>
James P. Cooper <jamespcooper@gmail.com>
James Robinson <jamesr@google.com> <jamesr.gatech@gmail.com>
James Toy <nil@opensesame.st>
James Tucker <raggi@google.com>
James Whitehead <jnwhiteh@gmail.com>
@@ -301,12 +281,10 @@ Jason Del Ponte <delpontej@gmail.com>
Jason Travis <infomaniac7@gmail.com>
Jay Weisskopf <jay@jayschwa.net>
Jean-Marc Eurin <jmeurin@google.com>
Jed Denlea <jed@fastly.com>
Jeff Hodges <jeff@somethingsimilar.com>
Jeff R. Allen <jra@nella.org> <jeff.allen@gmail.com>
Jeff Sickel <jas@corpus-callosum.com>
Jeff Wendling <jeff@spacemonkey.com>
Jens Frederich <jfrederich@gmail.com>
Jeremiah Harmsen <jeremiah@google.com>
Jeremy Jackins <jeremyjackins@gmail.com>
Jeremy Schlatter <jeremy.schlatter@gmail.com>
@@ -315,9 +293,7 @@ Jimmy Zelinskie <jimmyzelinskie@gmail.com>
Jingcheng Zhang <diogin@gmail.com>
Joakim Sernbrant <serbaut@gmail.com>
Joe Poirier <jdpoirier@gmail.com>
Joe Shaw <joe@joeshaw.org>
Joel Sing <jsing@google.com>
Joel Stemmer <stemmertech@gmail.com>
Johan Euphrosine <proppy@google.com>
John Asmuth <jasmuth@gmail.com>
John Beisley <huin@google.com>
@@ -327,7 +303,6 @@ John Graham-Cumming <jgc@jgc.org> <jgrahamc@gmail.com>
John Howard Palevich <jack.palevich@gmail.com>
John Newlin <jnewlin@google.com>
John Shahid <jvshahid@gmail.com>
John Tuley <john@tuley.org>
Jonathan Allie <jonallie@google.com>
Jonathan Feinberg <feinberg@google.com>
Jonathan Gold <jgold.bg@gmail.com>
@@ -348,7 +323,6 @@ Josh Hoak <jhoak@google.com>
Josh Holland <jrh@joshh.co.uk>
Joshua Chase <jcjoshuachase@gmail.com>
JP Sugarbroad <jpsugar@google.com>
JT Olds <jtolds@xnet5.com>
Jukka-Pekka Kekkonen <karatepekka@gmail.com>
Julian Phillips <julian@quantumfyre.co.uk>
Julien Schmidt <google@julienschmidt.com>
@@ -383,11 +357,9 @@ Luke Curley <qpingu@gmail.com>
Luuk van Dijk <lvd@golang.org> <lvd@google.com>
Manoj Dayaram <platform-dev@moovweb.com> <manoj.dayaram@moovweb.com>
Manu Garg <manugarg@google.com>
Manuel Mendez <mmendez534@gmail.com>
Marc Weistroff <marc@weistroff.net>
Marcel van Lohuizen <mpvl@golang.org>
Marco Hennings <marco.hennings@freiheit.com>
Mark Theunissen <mark.theunissen@gmail.com>
Mark Zavislak <zavislak@google.com>
Marko Juhani Silokunnas <marko.silokunnas@gmail.com>
Marko Mikulicic <mkm@google.com>
@@ -421,7 +393,6 @@ Michael Hoisie <hoisie@gmail.com>
Michael Hudson-Doyle <michael.hudson@linaro.org>
Michael Kelly <mjk@google.com>
Michael Lewis <mikelikespie@gmail.com>
Michael MacInnis <Michael.P.MacInnis@gmail.com>
Michael Matloob <matloob@google.com>
Michael Pearson <mipearson@gmail.com>
Michael Piatek <piatek@google.com>
@@ -444,15 +415,12 @@ Mikkel Krautz <mikkel@krautz.dk> <krautz@gmail.com>
Miquel Sabaté Solà <mikisabate@gmail.com>
Moriyoshi Koizumi <mozo@mozo.jp>
Môshe van der Sterre <moshevds@gmail.com>
Mrunal Patel <mrunalp@gmail.com>
Nan Deng <monnand@gmail.com>
Nathan John Youngman <nj@nathany.com>
Nathan P Finch <nate.finch@gmail.com>
Nicholas Katsaros <nick@nickkatsaros.com>
Nicholas Presta <nick@nickpresta.ca> <nick1presta@gmail.com>
Nicholas Sullivan <nicholas.sullivan@gmail.com>
Nicholas Waples <nwaples@gmail.com>
Nick Cooper <nmvc@google.com>
Nick Craig-Wood <nick@craig-wood.com> <nickcw@gmail.com>
Nicolas Kaiser <nikai@nikai.net>
Nicolas Owens <mischief@offblast.org>
@@ -479,12 +447,10 @@ Paul Borman <borman@google.com>
Paul Chang <paulchang@google.com>
Paul Hammond <paul@paulhammond.org>
Paul Lalonde <paul.a.lalonde@gmail.com>
Paul Nasrat <pnasrat@google.com>
Paul Sbarra <Sbarra.Paul@gmail.com>
Paul van Brouwershaven <paul@vanbrouwershaven.com>
Pavel Zinovkin <pavel.zinovkin@gmail.com>
Pawel Szczur <filemon@google.com>
Percy Wegmann <ox.to.a.cart@gmail.com>
Petar Maymounkov <petarm@gmail.com>
Peter Armitage <peter.armitage@gmail.com>
Peter Collingbourne <pcc@google.com>
@@ -506,13 +472,11 @@ Preetam Jinka <pj@preet.am>
Quan Yong Zhai <qyzhai@gmail.com>
Raif S. Naffah <go@naffah-raif.name>
Raph Levien <raph@google.com>
Raul Silvera <rsilvera@google.com>
Rémy Oudompheng <oudomphe@phare.normalesup.org> <remyoudompheng@gmail.com>
Richard Crowley <r@rcrowley.org>
Richard Eric Gavaletz <gavaletz@gmail.com>
Richard Musiol <mail@richard-musiol.de> <neelance@gmail.com>
Rick Arnold <rickarnoldjr@gmail.com>
Rick Hudson <rlh@golang.org>
Risto Jaakko Saarelma <rsaarelm@gmail.com>
Rob Pike <r@golang.org>
Robert Daniel Kortschak <dan.kortschak@adelaide.edu.au>
@@ -528,7 +492,6 @@ Rodrigo Moraes de Oliveira <rodrigo.moraes@gmail.com>
Rodrigo Rafael Monti Kochenburger <divoxx@gmail.com>
Roger Pau Monné <royger@gmail.com>
Roger Peppe <rogpeppe@gmail.com>
Ron Hashimoto <mail@h2so5.net>
Ron Minnich <rminnich@gmail.com>
Ross Light <rlight2@gmail.com>
Rowan Worth <sqweek@gmail.com>
@@ -555,7 +518,6 @@ Shawn Ledbetter <sledbetter@google.com>
Shawn Smith <shawn.p.smith@gmail.com>
Shenghou Ma <minux@golang.org> <minux.ma@gmail.com>
Shivakumar GN <shivakumar.gn@gmail.com>
Simon Whitehead <chemnova@gmail.com>
Sokolov Yura <funny.falcon@gmail.com>
Spring Mc <heresy.mc@gmail.com>
StalkR <stalkr@stalkr.net>
@@ -574,16 +536,12 @@ Tad Glines <tad.glines@gmail.com>
Taj Khattra <taj.khattra@gmail.com>
Tarmigan Casebolt <tarmigan@gmail.com>
Taru Karttunen <taruti@taruti.net>
Tetsuo Kiso <tetsuokiso9@gmail.com>
Thiago Fransosi Farina <thiago.farina@gmail.com> <tfarina@chromium.org>
Thomas Alan Copeland <talan.copeland@gmail.com>
Thomas Habets <habets@google.com>
Thomas Kappler <tkappler@gmail.com>
Timo Savola <timo.savola@gmail.com>
Timo Truyts <alkaloid.btx@gmail.com>
Tobias Columbus <tobias.columbus@gmail.com> <tobias.columbus@googlemail.com>
Todd Wang <toddwang@gmail.com>
Tom Linford <tomlinford@gmail.com>
Tom Szymanski <tgs@google.com>
Tor Andersson <tor.andersson@gmail.com>
Travis Cline <travis.cline@gmail.com>
@@ -608,7 +566,6 @@ Willem van der Schyff <willemvds@gmail.com>
William Chan <willchan@chromium.org>
William Josephson <wjosephson@gmail.com>
William Orr <will@worrbase.com> <ay1244@gmail.com>
Xia Bin <snyh@snyh.org>
Xing Xing <mikespook@gmail.com>
Yan Zou <yzou@google.com>
Yasuhiro Matsumoto <mattn.jp@gmail.com>

32
README Normal file
View File

@@ -0,0 +1,32 @@
This is the source code repository for the Go programming language.
For documentation about how to install and use Go,
visit http://golang.org/ or load doc/install-source.html
in your web browser.
After installing Go, you can view a nicely formatted
doc/install-source.html by running godoc --http=:6060
and then visiting http://localhost:6060/doc/install/source.
Unless otherwise noted, the Go source files are distributed
under the BSD-style license found in the LICENSE file.
--
Binary Distribution Notes
If you have just untarred a binary Go distribution, you need to set
the environment variable $GOROOT to the full path of the go
directory (the one containing this README). You can omit the
variable if you unpack it into /usr/local/go, or if you rebuild
from sources by running all.bash (see doc/install.html).
You should also add the Go binary directory $GOROOT/bin
to your shell's path.
For example, if you extracted the tar file into $HOME/go, you might
put the following in your .profile:
export GOROOT=$HOME/go
export PATH=$PATH:$GOROOT/bin
See doc/install.html for more details.

View File

@@ -1,45 +0,0 @@
# The Go Programming Language
Go is an open source programming language that makes it easy to build simple,
reliable, and efficient software.
![Gopher image](doc/gopher/fiveyears.jpg)
For documentation about how to install and use Go,
visit https://golang.org/ or load doc/install-source.html
in your web browser.
Our canonical Git repository is located at https://go.googlesource.com/go.
There is a mirror of the repository at https://github.com/golang/go.
Please report issues here: https://golang.org/issue/new
Go is the work of hundreds of contributors. We appreciate your help!
To contribute, please read the contribution guidelines:
https://golang.org/doc/contribute.html
##### Please note that we do not use pull requests.
Unless otherwise noted, the Go source files are distributed
under the BSD-style license found in the LICENSE file.
--
## Binary Distribution Notes
If you have just untarred a binary Go distribution, you need to set
the environment variable $GOROOT to the full path of the go
directory (the one containing this file). You can omit the
variable if you unpack it into /usr/local/go, or if you rebuild
from sources by running all.bash (see doc/install-source.html).
You should also add the Go binary directory $GOROOT/bin
to your shell's path.
For example, if you extracted the tar file into $HOME/go, you might
put the following in your .profile:
export GOROOT=$HOME/go
export PATH=$PATH:$GOROOT/bin
See https://golang.org/doc/install or doc/install.html for more details.

1
VERSION Normal file
View File

@@ -0,0 +1 @@
go1.3

View File

@@ -327,4 +327,3 @@ pkg syscall (netbsd-arm), const SizeofIfData = 132
pkg syscall (netbsd-arm), type IfMsghdr struct, Pad_cgo_1 [4]uint8
pkg syscall (netbsd-arm-cgo), const SizeofIfData = 132
pkg syscall (netbsd-arm-cgo), type IfMsghdr struct, Pad_cgo_1 [4]uint8
pkg unicode, const Version = "6.3.0"

View File

@@ -1,604 +0,0 @@
# CL 134210043 archive/zip: add Writer.Flush, Brad Fitzpatrick <bradfitz@golang.org>
pkg archive/zip, method (*Writer) Flush() error
# CL 97140043 compress/flate: add Reset() to allow reusing large buffers to compress multiple buffers, James Robinson <jamesr@google.com>
pkg compress/flate, type Resetter interface { Reset }
pkg compress/flate, type Resetter interface, Reset(io.Reader, []uint8) error
pkg compress/zlib, type Resetter interface { Reset }
pkg compress/zlib, type Resetter interface, Reset(io.Reader, []uint8) error
# CL 159120044 compress/gzip: allow stopping at end of first stream, Russ Cox <rsc@golang.org>
pkg compress/gzip, method (*Reader) Multistream(bool)
# CL 138800043 crypto: Add SHA3 functions in go.crypto/sha3 to the Hash enum., David Leon Gil <coruus@gmail.com>
pkg crypto, const SHA3_224 = 10
pkg crypto, const SHA3_224 Hash
pkg crypto, const SHA3_256 = 11
pkg crypto, const SHA3_256 Hash
pkg crypto, const SHA3_384 = 12
pkg crypto, const SHA3_384 Hash
pkg crypto, const SHA3_512 = 13
pkg crypto, const SHA3_512 Hash
# CL 114680043 crypto: add Signer, Adam Langley <agl@golang.org>
pkg crypto, method (Hash) HashFunc() Hash
pkg crypto, type Signer interface { Public, Sign }
pkg crypto, type Signer interface, Public() PublicKey
pkg crypto, type Signer interface, Sign(io.Reader, []uint8, SignerOpts) ([]uint8, error)
pkg crypto, type SignerOpts interface { HashFunc }
pkg crypto, type SignerOpts interface, HashFunc() Hash
pkg crypto/ecdsa, method (*PrivateKey) Public() crypto.PublicKey
pkg crypto/ecdsa, method (*PrivateKey) Sign(io.Reader, []uint8, crypto.SignerOpts) ([]uint8, error)
pkg crypto/rsa, method (*PSSOptions) HashFunc() crypto.Hash
pkg crypto/rsa, method (*PrivateKey) Public() crypto.PublicKey
pkg crypto/rsa, method (*PrivateKey) Sign(io.Reader, []uint8, crypto.SignerOpts) ([]uint8, error)
pkg crypto/rsa, type PSSOptions struct, Hash crypto.Hash
# CL 157090043 crypto/tls: support TLS_FALLBACK_SCSV as a server., Adam Langley <agl@golang.org>
pkg crypto/tls, const TLS_FALLBACK_SCSV = 22016
pkg crypto/tls, const TLS_FALLBACK_SCSV uint16
# CL 107400043 crypto/tls: Added dynamic alternative to NameToCertificate map for SNI, Percy Wegmann <ox.to.a.cart@gmail.com>
pkg crypto/tls, type ClientHelloInfo struct
pkg crypto/tls, type ClientHelloInfo struct, CipherSuites []uint16
pkg crypto/tls, type ClientHelloInfo struct, ServerName string
pkg crypto/tls, type ClientHelloInfo struct, SupportedCurves []CurveID
pkg crypto/tls, type ClientHelloInfo struct, SupportedPoints []uint8
pkg crypto/tls, type Config struct, GetCertificate func(*ClientHelloInfo) (*Certificate, error)
pkg crypto/tls, type ConnectionState struct, TLSUnique []uint8
# CL 153420045 crypto/x509: continue to recognise MaxPathLen of zero as "no value"., Adam Langley <agl@golang.org>
pkg crypto/x509, type Certificate struct, MaxPathLenZero bool
# CL 158950043 database/sql: add Drivers, returning list of registered drivers, Russ Cox <rsc@golang.org>
pkg database/sql, func Drivers() []string
# CL 117280043 debug/dwarf: fix Reader panic on DW_TAG_unspecified_type, Derek Parker <parkerderek86@gmail.com>
pkg debug/dwarf, method (*UnspecifiedType) Basic() *BasicType
pkg debug/dwarf, method (*UnspecifiedType) Common() *CommonType
pkg debug/dwarf, method (*UnspecifiedType) Size() int64
pkg debug/dwarf, method (*UnspecifiedType) String() string
pkg debug/dwarf, type UnspecifiedType struct
pkg debug/dwarf, type UnspecifiedType struct, embedded BasicType
# CL 132000043 debug/elf: support arm64 relocations, Michael Hudson-Doyle <michael.hudson@linaro.org>
pkg debug/elf, const EM_AARCH64 = 183
pkg debug/elf, const EM_AARCH64 Machine
pkg debug/elf, const R_AARCH64_ABS16 = 259
pkg debug/elf, const R_AARCH64_ABS16 R_AARCH64
pkg debug/elf, const R_AARCH64_ABS32 = 258
pkg debug/elf, const R_AARCH64_ABS32 R_AARCH64
pkg debug/elf, const R_AARCH64_ABS64 = 257
pkg debug/elf, const R_AARCH64_ABS64 R_AARCH64
pkg debug/elf, const R_AARCH64_ADD_ABS_LO12_NC = 277
pkg debug/elf, const R_AARCH64_ADD_ABS_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_ADR_GOT_PAGE = 311
pkg debug/elf, const R_AARCH64_ADR_GOT_PAGE R_AARCH64
pkg debug/elf, const R_AARCH64_ADR_PREL_LO21 = 274
pkg debug/elf, const R_AARCH64_ADR_PREL_LO21 R_AARCH64
pkg debug/elf, const R_AARCH64_ADR_PREL_PG_HI21 = 275
pkg debug/elf, const R_AARCH64_ADR_PREL_PG_HI21 R_AARCH64
pkg debug/elf, const R_AARCH64_ADR_PREL_PG_HI21_NC = 276
pkg debug/elf, const R_AARCH64_ADR_PREL_PG_HI21_NC R_AARCH64
pkg debug/elf, const R_AARCH64_CALL26 = 283
pkg debug/elf, const R_AARCH64_CALL26 R_AARCH64
pkg debug/elf, const R_AARCH64_CONDBR19 = 280
pkg debug/elf, const R_AARCH64_CONDBR19 R_AARCH64
pkg debug/elf, const R_AARCH64_COPY = 1024
pkg debug/elf, const R_AARCH64_COPY R_AARCH64
pkg debug/elf, const R_AARCH64_GLOB_DAT = 1025
pkg debug/elf, const R_AARCH64_GLOB_DAT R_AARCH64
pkg debug/elf, const R_AARCH64_GOT_LD_PREL19 = 309
pkg debug/elf, const R_AARCH64_GOT_LD_PREL19 R_AARCH64
pkg debug/elf, const R_AARCH64_IRELATIVE = 1032
pkg debug/elf, const R_AARCH64_IRELATIVE R_AARCH64
pkg debug/elf, const R_AARCH64_JUMP26 = 282
pkg debug/elf, const R_AARCH64_JUMP26 R_AARCH64
pkg debug/elf, const R_AARCH64_JUMP_SLOT = 1026
pkg debug/elf, const R_AARCH64_JUMP_SLOT R_AARCH64
pkg debug/elf, const R_AARCH64_LD64_GOT_LO12_NC = 312
pkg debug/elf, const R_AARCH64_LD64_GOT_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_LDST128_ABS_LO12_NC = 299
pkg debug/elf, const R_AARCH64_LDST128_ABS_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_LDST16_ABS_LO12_NC = 284
pkg debug/elf, const R_AARCH64_LDST16_ABS_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_LDST32_ABS_LO12_NC = 285
pkg debug/elf, const R_AARCH64_LDST32_ABS_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_LDST64_ABS_LO12_NC = 286
pkg debug/elf, const R_AARCH64_LDST64_ABS_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_LDST8_ABS_LO12_NC = 278
pkg debug/elf, const R_AARCH64_LDST8_ABS_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_LD_PREL_LO19 = 273
pkg debug/elf, const R_AARCH64_LD_PREL_LO19 R_AARCH64
pkg debug/elf, const R_AARCH64_MOVW_SABS_G0 = 270
pkg debug/elf, const R_AARCH64_MOVW_SABS_G0 R_AARCH64
pkg debug/elf, const R_AARCH64_MOVW_SABS_G1 = 271
pkg debug/elf, const R_AARCH64_MOVW_SABS_G1 R_AARCH64
pkg debug/elf, const R_AARCH64_MOVW_SABS_G2 = 272
pkg debug/elf, const R_AARCH64_MOVW_SABS_G2 R_AARCH64
pkg debug/elf, const R_AARCH64_MOVW_UABS_G0 = 263
pkg debug/elf, const R_AARCH64_MOVW_UABS_G0 R_AARCH64
pkg debug/elf, const R_AARCH64_MOVW_UABS_G0_NC = 264
pkg debug/elf, const R_AARCH64_MOVW_UABS_G0_NC R_AARCH64
pkg debug/elf, const R_AARCH64_MOVW_UABS_G1 = 265
pkg debug/elf, const R_AARCH64_MOVW_UABS_G1 R_AARCH64
pkg debug/elf, const R_AARCH64_MOVW_UABS_G1_NC = 266
pkg debug/elf, const R_AARCH64_MOVW_UABS_G1_NC R_AARCH64
pkg debug/elf, const R_AARCH64_MOVW_UABS_G2 = 267
pkg debug/elf, const R_AARCH64_MOVW_UABS_G2 R_AARCH64
pkg debug/elf, const R_AARCH64_MOVW_UABS_G2_NC = 268
pkg debug/elf, const R_AARCH64_MOVW_UABS_G2_NC R_AARCH64
pkg debug/elf, const R_AARCH64_MOVW_UABS_G3 = 269
pkg debug/elf, const R_AARCH64_MOVW_UABS_G3 R_AARCH64
pkg debug/elf, const R_AARCH64_NONE = 0
pkg debug/elf, const R_AARCH64_NONE R_AARCH64
pkg debug/elf, const R_AARCH64_NULL = 256
pkg debug/elf, const R_AARCH64_NULL R_AARCH64
pkg debug/elf, const R_AARCH64_P32_ABS16 = 2
pkg debug/elf, const R_AARCH64_P32_ABS16 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_ABS32 = 1
pkg debug/elf, const R_AARCH64_P32_ABS32 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_ADD_ABS_LO12_NC = 12
pkg debug/elf, const R_AARCH64_P32_ADD_ABS_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_P32_ADR_GOT_PAGE = 26
pkg debug/elf, const R_AARCH64_P32_ADR_GOT_PAGE R_AARCH64
pkg debug/elf, const R_AARCH64_P32_ADR_PREL_LO21 = 10
pkg debug/elf, const R_AARCH64_P32_ADR_PREL_LO21 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_ADR_PREL_PG_HI21 = 11
pkg debug/elf, const R_AARCH64_P32_ADR_PREL_PG_HI21 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_CALL26 = 21
pkg debug/elf, const R_AARCH64_P32_CALL26 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_CONDBR19 = 19
pkg debug/elf, const R_AARCH64_P32_CONDBR19 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_COPY = 180
pkg debug/elf, const R_AARCH64_P32_COPY R_AARCH64
pkg debug/elf, const R_AARCH64_P32_GLOB_DAT = 181
pkg debug/elf, const R_AARCH64_P32_GLOB_DAT R_AARCH64
pkg debug/elf, const R_AARCH64_P32_GOT_LD_PREL19 = 25
pkg debug/elf, const R_AARCH64_P32_GOT_LD_PREL19 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_IRELATIVE = 188
pkg debug/elf, const R_AARCH64_P32_IRELATIVE R_AARCH64
pkg debug/elf, const R_AARCH64_P32_JUMP26 = 20
pkg debug/elf, const R_AARCH64_P32_JUMP26 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_JUMP_SLOT = 182
pkg debug/elf, const R_AARCH64_P32_JUMP_SLOT R_AARCH64
pkg debug/elf, const R_AARCH64_P32_LD32_GOT_LO12_NC = 27
pkg debug/elf, const R_AARCH64_P32_LD32_GOT_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_P32_LDST128_ABS_LO12_NC = 17
pkg debug/elf, const R_AARCH64_P32_LDST128_ABS_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_P32_LDST16_ABS_LO12_NC = 14
pkg debug/elf, const R_AARCH64_P32_LDST16_ABS_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_P32_LDST32_ABS_LO12_NC = 15
pkg debug/elf, const R_AARCH64_P32_LDST32_ABS_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_P32_LDST64_ABS_LO12_NC = 16
pkg debug/elf, const R_AARCH64_P32_LDST64_ABS_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_P32_LDST8_ABS_LO12_NC = 13
pkg debug/elf, const R_AARCH64_P32_LDST8_ABS_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_P32_LD_PREL_LO19 = 9
pkg debug/elf, const R_AARCH64_P32_LD_PREL_LO19 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_MOVW_SABS_G0 = 8
pkg debug/elf, const R_AARCH64_P32_MOVW_SABS_G0 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_MOVW_UABS_G0 = 5
pkg debug/elf, const R_AARCH64_P32_MOVW_UABS_G0 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_MOVW_UABS_G0_NC = 6
pkg debug/elf, const R_AARCH64_P32_MOVW_UABS_G0_NC R_AARCH64
pkg debug/elf, const R_AARCH64_P32_MOVW_UABS_G1 = 7
pkg debug/elf, const R_AARCH64_P32_MOVW_UABS_G1 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_PREL16 = 4
pkg debug/elf, const R_AARCH64_P32_PREL16 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_PREL32 = 3
pkg debug/elf, const R_AARCH64_P32_PREL32 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_RELATIVE = 183
pkg debug/elf, const R_AARCH64_P32_RELATIVE R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TLSDESC = 187
pkg debug/elf, const R_AARCH64_P32_TLSDESC R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TLSDESC_ADD_LO12_NC = 126
pkg debug/elf, const R_AARCH64_P32_TLSDESC_ADD_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TLSDESC_ADR_PAGE21 = 124
pkg debug/elf, const R_AARCH64_P32_TLSDESC_ADR_PAGE21 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TLSDESC_ADR_PREL21 = 123
pkg debug/elf, const R_AARCH64_P32_TLSDESC_ADR_PREL21 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TLSDESC_CALL = 127
pkg debug/elf, const R_AARCH64_P32_TLSDESC_CALL R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TLSDESC_LD32_LO12_NC = 125
pkg debug/elf, const R_AARCH64_P32_TLSDESC_LD32_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TLSDESC_LD_PREL19 = 122
pkg debug/elf, const R_AARCH64_P32_TLSDESC_LD_PREL19 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TLSGD_ADD_LO12_NC = 82
pkg debug/elf, const R_AARCH64_P32_TLSGD_ADD_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TLSGD_ADR_PAGE21 = 81
pkg debug/elf, const R_AARCH64_P32_TLSGD_ADR_PAGE21 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TLSIE_ADR_GOTTPREL_PAGE21 = 103
pkg debug/elf, const R_AARCH64_P32_TLSIE_ADR_GOTTPREL_PAGE21 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TLSIE_LD32_GOTTPREL_LO12_NC = 104
pkg debug/elf, const R_AARCH64_P32_TLSIE_LD32_GOTTPREL_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TLSIE_LD_GOTTPREL_PREL19 = 105
pkg debug/elf, const R_AARCH64_P32_TLSIE_LD_GOTTPREL_PREL19 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TLSLE_ADD_TPREL_HI12 = 109
pkg debug/elf, const R_AARCH64_P32_TLSLE_ADD_TPREL_HI12 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TLSLE_ADD_TPREL_LO12 = 110
pkg debug/elf, const R_AARCH64_P32_TLSLE_ADD_TPREL_LO12 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TLSLE_ADD_TPREL_LO12_NC = 111
pkg debug/elf, const R_AARCH64_P32_TLSLE_ADD_TPREL_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TLSLE_MOVW_TPREL_G0 = 107
pkg debug/elf, const R_AARCH64_P32_TLSLE_MOVW_TPREL_G0 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TLSLE_MOVW_TPREL_G0_NC = 108
pkg debug/elf, const R_AARCH64_P32_TLSLE_MOVW_TPREL_G0_NC R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TLSLE_MOVW_TPREL_G1 = 106
pkg debug/elf, const R_AARCH64_P32_TLSLE_MOVW_TPREL_G1 R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TLS_DTPMOD = 184
pkg debug/elf, const R_AARCH64_P32_TLS_DTPMOD R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TLS_DTPREL = 185
pkg debug/elf, const R_AARCH64_P32_TLS_DTPREL R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TLS_TPREL = 186
pkg debug/elf, const R_AARCH64_P32_TLS_TPREL R_AARCH64
pkg debug/elf, const R_AARCH64_P32_TSTBR14 = 18
pkg debug/elf, const R_AARCH64_P32_TSTBR14 R_AARCH64
pkg debug/elf, const R_AARCH64_PREL16 = 262
pkg debug/elf, const R_AARCH64_PREL16 R_AARCH64
pkg debug/elf, const R_AARCH64_PREL32 = 261
pkg debug/elf, const R_AARCH64_PREL32 R_AARCH64
pkg debug/elf, const R_AARCH64_PREL64 = 260
pkg debug/elf, const R_AARCH64_PREL64 R_AARCH64
pkg debug/elf, const R_AARCH64_RELATIVE = 1027
pkg debug/elf, const R_AARCH64_RELATIVE R_AARCH64
pkg debug/elf, const R_AARCH64_TLSDESC = 1031
pkg debug/elf, const R_AARCH64_TLSDESC R_AARCH64
pkg debug/elf, const R_AARCH64_TLSDESC_ADD = 568
pkg debug/elf, const R_AARCH64_TLSDESC_ADD R_AARCH64
pkg debug/elf, const R_AARCH64_TLSDESC_ADD_LO12_NC = 564
pkg debug/elf, const R_AARCH64_TLSDESC_ADD_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_TLSDESC_ADR_PAGE21 = 562
pkg debug/elf, const R_AARCH64_TLSDESC_ADR_PAGE21 R_AARCH64
pkg debug/elf, const R_AARCH64_TLSDESC_ADR_PREL21 = 561
pkg debug/elf, const R_AARCH64_TLSDESC_ADR_PREL21 R_AARCH64
pkg debug/elf, const R_AARCH64_TLSDESC_CALL = 569
pkg debug/elf, const R_AARCH64_TLSDESC_CALL R_AARCH64
pkg debug/elf, const R_AARCH64_TLSDESC_LD64_LO12_NC = 563
pkg debug/elf, const R_AARCH64_TLSDESC_LD64_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_TLSDESC_LDR = 567
pkg debug/elf, const R_AARCH64_TLSDESC_LDR R_AARCH64
pkg debug/elf, const R_AARCH64_TLSDESC_LD_PREL19 = 560
pkg debug/elf, const R_AARCH64_TLSDESC_LD_PREL19 R_AARCH64
pkg debug/elf, const R_AARCH64_TLSDESC_OFF_G0_NC = 566
pkg debug/elf, const R_AARCH64_TLSDESC_OFF_G0_NC R_AARCH64
pkg debug/elf, const R_AARCH64_TLSDESC_OFF_G1 = 565
pkg debug/elf, const R_AARCH64_TLSDESC_OFF_G1 R_AARCH64
pkg debug/elf, const R_AARCH64_TLSGD_ADD_LO12_NC = 514
pkg debug/elf, const R_AARCH64_TLSGD_ADD_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_TLSGD_ADR_PAGE21 = 513
pkg debug/elf, const R_AARCH64_TLSGD_ADR_PAGE21 R_AARCH64
pkg debug/elf, const R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21 = 541
pkg debug/elf, const R_AARCH64_TLSIE_ADR_GOTTPREL_PAGE21 R_AARCH64
pkg debug/elf, const R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC = 542
pkg debug/elf, const R_AARCH64_TLSIE_LD64_GOTTPREL_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_TLSIE_LD_GOTTPREL_PREL19 = 543
pkg debug/elf, const R_AARCH64_TLSIE_LD_GOTTPREL_PREL19 R_AARCH64
pkg debug/elf, const R_AARCH64_TLSIE_MOVW_GOTTPREL_G0_NC = 540
pkg debug/elf, const R_AARCH64_TLSIE_MOVW_GOTTPREL_G0_NC R_AARCH64
pkg debug/elf, const R_AARCH64_TLSIE_MOVW_GOTTPREL_G1 = 539
pkg debug/elf, const R_AARCH64_TLSIE_MOVW_GOTTPREL_G1 R_AARCH64
pkg debug/elf, const R_AARCH64_TLSLE_ADD_TPREL_HI12 = 549
pkg debug/elf, const R_AARCH64_TLSLE_ADD_TPREL_HI12 R_AARCH64
pkg debug/elf, const R_AARCH64_TLSLE_ADD_TPREL_LO12 = 550
pkg debug/elf, const R_AARCH64_TLSLE_ADD_TPREL_LO12 R_AARCH64
pkg debug/elf, const R_AARCH64_TLSLE_ADD_TPREL_LO12_NC = 551
pkg debug/elf, const R_AARCH64_TLSLE_ADD_TPREL_LO12_NC R_AARCH64
pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G0 = 547
pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G0 R_AARCH64
pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G0_NC = 548
pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G0_NC R_AARCH64
pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G1 = 545
pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G1 R_AARCH64
pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G1_NC = 546
pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G1_NC R_AARCH64
pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G2 = 544
pkg debug/elf, const R_AARCH64_TLSLE_MOVW_TPREL_G2 R_AARCH64
pkg debug/elf, const R_AARCH64_TLS_DTPMOD64 = 1028
pkg debug/elf, const R_AARCH64_TLS_DTPMOD64 R_AARCH64
pkg debug/elf, const R_AARCH64_TLS_DTPREL64 = 1029
pkg debug/elf, const R_AARCH64_TLS_DTPREL64 R_AARCH64
pkg debug/elf, const R_AARCH64_TLS_TPREL64 = 1030
pkg debug/elf, const R_AARCH64_TLS_TPREL64 R_AARCH64
pkg debug/elf, const R_AARCH64_TSTBR14 = 279
pkg debug/elf, const R_AARCH64_TSTBR14 R_AARCH64
pkg debug/elf, method (R_AARCH64) GoString() string
pkg debug/elf, method (R_AARCH64) String() string
pkg debug/elf, type R_AARCH64 int
# CL 107530043 debug/elf: add (*File).DynamicSymbols, ErrNoSymbols, and tests for (*File).Symbols and (*File).DynamicSymbols, and formalize symbol order., Pietro Gagliardi <pietro10@mac.com>
pkg debug/elf, method (*File) DynamicSymbols() ([]Symbol, error)
pkg debug/elf, var ErrNoSymbols error
# CL 106460044 debug/plan9obj, cmd/addr2line: on Plan 9 use a.out header, Aram Hăvărneanu <aram@mgk.ro>
pkg debug/plan9obj, type FileHeader struct, HdrSize uint64
pkg debug/plan9obj, type FileHeader struct, LoadAddress uint64
# CL 122960043 encoding/xml: add InputOffset method to Decoder, Russ Cox <rsc@golang.org>
pkg encoding/xml, method (*Decoder) InputOffset() int64
# CL 124940043 cmd/go, go/build: implement import comment checking, Russ Cox <rsc@golang.org>
pkg go/build, const ImportComment = 4
pkg go/build, const ImportComment ImportMode
pkg go/build, type Package struct, ImportComment string
# CL 155050043 go/build: Return MultiplePackageError on importing a dir containing multiple packages, Jens Frederich <jfrederich@gmail.com>
pkg go/build, method (*MultiplePackageError) Error() string
pkg go/build, type MultiplePackageError struct
pkg go/build, type MultiplePackageError struct, Dir string
pkg go/build, type MultiplePackageError struct, Files []string
pkg go/build, type MultiplePackageError struct, Packages []string
# CL 135110044 go/token: implement PositionFor accessors, Robert Griesemer <gri@golang.org>
pkg go/token, method (*File) PositionFor(Pos, bool) Position
pkg go/token, method (*FileSet) PositionFor(Pos, bool) Position
# CL 109000049 image: add RGBAAt, Gray16At, etc., ChaiShushan <chaishushan@gmail.com>
pkg image, method (*Alpha) AlphaAt(int, int) color.Alpha
pkg image, method (*Alpha16) Alpha16At(int, int) color.Alpha16
pkg image, method (*Gray) GrayAt(int, int) color.Gray
pkg image, method (*Gray16) Gray16At(int, int) color.Gray16
pkg image, method (*NRGBA) NRGBAAt(int, int) color.NRGBA
pkg image, method (*NRGBA64) NRGBA64At(int, int) color.NRGBA64
pkg image, method (*RGBA) RGBAAt(int, int) color.RGBA
pkg image, method (*RGBA64) RGBA64At(int, int) color.RGBA64
pkg image, method (*YCbCr) YCbCrAt(int, int) color.YCbCr
# CL 129190043 png: make the encoder configurable, Jeff R. Allen <jra@nella.org>
pkg image/png, const BestCompression = -3
pkg image/png, const BestCompression CompressionLevel
pkg image/png, const BestSpeed = -2
pkg image/png, const BestSpeed CompressionLevel
pkg image/png, const DefaultCompression = 0
pkg image/png, const DefaultCompression CompressionLevel
pkg image/png, const NoCompression = -1
pkg image/png, const NoCompression CompressionLevel
pkg image/png, method (*Encoder) Encode(io.Writer, image.Image) error
pkg image/png, type CompressionLevel int
pkg image/png, type Encoder struct
pkg image/png, type Encoder struct, CompressionLevel CompressionLevel
# CL 101750048 math: implement Nextafter32, Robert Griesemer <gri@golang.org>
pkg math, func Nextafter32(float32, float32) float32
# CL 93550043 math/big: implement Rat.Float32, Robert Griesemer <gri@golang.org>
pkg math/big, method (*Rat) Float32() (float32, bool)
# CL 76540043 net/http: add BasicAuth method to *http.Request, Kelsey Hightower <kelsey.hightower@gmail.com>
pkg net/http, method (*Request) BasicAuth() (string, string, bool)
# CL 137940043 net/http: add Transport.DialTLS hook, Brad Fitzpatrick <bradfitz@golang.org>
pkg net/http, type Transport struct, DialTLS func(string, string) (net.Conn, error)
# CL 132750043 net/http/httputil: Pass a Logger to ReverseProxy, allowing the user to control logging., Mark Theunissen <mark.theunissen@gmail.com>
pkg net/http/httputil, type ReverseProxy struct, ErrorLog *log.Logger
# CL 148370043 os, syscall: add Unsetenv, Brad Fitzpatrick <bradfitz@golang.org>
pkg os, func Unsetenv(string) error
pkg syscall, func Unsetenv(string) error
# CL 144020043 reflect: add Type.Comparable, Russ Cox <rsc@golang.org>
pkg reflect, type Type interface, Comparable() bool
# CL 153670043 runtime: add PauseEnd array to MemStats and GCStats, Jens Frederich <jfrederich@gmail.com>
pkg runtime, type MemStats struct, PauseEnd [256]uint64
pkg runtime/debug, type GCStats struct, PauseEnd []time.Time
# CL 136710045 sync/atomic: add Value, Dmitriy Vyukov <dvyukov@google.com>
pkg sync/atomic, method (*Value) Load() interface{}
pkg sync/atomic, method (*Value) Store(interface{})
pkg sync/atomic, type Value struct
# CL 126190043 syscall: support UID/GID map files for Linux user namespaces, Mrunal Patel <mrunalp@gmail.com>
pkg syscall (linux-386), type SysProcAttr struct, GidMappings []SysProcIDMap
pkg syscall (linux-386), type SysProcAttr struct, UidMappings []SysProcIDMap
pkg syscall (linux-386), type SysProcIDMap struct
pkg syscall (linux-386), type SysProcIDMap struct, ContainerID int
pkg syscall (linux-386), type SysProcIDMap struct, HostID int
pkg syscall (linux-386), type SysProcIDMap struct, Size int
pkg syscall (linux-386-cgo), type SysProcAttr struct, GidMappings []SysProcIDMap
pkg syscall (linux-386-cgo), type SysProcAttr struct, UidMappings []SysProcIDMap
pkg syscall (linux-386-cgo), type SysProcIDMap struct
pkg syscall (linux-386-cgo), type SysProcIDMap struct, ContainerID int
pkg syscall (linux-386-cgo), type SysProcIDMap struct, HostID int
pkg syscall (linux-386-cgo), type SysProcIDMap struct, Size int
pkg syscall (linux-amd64), type SysProcAttr struct, GidMappings []SysProcIDMap
pkg syscall (linux-amd64), type SysProcAttr struct, UidMappings []SysProcIDMap
pkg syscall (linux-amd64), type SysProcIDMap struct
pkg syscall (linux-amd64), type SysProcIDMap struct, ContainerID int
pkg syscall (linux-amd64), type SysProcIDMap struct, HostID int
pkg syscall (linux-amd64), type SysProcIDMap struct, Size int
pkg syscall (linux-amd64-cgo), type SysProcAttr struct, GidMappings []SysProcIDMap
pkg syscall (linux-amd64-cgo), type SysProcAttr struct, UidMappings []SysProcIDMap
pkg syscall (linux-amd64-cgo), type SysProcIDMap struct
pkg syscall (linux-amd64-cgo), type SysProcIDMap struct, ContainerID int
pkg syscall (linux-amd64-cgo), type SysProcIDMap struct, HostID int
pkg syscall (linux-amd64-cgo), type SysProcIDMap struct, Size int
pkg syscall (linux-arm), type SysProcAttr struct, GidMappings []SysProcIDMap
pkg syscall (linux-arm), type SysProcAttr struct, UidMappings []SysProcIDMap
pkg syscall (linux-arm), type SysProcIDMap struct
pkg syscall (linux-arm), type SysProcIDMap struct, ContainerID int
pkg syscall (linux-arm), type SysProcIDMap struct, HostID int
pkg syscall (linux-arm), type SysProcIDMap struct, Size int
pkg syscall (linux-arm-cgo), type SysProcAttr struct, GidMappings []SysProcIDMap
pkg syscall (linux-arm-cgo), type SysProcAttr struct, UidMappings []SysProcIDMap
pkg syscall (linux-arm-cgo), type SysProcIDMap struct
pkg syscall (linux-arm-cgo), type SysProcIDMap struct, ContainerID int
pkg syscall (linux-arm-cgo), type SysProcIDMap struct, HostID int
pkg syscall (linux-arm-cgo), type SysProcIDMap struct, Size int
# CL 122200043 net: fix CNAME resolving on Windows, Egon Elbre <egonelbre@gmail.com>
pkg syscall (windows-386), const DNS_INFO_NO_RECORDS = 9501
pkg syscall (windows-386), const DNS_INFO_NO_RECORDS ideal-int
pkg syscall (windows-386), const DnsSectionAdditional = 3
pkg syscall (windows-386), const DnsSectionAdditional ideal-int
pkg syscall (windows-386), const DnsSectionAnswer = 1
pkg syscall (windows-386), const DnsSectionAnswer ideal-int
pkg syscall (windows-386), const DnsSectionAuthority = 2
pkg syscall (windows-386), const DnsSectionAuthority ideal-int
pkg syscall (windows-386), const DnsSectionQuestion = 0
pkg syscall (windows-386), const DnsSectionQuestion ideal-int
pkg syscall (windows-386), func DnsNameCompare(*uint16, *uint16) bool
pkg syscall (windows-amd64), const DNS_INFO_NO_RECORDS = 9501
pkg syscall (windows-amd64), const DNS_INFO_NO_RECORDS ideal-int
pkg syscall (windows-amd64), const DnsSectionAdditional = 3
pkg syscall (windows-amd64), const DnsSectionAdditional ideal-int
pkg syscall (windows-amd64), const DnsSectionAnswer = 1
pkg syscall (windows-amd64), const DnsSectionAnswer ideal-int
pkg syscall (windows-amd64), const DnsSectionAuthority = 2
pkg syscall (windows-amd64), const DnsSectionAuthority ideal-int
pkg syscall (windows-amd64), const DnsSectionQuestion = 0
pkg syscall (windows-amd64), const DnsSectionQuestion ideal-int
pkg syscall (windows-amd64), func DnsNameCompare(*uint16, *uint16) bool
# CL 86160044 os: Implement symlink support for Windows, Michael Fraenkel <michael.fraenkel@gmail.com>
pkg syscall (windows-386), const ERROR_PRIVILEGE_NOT_HELD = 1314
pkg syscall (windows-386), const ERROR_PRIVILEGE_NOT_HELD Errno
pkg syscall (windows-amd64), const ERROR_PRIVILEGE_NOT_HELD = 1314
pkg syscall (windows-amd64), const ERROR_PRIVILEGE_NOT_HELD Errno
# CL 86160044 os: Implement symlink support for Windows, Michael Fraenkel <michael.fraenkel@gmail.com>
pkg syscall (windows-386), const FILE_ATTRIBUTE_REPARSE_POINT = 1024
pkg syscall (windows-386), const FILE_ATTRIBUTE_REPARSE_POINT ideal-int
pkg syscall (windows-386), const FILE_FLAG_OPEN_REPARSE_POINT = 2097152
pkg syscall (windows-386), const FILE_FLAG_OPEN_REPARSE_POINT ideal-int
pkg syscall (windows-386), const FSCTL_GET_REPARSE_POINT = 589992
pkg syscall (windows-386), const FSCTL_GET_REPARSE_POINT ideal-int
pkg syscall (windows-386), const IO_REPARSE_TAG_SYMLINK = 2684354572
pkg syscall (windows-386), const IO_REPARSE_TAG_SYMLINK ideal-int
pkg syscall (windows-386), const MAXIMUM_REPARSE_DATA_BUFFER_SIZE = 16384
pkg syscall (windows-386), const MAXIMUM_REPARSE_DATA_BUFFER_SIZE ideal-int
pkg syscall (windows-386), const SYMBOLIC_LINK_FLAG_DIRECTORY = 1
pkg syscall (windows-386), const SYMBOLIC_LINK_FLAG_DIRECTORY ideal-int
pkg syscall (windows-386), func CreateHardLink(*uint16, *uint16, uintptr) error
pkg syscall (windows-386), func CreateSymbolicLink(*uint16, *uint16, uint32) error
pkg syscall (windows-386), func DeviceIoControl(Handle, uint32, *uint8, uint32, *uint8, uint32, *uint32, *Overlapped) error
pkg syscall (windows-386), func LoadCreateSymbolicLink() error
pkg syscall (windows-amd64), const FILE_ATTRIBUTE_REPARSE_POINT = 1024
pkg syscall (windows-amd64), const FILE_ATTRIBUTE_REPARSE_POINT ideal-int
pkg syscall (windows-amd64), const FILE_FLAG_OPEN_REPARSE_POINT = 2097152
pkg syscall (windows-amd64), const FILE_FLAG_OPEN_REPARSE_POINT ideal-int
pkg syscall (windows-amd64), const FSCTL_GET_REPARSE_POINT = 589992
pkg syscall (windows-amd64), const FSCTL_GET_REPARSE_POINT ideal-int
pkg syscall (windows-amd64), const IO_REPARSE_TAG_SYMLINK = 2684354572
pkg syscall (windows-amd64), const IO_REPARSE_TAG_SYMLINK ideal-int
pkg syscall (windows-amd64), const MAXIMUM_REPARSE_DATA_BUFFER_SIZE = 16384
pkg syscall (windows-amd64), const MAXIMUM_REPARSE_DATA_BUFFER_SIZE ideal-int
pkg syscall (windows-amd64), const SYMBOLIC_LINK_FLAG_DIRECTORY = 1
pkg syscall (windows-amd64), const SYMBOLIC_LINK_FLAG_DIRECTORY ideal-int
pkg syscall (windows-amd64), func CreateHardLink(*uint16, *uint16, uintptr) error
pkg syscall (windows-amd64), func CreateSymbolicLink(*uint16, *uint16, uint32) error
pkg syscall (windows-amd64), func DeviceIoControl(Handle, uint32, *uint8, uint32, *uint8, uint32, *uint32, *Overlapped) error
pkg syscall (windows-amd64), func LoadCreateSymbolicLink() error
# CL 149510043 net: disable SIO_UDP_CONNRESET behavior on windows., Ron Hashimoto <mail@h2so5.net>
pkg syscall (windows-386), const SIO_UDP_CONNRESET = 2550136844
pkg syscall (windows-386), const SIO_UDP_CONNRESET ideal-int
pkg syscall (windows-amd64), const SIO_UDP_CONNRESET = 2550136844
pkg syscall (windows-amd64), const SIO_UDP_CONNRESET ideal-int
# CL 102320044 syscall: implement syscall.Getppid() on Windows, Alan Shreve <alan@inconshreveable.com>
pkg syscall (windows-386), const TH32CS_INHERIT = 2147483648
pkg syscall (windows-386), const TH32CS_INHERIT ideal-int
pkg syscall (windows-386), const TH32CS_SNAPALL = 15
pkg syscall (windows-386), const TH32CS_SNAPALL ideal-int
pkg syscall (windows-386), const TH32CS_SNAPHEAPLIST = 1
pkg syscall (windows-386), const TH32CS_SNAPHEAPLIST ideal-int
pkg syscall (windows-386), const TH32CS_SNAPMODULE = 8
pkg syscall (windows-386), const TH32CS_SNAPMODULE ideal-int
pkg syscall (windows-386), const TH32CS_SNAPMODULE32 = 16
pkg syscall (windows-386), const TH32CS_SNAPMODULE32 ideal-int
pkg syscall (windows-386), const TH32CS_SNAPPROCESS = 2
pkg syscall (windows-386), const TH32CS_SNAPPROCESS ideal-int
pkg syscall (windows-386), const TH32CS_SNAPTHREAD = 4
pkg syscall (windows-386), const TH32CS_SNAPTHREAD ideal-int
pkg syscall (windows-386), func CreateToolhelp32Snapshot(uint32, uint32) (Handle, error)
pkg syscall (windows-386), func Process32First(Handle, *ProcessEntry32) error
pkg syscall (windows-386), func Process32Next(Handle, *ProcessEntry32) error
pkg syscall (windows-386), type ProcessEntry32 struct
pkg syscall (windows-386), type ProcessEntry32 struct, DefaultHeapID uintptr
pkg syscall (windows-386), type ProcessEntry32 struct, ExeFile [260]uint16
pkg syscall (windows-386), type ProcessEntry32 struct, Flags uint32
pkg syscall (windows-386), type ProcessEntry32 struct, ModuleID uint32
pkg syscall (windows-386), type ProcessEntry32 struct, ParentProcessID uint32
pkg syscall (windows-386), type ProcessEntry32 struct, PriClassBase int32
pkg syscall (windows-386), type ProcessEntry32 struct, ProcessID uint32
pkg syscall (windows-386), type ProcessEntry32 struct, Size uint32
pkg syscall (windows-386), type ProcessEntry32 struct, Threads uint32
pkg syscall (windows-386), type ProcessEntry32 struct, Usage uint32
pkg syscall (windows-amd64), const TH32CS_INHERIT = 2147483648
pkg syscall (windows-amd64), const TH32CS_INHERIT ideal-int
pkg syscall (windows-amd64), const TH32CS_SNAPALL = 15
pkg syscall (windows-amd64), const TH32CS_SNAPALL ideal-int
pkg syscall (windows-amd64), const TH32CS_SNAPHEAPLIST = 1
pkg syscall (windows-amd64), const TH32CS_SNAPHEAPLIST ideal-int
pkg syscall (windows-amd64), const TH32CS_SNAPMODULE = 8
pkg syscall (windows-amd64), const TH32CS_SNAPMODULE ideal-int
pkg syscall (windows-amd64), const TH32CS_SNAPMODULE32 = 16
pkg syscall (windows-amd64), const TH32CS_SNAPMODULE32 ideal-int
pkg syscall (windows-amd64), const TH32CS_SNAPPROCESS = 2
pkg syscall (windows-amd64), const TH32CS_SNAPPROCESS ideal-int
pkg syscall (windows-amd64), const TH32CS_SNAPTHREAD = 4
pkg syscall (windows-amd64), const TH32CS_SNAPTHREAD ideal-int
pkg syscall (windows-amd64), func CreateToolhelp32Snapshot(uint32, uint32) (Handle, error)
pkg syscall (windows-amd64), func Process32First(Handle, *ProcessEntry32) error
pkg syscall (windows-amd64), func Process32Next(Handle, *ProcessEntry32) error
pkg syscall (windows-amd64), type ProcessEntry32 struct
pkg syscall (windows-amd64), type ProcessEntry32 struct, DefaultHeapID uintptr
pkg syscall (windows-amd64), type ProcessEntry32 struct, ExeFile [260]uint16
pkg syscall (windows-amd64), type ProcessEntry32 struct, Flags uint32
pkg syscall (windows-amd64), type ProcessEntry32 struct, ModuleID uint32
pkg syscall (windows-amd64), type ProcessEntry32 struct, ParentProcessID uint32
pkg syscall (windows-amd64), type ProcessEntry32 struct, PriClassBase int32
pkg syscall (windows-amd64), type ProcessEntry32 struct, ProcessID uint32
pkg syscall (windows-amd64), type ProcessEntry32 struct, Size uint32
pkg syscall (windows-amd64), type ProcessEntry32 struct, Threads uint32
pkg syscall (windows-amd64), type ProcessEntry32 struct, Usage uint32
# CL 127740043 os: make SameFile handle paths like c:a.txt properly, Alex Brainman <alex.brainman@gmail.com>
pkg syscall (windows-386), func FullPath(string) (string, error)
pkg syscall (windows-amd64), func FullPath(string) (string, error)
# CL 98150043 testing: add Coverage function, Russ Cox <rsc@golang.org>
pkg testing, func Coverage() float64
# CL 148770043 cmd/go, testing: add TestMain support, Russ Cox <rsc@golang.org>
pkg testing, func MainStart(func(string, string) (bool, error), []InternalTest, []InternalBenchmark, []InternalExample) *M
pkg testing, method (*M) Run() int
pkg testing, type M struct
# CL 108030044 text/scanner: provide facility for custom identifiers, Robert Griesemer <gri@golang.org>
pkg text/scanner, type Scanner struct, IsIdentRune func(int32, int) bool
# CL 130620043 text/template: add back pointer to Nodes for better error generation, Rob Pike <r@golang.org>
pkg text/template/parse, type DotNode struct, embedded NodeType
pkg text/template/parse, type NilNode struct, embedded NodeType
pkg text/template/parse, method (*BranchNode) Copy() Node
pkg text/template/parse, method (*IdentifierNode) SetTree(*Tree) *IdentifierNode
pkg html/template, type Error struct, Node parse.Node
# CL 127470043 unicode: strconv: regexp: Upgrade to Unicode 7.0.0., Marcel van Lohuizen <mpvl@golang.org>
pkg unicode, const Version = "7.0.0"
pkg unicode, var Bassa_Vah *RangeTable
pkg unicode, var Caucasian_Albanian *RangeTable
pkg unicode, var Duployan *RangeTable
pkg unicode, var Elbasan *RangeTable
pkg unicode, var Grantha *RangeTable
pkg unicode, var Khojki *RangeTable
pkg unicode, var Khudawadi *RangeTable
pkg unicode, var Linear_A *RangeTable
pkg unicode, var Mahajani *RangeTable
pkg unicode, var Manichaean *RangeTable
pkg unicode, var Mende_Kikakui *RangeTable
pkg unicode, var Modi *RangeTable
pkg unicode, var Mro *RangeTable
pkg unicode, var Nabataean *RangeTable
pkg unicode, var Old_North_Arabian *RangeTable
pkg unicode, var Old_Permic *RangeTable
pkg unicode, var Pahawh_Hmong *RangeTable
pkg unicode, var Palmyrene *RangeTable
pkg unicode, var Pau_Cin_Hau *RangeTable
pkg unicode, var Psalter_Pahlavi *RangeTable
pkg unicode, var Siddham *RangeTable
pkg unicode, var Tirhuta *RangeTable
pkg unicode, var Warang_Citi *RangeTable

View File

@@ -1,249 +1,117 @@
pkg debug/elf, const R_PPC64_ADDR14 = 7
pkg debug/elf, const R_PPC64_ADDR14 R_PPC64
pkg debug/elf, const R_PPC64_ADDR14_BRNTAKEN = 9
pkg debug/elf, const R_PPC64_ADDR14_BRNTAKEN R_PPC64
pkg debug/elf, const R_PPC64_ADDR14_BRTAKEN = 8
pkg debug/elf, const R_PPC64_ADDR14_BRTAKEN R_PPC64
pkg debug/elf, const R_PPC64_ADDR16 = 3
pkg debug/elf, const R_PPC64_ADDR16 R_PPC64
pkg debug/elf, const R_PPC64_ADDR16_DS = 56
pkg debug/elf, const R_PPC64_ADDR16_DS R_PPC64
pkg debug/elf, const R_PPC64_ADDR16_HA = 6
pkg debug/elf, const R_PPC64_ADDR16_HA R_PPC64
pkg debug/elf, const R_PPC64_ADDR16_HI = 5
pkg debug/elf, const R_PPC64_ADDR16_HI R_PPC64
pkg debug/elf, const R_PPC64_ADDR16_HIGHER = 39
pkg debug/elf, const R_PPC64_ADDR16_HIGHER R_PPC64
pkg debug/elf, const R_PPC64_ADDR16_HIGHERA = 40
pkg debug/elf, const R_PPC64_ADDR16_HIGHERA R_PPC64
pkg debug/elf, const R_PPC64_ADDR16_HIGHEST = 41
pkg debug/elf, const R_PPC64_ADDR16_HIGHEST R_PPC64
pkg debug/elf, const R_PPC64_ADDR16_HIGHESTA = 42
pkg debug/elf, const R_PPC64_ADDR16_HIGHESTA R_PPC64
pkg debug/elf, const R_PPC64_ADDR16_LO = 4
pkg debug/elf, const R_PPC64_ADDR16_LO R_PPC64
pkg debug/elf, const R_PPC64_ADDR16_LO_DS = 57
pkg debug/elf, const R_PPC64_ADDR16_LO_DS R_PPC64
pkg debug/elf, const R_PPC64_ADDR24 = 2
pkg debug/elf, const R_PPC64_ADDR24 R_PPC64
pkg debug/elf, const R_PPC64_ADDR32 = 1
pkg debug/elf, const R_PPC64_ADDR32 R_PPC64
pkg debug/elf, const R_PPC64_ADDR64 = 38
pkg debug/elf, const R_PPC64_ADDR64 R_PPC64
pkg debug/elf, const R_PPC64_DTPMOD64 = 68
pkg debug/elf, const R_PPC64_DTPMOD64 R_PPC64
pkg debug/elf, const R_PPC64_DTPREL16 = 74
pkg debug/elf, const R_PPC64_DTPREL16 R_PPC64
pkg debug/elf, const R_PPC64_DTPREL16_DS = 101
pkg debug/elf, const R_PPC64_DTPREL16_DS R_PPC64
pkg debug/elf, const R_PPC64_DTPREL16_HA = 77
pkg debug/elf, const R_PPC64_DTPREL16_HA R_PPC64
pkg debug/elf, const R_PPC64_DTPREL16_HI = 76
pkg debug/elf, const R_PPC64_DTPREL16_HI R_PPC64
pkg debug/elf, const R_PPC64_DTPREL16_HIGHER = 103
pkg debug/elf, const R_PPC64_DTPREL16_HIGHER R_PPC64
pkg debug/elf, const R_PPC64_DTPREL16_HIGHERA = 104
pkg debug/elf, const R_PPC64_DTPREL16_HIGHERA R_PPC64
pkg debug/elf, const R_PPC64_DTPREL16_HIGHEST = 105
pkg debug/elf, const R_PPC64_DTPREL16_HIGHEST R_PPC64
pkg debug/elf, const R_PPC64_DTPREL16_HIGHESTA = 106
pkg debug/elf, const R_PPC64_DTPREL16_HIGHESTA R_PPC64
pkg debug/elf, const R_PPC64_DTPREL16_LO = 75
pkg debug/elf, const R_PPC64_DTPREL16_LO R_PPC64
pkg debug/elf, const R_PPC64_DTPREL16_LO_DS = 102
pkg debug/elf, const R_PPC64_DTPREL16_LO_DS R_PPC64
pkg debug/elf, const R_PPC64_DTPREL64 = 78
pkg debug/elf, const R_PPC64_DTPREL64 R_PPC64
pkg debug/elf, const R_PPC64_GOT16 = 14
pkg debug/elf, const R_PPC64_GOT16 R_PPC64
pkg debug/elf, const R_PPC64_GOT16_DS = 58
pkg debug/elf, const R_PPC64_GOT16_DS R_PPC64
pkg debug/elf, const R_PPC64_GOT16_HA = 17
pkg debug/elf, const R_PPC64_GOT16_HA R_PPC64
pkg debug/elf, const R_PPC64_GOT16_HI = 16
pkg debug/elf, const R_PPC64_GOT16_HI R_PPC64
pkg debug/elf, const R_PPC64_GOT16_LO = 15
pkg debug/elf, const R_PPC64_GOT16_LO R_PPC64
pkg debug/elf, const R_PPC64_GOT16_LO_DS = 59
pkg debug/elf, const R_PPC64_GOT16_LO_DS R_PPC64
pkg debug/elf, const R_PPC64_GOT_DTPREL16_DS = 91
pkg debug/elf, const R_PPC64_GOT_DTPREL16_DS R_PPC64
pkg debug/elf, const R_PPC64_GOT_DTPREL16_HA = 94
pkg debug/elf, const R_PPC64_GOT_DTPREL16_HA R_PPC64
pkg debug/elf, const R_PPC64_GOT_DTPREL16_HI = 93
pkg debug/elf, const R_PPC64_GOT_DTPREL16_HI R_PPC64
pkg debug/elf, const R_PPC64_GOT_DTPREL16_LO_DS = 92
pkg debug/elf, const R_PPC64_GOT_DTPREL16_LO_DS R_PPC64
pkg debug/elf, const R_PPC64_GOT_TLSGD16 = 79
pkg debug/elf, const R_PPC64_GOT_TLSGD16 R_PPC64
pkg debug/elf, const R_PPC64_GOT_TLSGD16_HA = 82
pkg debug/elf, const R_PPC64_GOT_TLSGD16_HA R_PPC64
pkg debug/elf, const R_PPC64_GOT_TLSGD16_HI = 81
pkg debug/elf, const R_PPC64_GOT_TLSGD16_HI R_PPC64
pkg debug/elf, const R_PPC64_GOT_TLSGD16_LO = 80
pkg debug/elf, const R_PPC64_GOT_TLSGD16_LO R_PPC64
pkg debug/elf, const R_PPC64_GOT_TLSLD16 = 83
pkg debug/elf, const R_PPC64_GOT_TLSLD16 R_PPC64
pkg debug/elf, const R_PPC64_GOT_TLSLD16_HA = 86
pkg debug/elf, const R_PPC64_GOT_TLSLD16_HA R_PPC64
pkg debug/elf, const R_PPC64_GOT_TLSLD16_HI = 85
pkg debug/elf, const R_PPC64_GOT_TLSLD16_HI R_PPC64
pkg debug/elf, const R_PPC64_GOT_TLSLD16_LO = 84
pkg debug/elf, const R_PPC64_GOT_TLSLD16_LO R_PPC64
pkg debug/elf, const R_PPC64_GOT_TPREL16_DS = 87
pkg debug/elf, const R_PPC64_GOT_TPREL16_DS R_PPC64
pkg debug/elf, const R_PPC64_GOT_TPREL16_HA = 90
pkg debug/elf, const R_PPC64_GOT_TPREL16_HA R_PPC64
pkg debug/elf, const R_PPC64_GOT_TPREL16_HI = 89
pkg debug/elf, const R_PPC64_GOT_TPREL16_HI R_PPC64
pkg debug/elf, const R_PPC64_GOT_TPREL16_LO_DS = 88
pkg debug/elf, const R_PPC64_GOT_TPREL16_LO_DS R_PPC64
pkg debug/elf, const R_PPC64_JMP_SLOT = 21
pkg debug/elf, const R_PPC64_JMP_SLOT R_PPC64
pkg debug/elf, const R_PPC64_NONE = 0
pkg debug/elf, const R_PPC64_NONE R_PPC64
pkg debug/elf, const R_PPC64_REL14 = 11
pkg debug/elf, const R_PPC64_REL14 R_PPC64
pkg debug/elf, const R_PPC64_REL14_BRNTAKEN = 13
pkg debug/elf, const R_PPC64_REL14_BRNTAKEN R_PPC64
pkg debug/elf, const R_PPC64_REL14_BRTAKEN = 12
pkg debug/elf, const R_PPC64_REL14_BRTAKEN R_PPC64
pkg debug/elf, const R_PPC64_REL16 = 249
pkg debug/elf, const R_PPC64_REL16 R_PPC64
pkg debug/elf, const R_PPC64_REL16_HA = 252
pkg debug/elf, const R_PPC64_REL16_HA R_PPC64
pkg debug/elf, const R_PPC64_REL16_HI = 251
pkg debug/elf, const R_PPC64_REL16_HI R_PPC64
pkg debug/elf, const R_PPC64_REL16_LO = 250
pkg debug/elf, const R_PPC64_REL16_LO R_PPC64
pkg debug/elf, const R_PPC64_REL24 = 10
pkg debug/elf, const R_PPC64_REL24 R_PPC64
pkg debug/elf, const R_PPC64_REL32 = 26
pkg debug/elf, const R_PPC64_REL32 R_PPC64
pkg debug/elf, const R_PPC64_REL64 = 44
pkg debug/elf, const R_PPC64_REL64 R_PPC64
pkg debug/elf, const R_PPC64_TLS = 67
pkg debug/elf, const R_PPC64_TLS R_PPC64
pkg debug/elf, const R_PPC64_TLSGD = 107
pkg debug/elf, const R_PPC64_TLSGD R_PPC64
pkg debug/elf, const R_PPC64_TLSLD = 108
pkg debug/elf, const R_PPC64_TLSLD R_PPC64
pkg debug/elf, const R_PPC64_TOC = 51
pkg debug/elf, const R_PPC64_TOC R_PPC64
pkg debug/elf, const R_PPC64_TOC16 = 47
pkg debug/elf, const R_PPC64_TOC16 R_PPC64
pkg debug/elf, const R_PPC64_TOC16_DS = 63
pkg debug/elf, const R_PPC64_TOC16_DS R_PPC64
pkg debug/elf, const R_PPC64_TOC16_HA = 50
pkg debug/elf, const R_PPC64_TOC16_HA R_PPC64
pkg debug/elf, const R_PPC64_TOC16_HI = 49
pkg debug/elf, const R_PPC64_TOC16_HI R_PPC64
pkg debug/elf, const R_PPC64_TOC16_LO = 48
pkg debug/elf, const R_PPC64_TOC16_LO R_PPC64
pkg debug/elf, const R_PPC64_TOC16_LO_DS = 64
pkg debug/elf, const R_PPC64_TOC16_LO_DS R_PPC64
pkg debug/elf, const R_PPC64_TPREL16 = 69
pkg debug/elf, const R_PPC64_TPREL16 R_PPC64
pkg debug/elf, const R_PPC64_TPREL16_DS = 95
pkg debug/elf, const R_PPC64_TPREL16_DS R_PPC64
pkg debug/elf, const R_PPC64_TPREL16_HA = 72
pkg debug/elf, const R_PPC64_TPREL16_HA R_PPC64
pkg debug/elf, const R_PPC64_TPREL16_HI = 71
pkg debug/elf, const R_PPC64_TPREL16_HI R_PPC64
pkg debug/elf, const R_PPC64_TPREL16_HIGHER = 97
pkg debug/elf, const R_PPC64_TPREL16_HIGHER R_PPC64
pkg debug/elf, const R_PPC64_TPREL16_HIGHERA = 98
pkg debug/elf, const R_PPC64_TPREL16_HIGHERA R_PPC64
pkg debug/elf, const R_PPC64_TPREL16_HIGHEST = 99
pkg debug/elf, const R_PPC64_TPREL16_HIGHEST R_PPC64
pkg debug/elf, const R_PPC64_TPREL16_HIGHESTA = 100
pkg debug/elf, const R_PPC64_TPREL16_HIGHESTA R_PPC64
pkg debug/elf, const R_PPC64_TPREL16_LO = 70
pkg debug/elf, const R_PPC64_TPREL16_LO R_PPC64
pkg debug/elf, const R_PPC64_TPREL16_LO_DS = 96
pkg debug/elf, const R_PPC64_TPREL16_LO_DS R_PPC64
pkg debug/elf, const R_PPC64_TPREL64 = 73
pkg debug/elf, const R_PPC64_TPREL64 R_PPC64
pkg debug/elf, method (R_PPC64) GoString() string
pkg debug/elf, method (R_PPC64) String() string
pkg debug/elf, type R_PPC64 int
pkg runtime (openbsd-386), const CLOCK_MONOTONIC = 3
pkg runtime (openbsd-386), const CLOCK_MONOTONIC ideal-int
pkg runtime (openbsd-386), const CLOCK_PROF = 2
pkg runtime (openbsd-386), const CLOCK_PROF ideal-int
pkg runtime (openbsd-386), const CLOCK_REALTIME = 0
pkg runtime (openbsd-386), const CLOCK_REALTIME ideal-int
pkg runtime (openbsd-386), const CLOCK_VIRTUAL = 1
pkg runtime (openbsd-386), const CLOCK_VIRTUAL ideal-int
pkg runtime (openbsd-386), const CTL_HW = 6
pkg runtime (openbsd-386), const CTL_HW ideal-int
pkg runtime (openbsd-386), const EAGAIN = 35
pkg runtime (openbsd-386), const EAGAIN ideal-int
pkg runtime (openbsd-386), const ENOTSUP = 91
pkg runtime (openbsd-386), const ENOTSUP ideal-int
pkg runtime (openbsd-386), const ESRCH = 3
pkg runtime (openbsd-386), const ESRCH ideal-int
pkg runtime (openbsd-386), const EWOULDBLOCK = 35
pkg runtime (openbsd-386), const EWOULDBLOCK ideal-int
pkg runtime (openbsd-386), const HW_NCPU = 3
pkg runtime (openbsd-386), const HW_NCPU ideal-int
pkg runtime (openbsd-386-cgo), const CLOCK_MONOTONIC = 3
pkg runtime (openbsd-386-cgo), const CLOCK_MONOTONIC ideal-int
pkg runtime (openbsd-386-cgo), const CLOCK_PROF = 2
pkg runtime (openbsd-386-cgo), const CLOCK_PROF ideal-int
pkg runtime (openbsd-386-cgo), const CLOCK_REALTIME = 0
pkg runtime (openbsd-386-cgo), const CLOCK_REALTIME ideal-int
pkg runtime (openbsd-386-cgo), const CLOCK_VIRTUAL = 1
pkg runtime (openbsd-386-cgo), const CLOCK_VIRTUAL ideal-int
pkg runtime (openbsd-386-cgo), const CTL_HW = 6
pkg runtime (openbsd-386-cgo), const CTL_HW ideal-int
pkg runtime (openbsd-386-cgo), const EAGAIN = 35
pkg runtime (openbsd-386-cgo), const EAGAIN ideal-int
pkg runtime (openbsd-386-cgo), const ENOTSUP = 91
pkg runtime (openbsd-386-cgo), const ENOTSUP ideal-int
pkg runtime (openbsd-386-cgo), const ESRCH = 3
pkg runtime (openbsd-386-cgo), const ESRCH ideal-int
pkg runtime (openbsd-386-cgo), const EWOULDBLOCK = 35
pkg runtime (openbsd-386-cgo), const EWOULDBLOCK ideal-int
pkg runtime (openbsd-386-cgo), const HW_NCPU = 3
pkg runtime (openbsd-386-cgo), const HW_NCPU ideal-int
pkg runtime (openbsd-amd64), const CLOCK_MONOTONIC = 3
pkg runtime (openbsd-amd64), const CLOCK_MONOTONIC ideal-int
pkg runtime (openbsd-amd64), const CLOCK_PROF = 2
pkg runtime (openbsd-amd64), const CLOCK_PROF ideal-int
pkg runtime (openbsd-amd64), const CLOCK_REALTIME = 0
pkg runtime (openbsd-amd64), const CLOCK_REALTIME ideal-int
pkg runtime (openbsd-amd64), const CLOCK_VIRTUAL = 1
pkg runtime (openbsd-amd64), const CLOCK_VIRTUAL ideal-int
pkg runtime (openbsd-amd64), const CTL_HW = 6
pkg runtime (openbsd-amd64), const CTL_HW ideal-int
pkg runtime (openbsd-amd64), const EAGAIN = 35
pkg runtime (openbsd-amd64), const EAGAIN ideal-int
pkg runtime (openbsd-amd64), const ENOTSUP = 91
pkg runtime (openbsd-amd64), const ENOTSUP ideal-int
pkg runtime (openbsd-amd64), const ESRCH = 3
pkg runtime (openbsd-amd64), const ESRCH ideal-int
pkg runtime (openbsd-amd64), const EWOULDBLOCK = 35
pkg runtime (openbsd-amd64), const EWOULDBLOCK ideal-int
pkg runtime (openbsd-amd64), const HW_NCPU = 3
pkg runtime (openbsd-amd64), const HW_NCPU ideal-int
pkg runtime (openbsd-amd64-cgo), const CLOCK_MONOTONIC = 3
pkg runtime (openbsd-amd64-cgo), const CLOCK_MONOTONIC ideal-int
pkg runtime (openbsd-amd64-cgo), const CLOCK_PROF = 2
pkg runtime (openbsd-amd64-cgo), const CLOCK_PROF ideal-int
pkg runtime (openbsd-amd64-cgo), const CLOCK_REALTIME = 0
pkg runtime (openbsd-amd64-cgo), const CLOCK_REALTIME ideal-int
pkg runtime (openbsd-amd64-cgo), const CLOCK_VIRTUAL = 1
pkg runtime (openbsd-amd64-cgo), const CLOCK_VIRTUAL ideal-int
pkg runtime (openbsd-amd64-cgo), const CTL_HW = 6
pkg runtime (openbsd-amd64-cgo), const CTL_HW ideal-int
pkg runtime (openbsd-amd64-cgo), const EAGAIN = 35
pkg runtime (openbsd-amd64-cgo), const EAGAIN ideal-int
pkg runtime (openbsd-amd64-cgo), const ENOTSUP = 91
pkg runtime (openbsd-amd64-cgo), const ENOTSUP ideal-int
pkg runtime (openbsd-amd64-cgo), const ESRCH = 3
pkg runtime (openbsd-amd64-cgo), const ESRCH ideal-int
pkg runtime (openbsd-amd64-cgo), const EWOULDBLOCK = 35
pkg runtime (openbsd-amd64-cgo), const EWOULDBLOCK ideal-int
pkg runtime (openbsd-amd64-cgo), const HW_NCPU = 3
pkg runtime (openbsd-amd64-cgo), const HW_NCPU ideal-int
pkg debug/goobj, const SBSS = 21
pkg debug/goobj, const SBSS SymKind
pkg debug/goobj, const SCONST = 31
pkg debug/goobj, const SCONST SymKind
pkg debug/goobj, const SDATA = 19
pkg debug/goobj, const SDATA SymKind
pkg debug/goobj, const SDYNIMPORT = 32
pkg debug/goobj, const SDYNIMPORT SymKind
pkg debug/goobj, const SELFROSECT = 12
pkg debug/goobj, const SELFROSECT SymKind
pkg debug/goobj, const SELFRXSECT = 2
pkg debug/goobj, const SELFRXSECT SymKind
pkg debug/goobj, const SELFSECT = 14
pkg debug/goobj, const SELFSECT SymKind
pkg debug/goobj, const SFILE = 29
pkg debug/goobj, const SFILE SymKind
pkg debug/goobj, const SFILEPATH = 30
pkg debug/goobj, const SFILEPATH SymKind
pkg debug/goobj, const SFUNCTAB = 8
pkg debug/goobj, const SFUNCTAB SymKind
pkg debug/goobj, const SGOFUNC = 6
pkg debug/goobj, const SGOFUNC SymKind
pkg debug/goobj, const SGOSTRING = 5
pkg debug/goobj, const SGOSTRING SymKind
pkg debug/goobj, const SHOSTOBJ = 33
pkg debug/goobj, const SHOSTOBJ SymKind
pkg debug/goobj, const SINITARR = 18
pkg debug/goobj, const SINITARR SymKind
pkg debug/goobj, const SMACHO = 15
pkg debug/goobj, const SMACHO SymKind
pkg debug/goobj, const SMACHOGOT = 16
pkg debug/goobj, const SMACHOGOT SymKind
pkg debug/goobj, const SMACHOINDIRECTGOT = 28
pkg debug/goobj, const SMACHOINDIRECTGOT SymKind
pkg debug/goobj, const SMACHOINDIRECTPLT = 27
pkg debug/goobj, const SMACHOINDIRECTPLT SymKind
pkg debug/goobj, const SMACHOPLT = 13
pkg debug/goobj, const SMACHOPLT SymKind
pkg debug/goobj, const SMACHOSYMSTR = 25
pkg debug/goobj, const SMACHOSYMSTR SymKind
pkg debug/goobj, const SMACHOSYMTAB = 26
pkg debug/goobj, const SMACHOSYMTAB SymKind
pkg debug/goobj, const SNOPTRBSS = 22
pkg debug/goobj, const SNOPTRBSS SymKind
pkg debug/goobj, const SNOPTRDATA = 17
pkg debug/goobj, const SNOPTRDATA SymKind
pkg debug/goobj, const SPCLNTAB = 11
pkg debug/goobj, const SPCLNTAB SymKind
pkg debug/goobj, const SRODATA = 7
pkg debug/goobj, const SRODATA SymKind
pkg debug/goobj, const SSTRING = 4
pkg debug/goobj, const SSTRING SymKind
pkg debug/goobj, const SSYMTAB = 10
pkg debug/goobj, const SSYMTAB SymKind
pkg debug/goobj, const STEXT = 1
pkg debug/goobj, const STEXT SymKind
pkg debug/goobj, const STLSBSS = 23
pkg debug/goobj, const STLSBSS SymKind
pkg debug/goobj, const STYPE = 3
pkg debug/goobj, const STYPE SymKind
pkg debug/goobj, const STYPELINK = 9
pkg debug/goobj, const STYPELINK SymKind
pkg debug/goobj, const SWINDOWS = 20
pkg debug/goobj, const SWINDOWS SymKind
pkg debug/goobj, const SXREF = 24
pkg debug/goobj, const SXREF SymKind
pkg debug/goobj, func Parse(io.ReadSeeker, string) (*Package, error)
pkg debug/goobj, method (Sym) String() string
pkg debug/goobj, method (SymID) String() string
pkg debug/goobj, method (SymKind) String() string
pkg debug/goobj, type Data struct
pkg debug/goobj, type Data struct, Offset int64
pkg debug/goobj, type Data struct, Size int64
pkg debug/goobj, type Func struct
pkg debug/goobj, type Func struct, Args int
pkg debug/goobj, type Func struct, File []string
pkg debug/goobj, type Func struct, Frame int
pkg debug/goobj, type Func struct, FuncData []FuncData
pkg debug/goobj, type Func struct, Leaf bool
pkg debug/goobj, type Func struct, NoSplit bool
pkg debug/goobj, type Func struct, PCData []Data
pkg debug/goobj, type Func struct, PCFile Data
pkg debug/goobj, type Func struct, PCLine Data
pkg debug/goobj, type Func struct, PCSP Data
pkg debug/goobj, type Func struct, Var []Var
pkg debug/goobj, type FuncData struct
pkg debug/goobj, type FuncData struct, Offset int64
pkg debug/goobj, type FuncData struct, Sym SymID
pkg debug/goobj, type Package struct
pkg debug/goobj, type Package struct, ImportPath string
pkg debug/goobj, type Package struct, Imports []string
pkg debug/goobj, type Package struct, MaxVersion int
pkg debug/goobj, type Package struct, Syms []*Sym
pkg debug/goobj, type Reloc struct
pkg debug/goobj, type Reloc struct, Add int
pkg debug/goobj, type Reloc struct, Offset int
pkg debug/goobj, type Reloc struct, Size int
pkg debug/goobj, type Reloc struct, Sym SymID
pkg debug/goobj, type Reloc struct, Type int
pkg debug/goobj, type Sym struct
pkg debug/goobj, type Sym struct, Data Data
pkg debug/goobj, type Sym struct, DupOK bool
pkg debug/goobj, type Sym struct, Func *Func
pkg debug/goobj, type Sym struct, Kind SymKind
pkg debug/goobj, type Sym struct, Reloc []Reloc
pkg debug/goobj, type Sym struct, Size int
pkg debug/goobj, type Sym struct, Type SymID
pkg debug/goobj, type Sym struct, embedded SymID
pkg debug/goobj, type SymID struct
pkg debug/goobj, type SymID struct, Name string
pkg debug/goobj, type SymID struct, Version int
pkg debug/goobj, type SymKind int
pkg debug/goobj, type Var struct
pkg debug/goobj, type Var struct, Kind int
pkg debug/goobj, type Var struct, Name string
pkg debug/goobj, type Var struct, Offset int
pkg debug/goobj, type Var struct, Type SymID

View File

@@ -78,18 +78,17 @@ well-established conventions.</p>
source code. For Bitbucket, GitHub, Google Code, and Launchpad, the
root directory of the repository is identified by the repository's
main URL, without the <code>http://</code> prefix. Subdirectories are named by
adding to that path.
For example, the Go example programs are obtained by running</p>
adding to that path. For example, the supplemental networking
libraries for Go are obtained by running</p>
<pre>
git clone https://github.com/golang/example
hg clone http://code.google.com/p/go.net
</pre>
<p>and thus the import path for the root directory of that repository is
"<code>github.com/golang/example</code>".
The <a href="https://godoc.org/github.com/golang/example/stringutil">stringutil</a>
package is stored in a subdirectory, so its import path is
"<code>github.com/golang/example/stringutil</code>".</p>
"<code>code.google.com/p/go.net</code>". The websocket package is stored in a
subdirectory, so its import path is
"<code>code.google.com/p/go.net/websocket</code>".</p>
<p>These paths are on the long side, but in exchange we get an
automatically managed name space for import paths and the ability for
@@ -100,7 +99,7 @@ deduce where to obtain the source code.</p>
in a known way from the import path. Specifically, the first choice
is <code>$GOPATH/src/&lt;import-path&gt;</code>. If <code>$GOPATH</code> is
unset, the go command will fall back to storing source code alongside the
standard Go packages, in <code>$GOROOT/src/&lt;import-path&gt;</code>.
standard Go packages, in <code>$GOROOT/src/pkg/&lt;import-path&gt;</code>.
If <code>$GOPATH</code> is set to a list of paths, the go command tries
<code>&lt;dir&gt;/src/&lt;import-path&gt;</code> for each of the directories in
that list.</p>

View File

@@ -57,35 +57,35 @@ Here is an example:
WARNING: DATA RACE
Read by goroutine 185:
net.(*pollServer).AddFD()
src/net/fd_unix.go:89 +0x398
src/pkg/net/fd_unix.go:89 +0x398
net.(*pollServer).WaitWrite()
src/net/fd_unix.go:247 +0x45
src/pkg/net/fd_unix.go:247 +0x45
net.(*netFD).Write()
src/net/fd_unix.go:540 +0x4d4
src/pkg/net/fd_unix.go:540 +0x4d4
net.(*conn).Write()
src/net/net.go:129 +0x101
src/pkg/net/net.go:129 +0x101
net.func·060()
src/net/timeout_test.go:603 +0xaf
src/pkg/net/timeout_test.go:603 +0xaf
Previous write by goroutine 184:
net.setWriteDeadline()
src/net/sockopt_posix.go:135 +0xdf
src/pkg/net/sockopt_posix.go:135 +0xdf
net.setDeadline()
src/net/sockopt_posix.go:144 +0x9c
src/pkg/net/sockopt_posix.go:144 +0x9c
net.(*conn).SetDeadline()
src/net/net.go:161 +0xe3
src/pkg/net/net.go:161 +0xe3
net.func·061()
src/net/timeout_test.go:616 +0x3ed
src/pkg/net/timeout_test.go:616 +0x3ed
Goroutine 185 (running) created at:
net.func·061()
src/net/timeout_test.go:609 +0x288
src/pkg/net/timeout_test.go:609 +0x288
Goroutine 184 (running) created at:
net.TestProlongTimeout()
src/net/timeout_test.go:618 +0x298
src/pkg/net/timeout_test.go:618 +0x298
testing.tRunner()
src/testing/testing.go:301 +0xe8
src/pkg/testing/testing.go:301 +0xe8
</pre>
<h2 id="Options">Options</h2>
@@ -377,8 +377,7 @@ func (w *Watchdog) Start() {
<h2 id="Supported_Systems">Supported Systems</h2>
<p>
The race detector runs on <code>darwin/amd64</code>, <code>freebsd/amd64</code>,
<code>linux/amd64</code>, and <code>windows/amd64</code>.
The race detector runs on <code>darwin/amd64</code>, <code>linux/amd64</code>, and <code>windows/amd64</code>.
</p>
<h2 id="Runtime_Overheads">Runtime Overhead</h2>

View File

@@ -117,9 +117,6 @@ All user-defined symbols other than jump labels are written as offsets to these
<p>
The <code>SB</code> pseudo-register can be thought of as the origin of memory, so the symbol <code>foo(SB)</code>
is the name <code>foo</code> as an address in memory.
This form is used to name global functions and data.
Adding <code>&lt;&gt;</code> to the name, as in <code>foo&lt;&gt;(SB)</code>, makes the name
visible only in the current source file, like a top-level <code>static</code> declaration in a C file.
</p>
<p>
@@ -131,11 +128,8 @@ Thus <code>0(FP)</code> is the first argument to the function,
When referring to a function argument this way, it is conventional to place the name
at the beginning, as in <code>first_arg+0(FP)</code> and <code>second_arg+8(FP)</code>.
Some of the assemblers enforce this convention, rejecting plain <code>0(FP)</code> and <code>8(FP)</code>.
For assembly functions with Go prototypes, <code>go</code> <code>vet</code> will check that the argument names
For assembly functions with Go prototypes, <code>go vet</code> will check that the argument names
and offsets match.
On 32-bit systems, the low and high 32 bits of a 64-bit value are distinguished by adding
a <code>_lo</code> or <code>_hi</code> suffix to the name, as in <code>arg_lo+0(FP)</code> or <code>arg_hi+4(FP)</code>.
If a Go prototype does not name its result, the expected assembly name is <code>ret</code>.
</p>
<p>
@@ -155,7 +149,7 @@ hardware's <code>SP</code> register.
<p>
Instructions, registers, and assembler directives are always in UPPER CASE to remind you
that assembly programming is a fraught endeavor.
(Exception: the <code>g</code> register renaming on ARM.)
(Exceptions: the <code>m</code> and <code>g</code> register renamings on ARM.)
</p>
<p>
@@ -212,8 +206,6 @@ The frame size <code>$24-8</code> states that the function has a 24-byte frame
and is called with 8 bytes of argument, which live on the caller's frame.
If <code>NOSPLIT</code> is not specified for the <code>TEXT</code>,
the argument size must be provided.
For assembly functions with Go prototypes, <code>go</code> <code>vet</code> will check that the
argument size is correct.
</p>
<p>
@@ -224,20 +216,19 @@ simple name <code>profileloop</code>.
</p>
<p>
Global data symbols are defined by a sequence of initializing
<code>DATA</code> directives followed by a <code>GLOBL</code> directive.
Each <code>DATA</code> directive initializes a section of the
corresponding memory.
The memory not explicitly initialized is zeroed.
The general form of the <code>DATA</code> directive is
For <code>DATA</code> directives, the symbol is followed by a slash and the number
of bytes the memory associated with the symbol occupies.
The arguments are optional flags and the data itself.
For instance,
</p>
<pre>
DATA symbol+offset(SB)/width, value
DATA runtime·isplan9(SB)/4, $1
</pre>
<p>
which initializes the symbol memory at the given offset and width with the given value.
The <code>DATA</code> directives for a given symbol must be written with increasing offsets.
declares the local symbol <code>runtime·isplan9</code> of size 4 and value 1.
Again the symbol has the middle dot and is offset from <code>SB</code>.
</p>
<p>
@@ -246,26 +237,15 @@ The arguments are optional flags and the size of the data being declared as a gl
which will have initial value all zeros unless a <code>DATA</code> directive
has initialized it.
The <code>GLOBL</code> directive must follow any corresponding <code>DATA</code> directives.
</p>
<p>
For example,
This example
</p>
<pre>
DATA divtab&lt;&gt;+0x00(SB)/4, $0xf4f8fcff
DATA divtab&lt;&gt;+0x04(SB)/4, $0xe6eaedf0
...
DATA divtab&lt;&gt;+0x3c(SB)/4, $0x81828384
GLOBL divtab&lt;&gt;(SB), RODATA, $64
GLOBL runtime·tlsoffset(SB), NOPTR, $4
GLOBL runtime·tlsoffset(SB),$4
</pre>
<p>
declares and initializes <code>divtab&lt;&gt;</code>, a read-only 64-byte table of 4-byte integer values,
and declares <code>runtime·tlsoffset</code>, a 4-byte, implicitly zeroed variable that
contains no pointers.
declares <code>runtime·tlsoffset</code> to have size 4.
</p>
<p>
@@ -273,7 +253,7 @@ There may be one or two arguments to the directives.
If there are two, the first is a bit mask of flags,
which can be written as numeric expressions, added or or-ed together,
or can be set symbolically for easier absorption by a human.
Their values, defined in the standard <code>#include</code> file <code>textflag.h</code>, are:
Their values, defined in the file <code>src/cmd/ld/textflag.h</code>, are:
</p>
<ul>
@@ -319,84 +299,6 @@ This is a wrapper function and should not count as disabling <code>recover</code
</li>
</ul>
<h3 id="runtime">Runtime Coordination</h3>
<p>
For garbage collection to run correctly, the runtime must know the
location of pointers in all global data and in most stack frames.
The Go compiler emits this information when compiling Go source files,
but assembly programs must define it explicitly.
</p>
<p>
A data symbol marked with the <code>NOPTR</code> flag (see above)
is treated as containing no pointers to runtime-allocated data.
A data symbol with the <code>RODATA</code> flag
is allocated in read-only memory and is therefore treated
as implicitly marked <code>NOPTR</code>.
A data symbol with a total size smaller than a pointer
is also treated as implicitly marked <code>NOPTR</code>.
It is not possible to define a symbol containing pointers in an assembly source file;
such a symbol must be defined in a Go source file instead.
Assembly source can still refer to the symbol by name
even without <code>DATA</code> and <code>GLOBL</code> directives.
A good general rule of thumb is to define all non-<code>RODATA</code>
symbols in Go instead of in assembly.
</p>
<p>
Each function also needs annotations giving the location of
live pointers in its arguments, results, and local stack frame.
For an assembly function with no pointer results and
either no local stack frame or no function calls,
the only requirement is to define a Go prototype for the function
in a Go source file in the same package. The name of the assembly
function must not contain the package name component (for example,
function <code>Syscall</code> in package <code>syscall</code> should
use the name <code>·Syscall</code> instead of the equivalent name
<code>syscall·Syscall</code> in its <code>TEXT</code> directive).
For more complex situations, explicit annotation is needed.
These annotations use pseudo-instructions defined in the standard
<code>#include</code> file <code>funcdata.h</code>.
</p>
<p>
If a function has no arguments and no results,
the pointer information can be omitted.
This is indicated by an argument size annotation of <code>$<i>n</i>-0</code>
on the <code>TEXT</code> instruction.
Otherwise, pointer information must be provided by
a Go prototype for the function in a Go source file,
even for assembly functions not called directly from Go.
(The prototype will also let <code>go</code> <code>vet</code> check the argument references.)
At the start of the function, the arguments are assumed
to be initialized but the results are assumed uninitialized.
If the results will hold live pointers during a call instruction,
the function should start by zeroing the results and then
executing the pseudo-instruction <code>GO_RESULTS_INITIALIZED</code>.
This instruction records that the results are now initialized
and should be scanned during stack movement and garbage collection.
It is typically easier to arrange that assembly functions do not
return pointers or do not contain call instructions;
no assembly functions in the standard library use
<code>GO_RESULTS_INITIALIZED</code>.
</p>
<p>
If a function has no local stack frame,
the pointer information can be omitted.
This is indicated by a local frame size annotation of <code>$0-<i>n</i></code>
on the <code>TEXT</code> instruction.
The pointer information can also be omitted if the
function contains no call instructions.
Otherwise, the local stack frame must not contain pointers,
and the assembly must confirm this fact by executing the
pseudo-instruction <code>NO_LOCAL_POINTERS</code>.
Because stack resizing is implemented by moving the stack,
the stack pointer may change during any function call:
even pointers to stack data must not be kept in local variables.
</p>
<h2 id="architectures">Architecture-specific details</h2>
<p>
@@ -442,7 +344,7 @@ Here follows some descriptions of key Go-specific details for the supported arch
<h3 id="x86">32-bit Intel 386</h3>
<p>
The runtime pointer to the <code>g</code> structure is maintained
The runtime pointers to the <code>m</code> and <code>g</code> structures are maintained
through the value of an otherwise unused (as far as Go is concerned) register in the MMU.
A OS-dependent macro <code>get_tls</code> is defined for the assembler if the source includes
an architecture-dependent header file, like this:
@@ -454,15 +356,14 @@ an architecture-dependent header file, like this:
<p>
Within the runtime, the <code>get_tls</code> macro loads its argument register
with a pointer to the <code>g</code> pointer, and the <code>g</code> struct
contains the <code>m</code> pointer.
with a pointer to a pair of words representing the <code>g</code> and <code>m</code> pointers.
The sequence to load <code>g</code> and <code>m</code> using <code>CX</code> looks like this:
</p>
<pre>
get_tls(CX)
MOVL g(CX), AX // Move g into AX.
MOVL g_m(AX), BX // Move g->m into BX.
MOVL g(CX), AX // Move g into AX.
MOVL m(CX), BX // Move m into BX.
</pre>
<h3 id="amd64">64-bit Intel 386 (a.k.a. amd64)</h3>
@@ -475,21 +376,22 @@ pointers is the same as on the 386, except it uses <code>MOVQ</code> rather than
<pre>
get_tls(CX)
MOVQ g(CX), AX // Move g into AX.
MOVQ g_m(AX), BX // Move g->m into BX.
MOVQ g(CX), AX // Move g into AX.
MOVQ m(CX), BX // Move m into BX.
</pre>
<h3 id="arm">ARM</h3>
<p>
The registers <code>R10</code> and <code>R11</code>
The registers <code>R9</code>, <code>R10</code>, and <code>R11</code>
are reserved by the compiler and linker.
</p>
<p>
<code>R10</code> points to the <code>g</code> (goroutine) structure.
Within assembler source code, this pointer must be referred to as <code>g</code>;
the name <code>R10</code> is not recognized.
<code>R9</code> and <code>R10</code> point to the <code>m</code> (machine) and <code>g</code>
(goroutine) structures, respectively.
Within assembler source code, these pointers must be referred to as <code>m</code> and <code>g</code>;
the names <code>R9</code> and <code>R10</code> are not recognized.
</p>
<p>
@@ -532,10 +434,13 @@ Here's how the 386 runtime defines the 64-bit atomic load function.
// so actually
// void atomicload64(uint64 *res, uint64 volatile *addr);
TEXT runtime·atomicload64(SB), NOSPLIT, $0-8
MOVL ptr+0(FP), AX
LEAL ret_lo+4(FP), BX
BYTE $0x0f; BYTE $0x6f; BYTE $0x00 // MOVQ (%EAX), %MM0
BYTE $0x0f; BYTE $0x7f; BYTE $0x03 // MOVQ %MM0, 0(%EBX)
BYTE $0x0F; BYTE $0x77 // EMMS
MOVL 4(SP), BX
MOVL 8(SP), AX
// MOVQ (%EAX), %MM0
BYTE $0x0f; BYTE $0x6f; BYTE $0x00
// MOVQ %MM0, 0(%EBX)
BYTE $0x0f; BYTE $0x7f; BYTE $0x03
// EMMS
BYTE $0x0F; BYTE $0x77
RET
</pre>

View File

@@ -62,10 +62,10 @@ details.
</tr>
<tr>
<td><a href="//godoc.org/golang.org/x/tools/cmd/cover/">cover</a></td>
<td><a href="http://godoc.org/code.google.com/p/go.tools/cmd/cover/">cover</a></td>
<td>&nbsp;&nbsp;&nbsp;&nbsp;</td>
<td>Cover is a program for creating and analyzing the coverage profiles
generated by <code>"go test -coverprofile"</code>.</td>
generated by <code>"go test -coverprofile"</code>.
</tr>
<tr>
@@ -83,13 +83,13 @@ gofmt</a> command with more general options.</td>
</tr>
<tr>
<td><a href="//godoc.org/golang.org/x/tools/cmd/godoc/">godoc</a></td>
<td><a href="http://godoc.org/code.google.com/p/go.tools/cmd/godoc/">godoc</a></td>
<td>&nbsp;&nbsp;&nbsp;&nbsp;</td>
<td>Godoc extracts and generates documentation for Go packages.</td>
</tr>
<tr>
<td><a href="//godoc.org/golang.org/x/tools/cmd/vet/">vet</a></td>
<td><a href="http://godoc.org/code.google.com/p/go.tools/cmd/vet/">vet</a></td>
<td>&nbsp;&nbsp;&nbsp;&nbsp;</td>
<td>Vet examines Go source code and reports suspicious constructs, such as Printf
calls whose arguments do not align with the format string.</td>

View File

@@ -18,7 +18,7 @@ It explains the simplest way to get up and running with your Go installation.
<p>
A similar explanation is available as a
<a href="//www.youtube.com/watch?v=XCsL89YtqCs">screencast</a>.
<a href="http://www.youtube.com/watch?v=XCsL89YtqCs">screencast</a>.
</p>
@@ -60,35 +60,37 @@ To give you an idea of how a workspace looks in practice, here's an example:
<pre>
bin/
hello # command executable
outyet # command executable
streak # command executable
todo # command executable
pkg/
linux_amd64/
github.com/golang/example/
stringutil.a # package object
code.google.com/p/goauth2/
oauth.a # package object
github.com/nf/todo/
task.a # package object
src/
<a href="https://github.com/golang/example/">github.com/golang/example/</a>
.git/ # Git repository metadata
hello/
hello.go # command source
outyet/
main.go # command source
main_test.go # test source
stringutil/
reverse.go # package source
reverse_test.go # test source
code.google.com/p/goauth2/
.hg/ # mercurial repository metadata
oauth/
oauth.go # package source
oauth_test.go # test source
github.com/nf/
streak/
.git/ # git repository metadata
oauth.go # command source
streak.go # command source
todo/
.git/ # git repository metadata
task/
task.go # package source
todo.go # command source
</pre>
<p>
This workspace contains one repository (<code>example</code>)
comprising two commands (<code>hello</code> and <code>outyet</code>)
and one library (<code>stringutil</code>).
</p>
<p>
A typical workspace would contain many source repositories containing many
packages and commands. Most Go programmers keep <i>all</i> their Go source code
and dependencies in a single workspace.
This workspace contains three repositories (<code>goauth2</code>,
<code>streak</code>, and <code>todo</code>) comprising two commands
(<code>streak</code> and <code>todo</code>) and two libraries
(<code>oauth</code> and <code>task</code>).
</p>
<p>
@@ -108,14 +110,13 @@ when developing Go code.
<p>
To get started, create a workspace directory and set <code>GOPATH</code>
accordingly. Your workspace can be located wherever you like, but we'll use
<code>$HOME/work</code> in this document. Note that this must <b>not</b> be the
<code>$HOME/go</code> in this document. Note that this must <b>not</b> be the
same path as your Go installation.
(Another common setup is to set <code>GOPATH=$HOME</code>.)
</p>
<pre>
$ <b>mkdir $HOME/work</b>
$ <b>export GOPATH=$HOME/work</b>
$ <b>mkdir $HOME/go</b>
$ <b>export GOPATH=$HOME/go</b>
</pre>
<p>
@@ -127,11 +128,6 @@ to your <code>PATH</code>:
$ <b>export PATH=$PATH:$GOPATH/bin</b>
</pre>
<p>
To learn more about setting up the <code>GOPATH</code> environment variable,
please see
<a href="/cmd/go/#hdr-GOPATH_environment_variable"><code>go help gopath</code></a>
</p>
<h3 id="PackagePaths">Package paths</h3>
@@ -224,7 +220,7 @@ This command builds the <code>hello</code> command, producing an executable
binary. It then installs that binary to the workspace's <code>bin</code>
directory as <code>hello</code> (or, under Windows, <code>hello.exe</code>).
In our example, that will be <code>$GOPATH/bin/hello</code>, which is
<code>$HOME/work/bin/hello</code>.
<code>$HOME/go/bin/hello</code>.
</p>
<p>
@@ -260,7 +256,7 @@ optional: you do not need to use source control to write Go code.
<pre>
$ <b>cd $GOPATH/src/github.com/user/hello</b>
$ <b>git init</b>
Initialized empty Git repository in /home/user/work/src/github.com/user/hello/.git/
Initialized empty Git repository in /home/user/go/src/github.com/user/hello/.git/
$ <b>git add hello.go</b>
$ <b>git commit -m "initial commit"</b>
[master (root-commit) 0b4507d] initial commit
@@ -281,29 +277,29 @@ Let's write a library and use it from the <code>hello</code> program.
<p>
Again, the first step is to choose a package path (we'll use
<code>github.com/user/stringutil</code>) and create the package directory:
<code>github.com/user/newmath</code>) and create the package directory:
</p>
<pre>
$ <b>mkdir $GOPATH/src/github.com/user/stringutil</b>
$ <b>mkdir $GOPATH/src/github.com/user/newmath</b>
</pre>
<p>
Next, create a file named <code>reverse.go</code> in that directory with the
Next, create a file named <code>sqrt.go</code> in that directory with the
following contents.
</p>
<pre>
// Package stringutil contains utility functions for working with strings.
package stringutil
// Package newmath is a trivial example package.
package newmath
// Reverse returns its argument string reversed rune-wise left to right.
func Reverse(s string) string {
r := []rune(s)
for i, j := 0, len(r)-1; i &lt; len(r)/2; i, j = i+1, j-1 {
r[i], r[j] = r[j], r[i]
// Sqrt returns an approximation to the square root of x.
func Sqrt(x float64) float64 {
z := 1.0
for i := 0; i &lt; 1000; i++ {
z -= (z*z - x) / (2 * z)
}
return string(r)
return z
}
</pre>
@@ -312,7 +308,7 @@ Now, test that the package compiles with <code>go build</code>:
</p>
<pre>
$ <b>go build github.com/user/stringutil</b>
$ <b>go build github.com/user/newmath</b>
</pre>
<p>
@@ -330,7 +326,7 @@ directory of the workspace.
</p>
<p>
After confirming that the <code>stringutil</code> package builds,
After confirming that the <code>newmath</code> package builds,
modify your original <code>hello.go</code> (which is in
<code>$GOPATH/src/github.com/user/hello</code>) to use it:
</p>
@@ -341,18 +337,18 @@ package main
import (
"fmt"
<b>"github.com/user/stringutil"</b>
<b>"github.com/user/newmath"</b>
)
func main() {
fmt.Printf(stringutil.Reverse("!oG ,olleH"))
fmt.Printf("Hello, world. <b>Sqrt(2) = %v\n", newmath.Sqrt(2)</b>)
}
</pre>
<p>
Whenever the <code>go</code> tool installs a package or binary, it also
installs whatever dependencies it has.
So when you install the <code>hello</code> program
installs whatever dependencies it has. So when you install the <code>hello</code>
program
</p>
<pre>
@@ -360,16 +356,16 @@ $ <b>go install github.com/user/hello</b>
</pre>
<p>
the <code>stringutil</code> package will be installed as well, automatically.
the <code>newmath</code> package will be installed as well, automatically.
</p>
<p>
Running the new version of the program, you should see a new, reversed message:
Running the new version of the program, you should see some numerical output:
</p>
<pre>
$ <b>hello</b>
Hello, Go!
Hello, world. Sqrt(2) = 1.414213562373095
</pre>
<p>
@@ -378,22 +374,22 @@ After the steps above, your workspace should look like this:
<pre>
bin/
hello # command executable
hello # command executable
pkg/
linux_amd64/ # this will reflect your OS and architecture
linux_amd64/ # this will reflect your OS and architecture
github.com/user/
stringutil.a # package object
newmath.a # package object
src/
github.com/user/
hello/
hello.go # command source
stringutil/
reverse.go # package source
hello.go # command source
newmath/
sqrt.go # package source
</pre>
<p>
Note that <code>go install</code> placed the <code>stringutil.a</code> object
in a directory inside <code>pkg/linux_amd64</code> that mirrors its source
Note that <code>go install</code> placed the <code>newmath.a</code> object in a
directory inside <code>pkg/linux_amd64</code> that mirrors its source
directory.
This is so that future invocations of the <code>go</code> tool can find the
package object and avoid recompiling the package unnecessarily.
@@ -461,29 +457,20 @@ if the function calls a failure function such as <code>t.Error</code> or
</p>
<p>
Add a test to the <code>stringutil</code> package by creating the file
<code>$GOPATH/src/github.com/user/stringutil/reverse_test.go</code> containing
the following Go code.
Add a test to the <code>newmath</code> package by creating the file
<code>$GOPATH/src/github.com/user/newmath/sqrt_test.go</code> containing the
following Go code.
</p>
<pre>
package stringutil
package newmath
import "testing"
func TestReverse(t *testing.T) {
cases := []struct {
in, want string
}{
{"Hello, world", "dlrow ,olleH"},
{"Hello, 世界", "界世 ,olleH"},
{"", ""},
}
for _, c := range cases {
got := Reverse(c.in)
if got != c.want {
t.Errorf("Reverse(%q) == %q, want %q", c.in, got, c.want)
}
func TestSqrt(t *testing.T) {
const in, out = 4, 2
if x := Sqrt(in); x != out {
t.Errorf("Sqrt(%v) = %v, want %v", in, x, out)
}
}
</pre>
@@ -493,8 +480,8 @@ Then run the test with <code>go test</code>:
</p>
<pre>
$ <b>go test github.com/user/stringutil</b>
ok github.com/user/stringutil 0.165s
$ <b>go test github.com/user/newmath</b>
ok github.com/user/newmath 0.165s
</pre>
<p>
@@ -504,7 +491,7 @@ directory, you can omit the package path:
<pre>
$ <b>go test</b>
ok github.com/user/stringutil 0.165s
ok github.com/user/newmath 0.165s
</pre>
<p>
@@ -520,16 +507,16 @@ An import path can describe how to obtain the package source code using a
revision control system such as Git or Mercurial. The <code>go</code> tool uses
this property to automatically fetch packages from remote repositories.
For instance, the examples described in this document are also kept in a
Git repository hosted at GitHub
<code><a href="https://github.com/golang/example">github.com/golang/example</a></code>.
Mercurial repository hosted at Google Code,
<code><a href="http://code.google.com/p/go.example">code.google.com/p/go.example</a></code>.
If you include the repository URL in the package's import path,
<code>go get</code> will fetch, build, and install it automatically:
</p>
<pre>
$ <b>go get github.com/golang/example/hello</b>
$ <b>go get code.google.com/p/go.example/hello</b>
$ <b>$GOPATH/bin/hello</b>
Hello, Go examples!
Hello, world. Sqrt(2) = 1.414213562373095
</pre>
<p>
@@ -546,46 +533,44 @@ tree should now look like this:
<pre>
bin/
hello # command executable
hello # command executable
pkg/
linux_amd64/
github.com/golang/example/
stringutil.a # package object
code.google.com/p/go.example/
newmath.a # package object
github.com/user/
stringutil.a # package object
newmath.a # package object
src/
github.com/golang/example/
.git/ # Git repository metadata
code.google.com/p/go.example/
hello/
hello.go # command source
stringutil/
reverse.go # package source
reverse_test.go # test source
hello.go # command source
newmath/
sqrt.go # package source
sqrt_test.go # test source
github.com/user/
hello/
hello.go # command source
stringutil/
reverse.go # package source
reverse_test.go # test source
hello.go # command source
newmath/
sqrt.go # package source
sqrt_test.go # test source
</pre>
<p>
The <code>hello</code> command hosted at GitHub depends on the
<code>stringutil</code> package within the same repository. The imports in
<code>hello.go</code> file use the same import path convention, so the
<code>go get</code> command is able to locate and install the dependent
package, too.
The <code>hello</code> command hosted at Google Code depends on the
<code>newmath</code> package within the same repository. The imports in
<code>hello.go</code> file use the same import path convention, so the <code>go
get</code> command is able to locate and install the dependent package, too.
</p>
<pre>
import "github.com/golang/example/stringutil"
import "code.google.com/p/go.example/newmath"
</pre>
<p>
This convention is the easiest way to make your Go packages available for
others to use.
The <a href="//golang.org/wiki/Projects">Go Wiki</a>
and <a href="//godoc.org/">godoc.org</a>
The <a href="http://code.google.com/p/go-wiki/wiki/Projects">Go Wiki</a>
and <a href="http://godoc.org/">godoc.org</a>
provide lists of external Go projects.
</p>
@@ -599,7 +584,7 @@ For more information on using remote repositories with the <code>go</code> tool,
<p>
Subscribe to the
<a href="//groups.google.com/group/golang-announce">golang-announce</a>
<a href="http://groups.google.com/group/golang-announce">golang-announce</a>
mailing list to be notified when a new stable version of Go is released.
</p>
@@ -609,7 +594,7 @@ clear, idiomatic Go code.
</p>
<p>
Take <a href="//tour.golang.org/">A Tour of Go</a> to learn the language
Take <a href="http://tour.golang.org/">A Tour of Go</a> to learn the language
proper.
</p>
@@ -628,10 +613,10 @@ For real-time help, ask the helpful gophers in <code>#go-nuts</code> on the
<p>
The official mailing list for discussion of the Go language is
<a href="//groups.google.com/group/golang-nuts">Go Nuts</a>.
<a href="http://groups.google.com/group/golang-nuts">Go Nuts</a>.
</p>
<p>
Report bugs using the
<a href="//golang.org/issue">Go issue tracker</a>.
<a href="http://code.google.com/p/go/issues/list">Go issue tracker</a>.
</p>

View File

@@ -9,7 +9,7 @@
<p>
Go is an open source project developed by a team at
<a href="//google.com/">Google</a> and many
<a href="http://google.com/">Google</a> and many
<a href="/CONTRIBUTORS">contributors</a> from the open source community.
</p>
@@ -17,29 +17,34 @@ Go is an open source project developed by a team at
Go is distributed under a <a href="/LICENSE">BSD-style license</a>.
</p>
<h3 id="announce"><a href="//groups.google.com/group/golang-announce">Announcements Mailing List</a></h3>
<h3 id="announce"><a href="http://groups.google.com/group/golang-announce">Announcements Mailing List</a></h3>
<p>
A low traffic mailing list for important announcements, such as new releases.
</p>
<p>
We encourage all Go users to subscribe to
<a href="//groups.google.com/group/golang-announce">golang-announce</a>.
<a href="http://groups.google.com/group/golang-announce">golang-announce</a>.
</p>
<h2 id="go1">Version history</h2>
<h3 id="release"><a href="/doc/devel/release.html">Release History</a></h3>
<p>A summary of the changes between Go releases.</p>
<p>A <a href="/doc/devel/release.html">summary</a> of the changes between Go releases. Notes for the major releases:</p>
<h4 id="go1notes"><a href="/doc/go1">Go 1 Release Notes</a></h4>
<p>
A guide for updating your code to work with Go 1.
</p>
<ul>
<li><a href="/doc/go1.4">Go 1.4</a> <small>(December 2014)</small></li>
<li><a href="/doc/go1.3">Go 1.3</a> <small>(June 2014)</small></li>
<li><a href="/doc/go1.2">Go 1.2</a> <small>(December 2013)</small></li>
<li><a href="/doc/go1.1">Go 1.1</a> <small>(May 2013)</small></li>
<li><a href="/doc/go1">Go 1</a> <small>(March 2012)</small></li>
</ul>
<h4 id="release notes"><a href="/doc/go1.1">Go 1.1 Release Notes</a></h4>
<p>
A list of significant changes in Go 1.1, with instructions for updating
your code where necessary.
Each point release includes a similar document appropriate for that
release: <a href="/doc/go1.2">Go 1.2</a>, <a href="/doc/go1.3">Go 1.3</a>,
and so on.
</p>
<h3 id="go1compat"><a href="/doc/go1compat">Go 1 and the Future of Go Programs</a></h3>
<p>
@@ -50,7 +55,7 @@ Go 1 matures.
<h2 id="resources">Developer Resources</h2>
<h3 id="source"><a href="https://golang.org/change">Source Code</a></h3>
<h3 id="source"><a href="https://code.google.com/p/go/source">Source Code</a></h3>
<p>Check out the Go source code.</p>
<h3 id="golang-dev"><a href="https://groups.google.com/group/golang-dev">Developer</a> and
@@ -67,22 +72,22 @@ href="https://groups.google.com/group/golang-nuts">golang-nuts</a>.</p>
<p>A mailing list that receives a message summarizing each checkin to the Go repository.</p>
<h3 id="golang-bugs"><a href="https://groups.google.com/group/golang-bugs">Bugs Mailing List</a></h3>
<p>A mailing list that receives each update to the Go <a href="//golang.org/issue">issue tracker</a>.</p>
<p>A mailing list that receives each update to the Go <a href="http://golang.org/issue">issue tracker</a>.</p>
<h3 id="build_status"><a href="//build.golang.org/">Build Status</a></h3>
<h3 id="build_status"><a href="http://build.golang.org/">Build Status</a></h3>
<p>View the status of Go builds across the supported operating
systems and architectures.</p>
<h2 id="howto">How you can help</h2>
<h3><a href="//golang.org/issue">Reporting issues</a></h3>
<h3><a href="https://code.google.com/p/go/issues">Reporting issues</a></h3>
<p>
If you spot bugs, mistakes, or inconsistencies in the Go project's code or
documentation, please let us know by
<a href="//golang.org/issue/new">filing a ticket</a>
on our <a href="//golang.org/issue">issue tracker</a>.
<a href="https://code.google.com/p/go/issues/entry">filing a ticket</a>
on our <a href="https://code.google.com/p/go/issues">issue tracker</a>.
(Of course, you should check it's not an existing issue before creating
a new one.)
</p>
@@ -101,8 +106,8 @@ To get started, read these <a href="/doc/contribute.html">contribution
guidelines</a> for information on design, testing, and our code review process.
</p>
<p>
Check <a href="//golang.org/issue">the tracker</a> for
Check <a href="https://code.google.com/p/go/issues">the tracker</a> for
open issues that interest you. Those labeled
<a href="https://github.com/golang/go/issues?q=is%3Aopen+is%3Aissue+label%3Ahelpwanted">helpwanted</a>
<a href="https://code.google.com/p/go/issues/list?q=status=HelpWanted">HelpWanted</a>
are particularly in need of outside help.
</p>

View File

@@ -6,12 +6,9 @@
<p>
This document explains how to contribute changes to the Go project.
It assumes you have followed the
It assumes you have installed Go using the
<a href="/doc/install/source">installation instructions</a> and
have <a href="code.html">written and tested your code</a>.
</p>
<p>
(Note that the <code>gccgo</code> frontend lives elsewhere;
see <a href="gccgo_contribute.html">Contributing to gccgo</a>.)
</p>
@@ -57,8 +54,7 @@ $ ./all.bash
</p>
<p>
After running for a while, the command should print
"<code>ALL</code> <code>TESTS</code> <code>PASSED</code>".
After running for a while, the command should print "<code>ALL TESTS PASSED</code>".
</p>
<h2 id="Code_review">Code review</h2>
@@ -68,230 +64,208 @@ Changes to Go must be reviewed before they are submitted,
no matter who makes the change.
(In exceptional cases, such as fixing a build, the review can
follow shortly after submitting.)
A custom git command called <code>git-codereview</code>,
discussed below, helps manage the code review process through a Google-hosted
<a href="https://go-review.googlesource.com/">instance</a> of the code review
system called <a href="https://code.google.com/p/gerrit/">Gerrit</a>.
A Mercurial extension helps manage the code review process.
The extension is included in the Go source tree but needs
to be added to your Mercurial configuration.
</p>
<h3>Set up authentication for code review</h3>
<h3>Caveat for Mercurial aficionados</h3>
<p>
The Git code hosting server and Gerrit code review server both use a Google
Account to authenticate. You therefore need a Google Account to proceed.
<i>Using Mercurial with the code review extension is not the same
as using standard Mercurial.</i>
</p>
<p>
The Go repository is maintained as a single line of reviewed changes;
we prefer to avoid the complexity of Mercurial's arbitrary change graph.
The code review extension helps here: its <code>hg submit</code> command
automatically checks for and warns about the local repository
being out of date compared to the remote one.
The <code>hg submit</code> command also verifies other
properties about the Go repository.
For example,
it checks that Go code being checked in is formatted in the standard style,
as defined by <a href="/cmd/gofmt">gofmt</a>,
and it checks that the author of the code is properly recorded for
<a href="#copyright">copyright purposes</a>.
</p>
<p>
To help ensure changes are only created by <code>hg submit</code>,
the code review extension disables the standard <code>hg commit</code>
command.
</p>
<h3>Configure the extension</h3>
<p>Edit <code>.hg/hgrc</code> in the root of your Go checkout to add:</p>
<pre>
[extensions]
codereview = /path/to/go/lib/codereview/codereview.py
[ui]
username = Your Name &lt;you@server.dom&gt;
</pre>
<p>
The <code>username</code> information will not be used unless
you are a committer (see below), but Mercurial complains if it is missing.
</p>
<p>
As the codereview extension is only enabled for your Go checkout, the remainder of this document assumes you
are inside the go directory when issuing commands.
</p>
<p>To contribute to subrepositories, edit the <code>.hg/hgrc</code> for each
subrepository in the same way. For example, add the codereview extension to
<code>code.google.com/p/go.tools/.hg/hgrc</code>.
</p>
<h3>Understanding the extension</h3>
<p>After adding the code review extension, you can run</p>
<pre>
$ hg help codereview
</pre>
<p>to learn more about its commands. To learn about a specific code-review-specific
command such as <code>change</code>, run</p>
<pre>
$ hg help change
</pre>
<p>
Windows users may need to perform extra steps to get the code review
extension working. See the
<a href="https://code.google.com/p/go-wiki/wiki/CodeReview">CodeReview page</a>
on the <a href="https://code.google.com/p/go-wiki/wiki">Go Wiki</a> for details.
</p>
<h3>Log in to the code review site.</h3>
<p>
The code review server uses a Google Account to authenticate.
(If you can use the account to
<a href="https://www.google.com/accounts/Login">sign in at google.com</a>,
<a href="https://www.google.com/accounts/Login?hl=en&amp;continue=http://www.google.com/">sign in at google.com</a>,
you can use it to sign in to the code review server.)
The email address you use with the code review system
will be recorded in the <a href="https://go.googlesource.com/go">change log</a>
The email address you use on the Code Review site
will be recorded in the <a href="https://code.google.com/p/go/source/list">Mercurial change log</a>
and in the <a href="/CONTRIBUTORS"><code>CONTRIBUTORS</code></a> file.
You can <a href="https://www.google.com/accounts/NewAccount">create a Google Account</a>
associated with any address where you receive email.
</p>
<p>
Visit the site <a href="https://go.googlesource.com">go.googlesource.com</a>
and log in using your Google Account.
Click on the "Generate Password" link that appears at the top of the page.
</p>
<p>
Click the radio button that says "Only <code>go.googlesource.com</code>"
to use this authentication token only for the Go project.
</p>
<p>
Further down the page is a box containing commands to install
the authentication cookie in file called <code>.gitcookies</code> in your home
directory.
Copy the text for the commands into a Unix shell window to execute it.
That will install the authentication token.
</p>
<p>
(If you are on a Windows computer, you should instead follow the instructions
in the yellow box to run the command.)
</p>
<h3>Register with Gerrit</h3>
<p>
Now that you have a Google account and the authentication token,
you need to register your account with Gerrit, the code review system.
To do this, visit <a href="https://golang.org/cl">golang.org/cl</a>
and log in using the same Google Account you used above.
That is all that is required.
</p>
<h3>Install the git-codereview command</h3>
<p>
Now install the <code>git-codereview</code> command by running,
If you've enabled the two-step verification feature, don't forget to generate an
application-specific password and use that when prompted for a password.
</p>
<pre>
go get -u golang.org/x/review/git-codereview
$ hg code-login
Email (login for uploading to codereview.appspot.com): rsc@golang.org
Password for rsc@golang.org:
Saving authentication cookies to /Users/rsc/.codereview_upload_cookies_codereview.appspot.com
</pre>
<p>
Make sure <code>git-codereview</code> is installed in your shell path, so that the
<code>git</code> command can find it. Check that
<h3>Configure your account settings.</h3>
<p>Edit your <a href="https://codereview.appspot.com/settings">code review settings</a>.
Grab a nickname.
Many people prefer to set the Context option to
&ldquo;Whole file&rdquo; to see more context when reviewing changes.
</p>
<pre>
$ git codereview help
</pre>
<p>
prints help text, not an error.
<p>Once you have chosen a nickname in the settings page, others
can use that nickname as a shorthand for naming reviewers and the CC list.
For example, <code>rsc</code> is an alias for <code>rsc@golang.org</code>.
</p>
<p>
Note to Git aficionados: The <code>git-codereview</code> command is not required to
upload and manage Gerrit code reviews. For those who prefer plain Git, the text
below gives the Git equivalent of each git-codereview command. If you do use plain
Git, note that you still need the commit hooks that the git-codereview command
configures; those hooks add a Gerrit <code>Change-Id</code> line to the commit
message and check that all Go source files have been formatted with gofmt. Even
if you intend to use plain Git for daily work, install the hooks in a new Git
checkout by running <code>git-codereview</code> <code>hooks</code>.
</p>
<h3>Set up git aliases</h3>
<p>
The <code>git-codereview</code> command can be run directly from the shell
by typing, for instance,
</p>
<pre>
$ git codereview sync
</pre>
<p>
but it is more convenient to set up aliases for <code>git-codereview</code>'s own
subcommands, so that the above becomes,
</p>
<pre>
$ git sync
</pre>
<p>
The <code>git-codereview</code> subcommands have been chosen to be distinct from
Git's own, so it's safe to do so.
</p>
<p>
The aliases are optional, but in the rest of this document we will assume
they are installed.
To install them, copy this text into your Git configuration file
(usually <code>.gitconfig</code> in your home directory):
</p>
<pre>
[alias]
change = codereview change
gofmt = codereview gofmt
mail = codereview mail
pending = codereview pending
submit = codereview submit
sync = codereview sync
</pre>
<h3>Understanding the git-codereview command</h3>
<p>After installing the <code>git-codereview</code> command, you can run</p>
<pre>
$ git codereview help
</pre>
<p>
to learn more about its commands.
You can also read the <a href="https://godoc.org/golang.org/x/review/git-codereview">command documentation</a>.
</p>
<h3>Switch to the master branch</h3>
<h3>Switch to the default branch</h3>
<p>
Most Go installations use a release branch, but new changes should
only be made based on the master branch.
(They may be applied later to a release branch as part of the release process,
but most contributors won't do this themselves.)
Before making a change, make sure you start on the master branch:
only be made to the default branch. (They may be applied later to a release
branch as part of the release process.)
Before making a change, make sure you use the default branch:
</p>
<pre>
$ git checkout master
$ git sync
$ hg update default
</pre>
<p>
(In Git terms, <code>git</code> <code>sync</code> runs
<code>git</code> <code>pull</code> <code>-r</code>.)
</p>
<h3>Make a change</h3>
<p>
The entire checked-out tree is writable.
Once you have edited files, you must tell Git that they have been modified.
You must also tell Git about any files that are added, removed, or renamed files.
These operations are done with the usual Git commands,
<code>git</code> <code>add</code>,
<code>git</code> <code>rm</code>,
and
<code>git</code> <code>mv</code>.
If you need to edit files, just edit them: Mercurial will figure out which ones changed.
You do need to inform Mercurial of added, removed, copied, or renamed files,
by running
<code>hg add</code>,
<code>hg rm</code>,
<code>hg cp</code>,
or
<code>hg mv</code>.
</p>
<p>
If you wish to checkpoint your work, or are ready to send the code out for review, run</p>
<p>When you are ready to send a change out for review, run</p>
<pre>
$ git change <i>&lt;branch&gt;</i>
$ hg change
</pre>
<p>
from any directory in your Go repository to commit the changes so far.
The name <i>&lt;branch&gt;</i> is an arbitrary one you choose to identify the
local branch containing your changes.
</p>
<p>
(In Git terms, <code>git</code> <code>change</code> <code>&lt;branch&gt;</code>
runs <code>git</code> <code>checkout</code> <code>-b</code> <code>branch</code>,
then <code>git</code> <code>branch</code> <code>--set-upstream-to</code> <code>origin/master</code>,
then <code>git</code> <code>commit</code>.)
</p>
<p>
Git will open a change description file in your editor.
(It uses the editor named by the <code>$EDITOR</code> environment variable,
<code>vi</code> by default.)
<p>from any directory in your Go repository.
Mercurial will open a change description file in your editor.
(It uses the editor named by the <code>$EDITOR</code> environment variable, <code>vi</code> by default.)
The file will look like:
</p>
<pre>
# Change list.
# Lines beginning with # are ignored.
# Multi-line values should be indented.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch foo
# Changes not staged for commit:
# modified: editedfile.go
#
Reviewer:
CC:
Description:
&lt;enter description here&gt;
Files:
src/pkg/math/sin.go
src/pkg/math/tan.go
src/pkg/regexp/regexp.go
</pre>
<p>
At the beginning of this file is a blank line; replace it
with a thorough description of your change.
The <code>Reviewer</code> line lists the reviewers assigned
to this change, and the <code>CC</code> line lists people to
notify about the change.
These can be code review nicknames or arbitrary email addresses.
Unless explicitly told otherwise, such as in the discussion leading
up to sending in the change list, leave the reviewer field blank.
This means that the
<a href="https://groups.google.com/group/golang-codereviews">golang-codereviews@googlegroups.com</a>
mailing list will be used as the reviewer.
</p>
<p>
Replace &ldquo;<code>&lt;enter description here&gt;</code>&rdquo;
with a description of your change.
The first line of the change description is conventionally a one-line
summary of the change, prefixed by the primary affected package,
and is used as the subject for code review mail.
The rest of the
description elaborates and should provide context for the
change and explain what it does.
If there is a helpful reference, mention it here.
and is used as the subject for code review mail; the rest of the
description elaborates.
</p>
<p>
The <code>Files</code> section lists all the modified files
in your client.
It is best to keep unrelated changes in different change lists.
In this example, we can include just the changes to package <code>math</code>
by deleting the line mentioning <code>regexp.go</code>.
</p>
<p>
@@ -299,314 +273,343 @@ After editing, the template might now read:
</p>
<pre>
math: improved Sin, Cos and Tan precision for very large arguments
# Change list.
# Lines beginning with # are ignored.
# Multi-line values should be indented.
The existing implementation has poor numerical properties for
large arguments, so use the McGillicutty algorithm to improve
accuracy above 1e10.
Reviewer: golang-codereviews@googlegroups.com
CC: math-nuts@swtch.com
The algorithm is described at http://wikipedia.org/wiki/McGillicutty_Algorithm
Description:
math: improved Sin, Cos and Tan precision for very large arguments.
Fixes #159
See Bimmler and Shaney, ``Extreme sinusoids,'' J. Math 3(14).
Fixes issue 159.
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch foo
# Changes not staged for commit:
# modified: editedfile.go
#
Files:
src/pkg/math/sin.go
src/pkg/math/tan.go
</pre>
<p>
The commented section of the file lists all the modified files in your client.
It is best to keep unrelated changes in different change lists,
so if you see a file listed that should not be included, abort
the command and move that file to a different branch.
</p>
<p>
The special notation "Fixes #159" associates the change with issue 159 in the
<a href="https://golang.org/issue/159">Go issue tracker</a>.
The special sentence &ldquo;Fixes issue 159.&rdquo; associates
the change with issue 159 in the <a href="https://code.google.com/p/go/issues/list">Go issue tracker</a>.
When this change is eventually submitted, the issue
tracker will automatically mark the issue as fixed.
(There are several such conventions, described in detail in the
<a href="https://help.github.com/articles/closing-issues-via-commit-messages/">GitHub Issue Tracker documentation</a>.)
(These conventions are described in detail by the
<a href="https://code.google.com/p/support/wiki/IssueTracker#Integration_with_version_control">Google Project Hosting Issue Tracker documentation</a>.)
</p>
<p>
Once you have finished writing the commit message,
save the file and exit the editor.
</p>
Save the file and exit the editor.</p>
<p>
If you wish to do more editing, re-stage your changes using
<code>git</code> <code>add</code>, and then run
The code review server assigns your change an issue number and URL,
which <code>hg change</code> will print, something like:
</p>
<pre>
$ git change
CL created: https://codereview.appspot.com/99999
</pre>
<h3>Adding or removing files from an existing change</h3>
<p>
to update the change description and incorporate the staged changes. The
change description contains a <code>Change-Id</code> line near the bottom,
added by a Git commit hook during the initial
<code>git</code> <code>change</code>.
That line is used by Gerrit to match successive uploads of the same change.
Do not edit or delete it.
If you need to re-edit the change description, or change the files included in the CL,
run <code>hg change 99999</code>.
</p>
<p>
(In Git terms, <code>git</code> <code>change</code> with no branch name
runs <code>git</code> <code>commit</code> <code>--amend</code>.)
Alternatively, you can use
</p>
<pre>
$ hg file 99999 somefile
</pre>
<p>
to add <code>somefile</code> to CL 99999, and
</p>
<pre>
$ hg file -d 99999 somefile
</pre>
<p>
to remove <code>somefile</code> from the CL.
</p>
<p>
A file may only belong to a single active CL at a time. <code>hg file</code>
will issue a warning if a file is moved between changes.
</p>
<h3>Synchronize your client</h3>
<p>While you were working, others might have submitted changes
to the repository. To update your client, run</p>
<pre>
$ hg sync
</pre>
<p>(For Mercurial fans, <code>hg sync</code> runs <code>hg pull -u</code>
but then also synchronizes the local change list state against the new data.)</p>
<p>
If files you were editing have changed, Mercurial does its best to merge the
remote changes into your local changes. It may leave some files to merge by hand.
</p>
<p>
For example, suppose you have edited <code>flag_test.go</code> but
someone else has committed an independent change.
When you run <code>hg sync</code>, you will get the (scary-looking) output
(emphasis added):
<pre>
$ hg sync
adding changesets
adding manifests
adding file changes
added 1 changeset with 2 changes to 2 files
getting src/pkg/flag/flag.go
couldn't find merge tool hgmerge
merging src/pkg/flag/flag_test.go
warning: conflicts during merge.
<i>merging src/pkg/flag/flag_test.go failed!</i>
1 file updated, 0 files merged, 0 files removed, 1 file unresolved
use 'hg resolve' to retry unresolved file merges
$
</pre>
<p>
The only important part in that transcript is the italicized line:
Mercurial failed to merge your changes with the independent change.
When this happens, Mercurial leaves both edits in the file,
marked by <code>&lt;&lt;&lt;&lt;&lt;&lt;&lt;</code> and
<code>&gt;&gt;&gt;&gt;&gt;&gt;&gt;</code>.
it is now your job to edit the file to combine them.
Continuing the example, searching for those strings in <code>flag_test.go</code>
might turn up:
</p>
<pre>
VisitAll(visitor);
&lt;&lt;&lt;&lt;&lt;&lt;&lt; local
if len(m) != 7 {
=======
if len(m) != 8 {
&gt;&gt;&gt;&gt;&gt;&gt;&gt; other
t.Error("VisitAll misses some flags");
</pre>
<p>
Mercurial doesn't show it, but suppose the original text that both edits
started with was 6; you added 1 and the other change added 2,
so the correct answer might now be 9. First, edit the section
to remove the markers and leave the correct code:
</p>
<pre>
VisitAll(visitor);
if len(m) != 9 {
t.Error("VisitAll misses some flags");
</pre>
<p>
Then ask Mercurial to mark the conflict as resolved:
</p>
<pre>
$ hg resolve -m flag_test.go
</pre>
<p>
If you had been editing the file, say for debugging, but do not
care to preserve your changes, you can run
<code>hg revert flag_test.go</code> to abandon your
changes, but you may still need to run
<code>hg resolve -m</code> to mark the conflict resolved.
</p>
<h3>Mail the change for review</h3>
<p>
Once the change is ready, mail it out for review:
Creating or uploading the change uploads a copy of the diff to the code review server,
but it does not notify anyone about it. To do that, you need to run <code>hg mail</code>
(see below).
</p>
<p>To send out a change for review, run <code>hg mail</code> using the change list number
assigned during <code>hg change</code>:</p>
<pre>
$ hg mail 99999
</pre>
<p>You can add to the <code>Reviewer:</code> and <code>CC:</code> lines
using the <code>-r</code> or <code>--cc</code> options.
In the above example, we could have left the <code>Reviewer</code> and <code>CC</code>
lines blank and then run:
</p>
<pre>
$ git mail
$ hg mail -r golang-codereviews@googlegroups.com --cc math-nuts@swtch.com 99999
</pre>
<p>
You can specify a reviewer or CC interested parties
using the <code>-r</code> or <code>-cc</code> options.
Both accept a comma-separated list of email addresses:
</p>
<p>to achieve the same effect.</p>
<pre>
$ git mail -r joe@golang.org -cc mabel@example.com,math-nuts@swtch.com
</pre>
<p>
Unless explicitly told otherwise, such as in the discussion leading
up to sending in the change list, it's better not to specify a reviewer.
All changes are automatically CC'ed to the
<a href="https://groups.google.com/group/golang-codereviews">golang-codereviews@googlegroups.com</a>
mailing list.
</p>
<p>
(In Git terms, <code>git</code> <code>mail</code> pushes the local committed
changes to Gerrit using <code>git</code> <code>push</code> <code>origin</code>
<code>HEAD:refs/for/master</code>.)
</p>
<p>Note that <code>-r</code> and <code>--cc</code> cannot be spelled <code>--r</code> or <code>-cc</code>.</p>
<p>
If your change relates to an open issue, please add a comment to the issue
announcing your proposed fix, including a link to your CL.
</p>
<p>
The code review server assigns your change an issue number and URL,
which <code>git</code> <code>mail</code> will print, something like:
</p>
<pre>
remote: New Changes:
remote: https://go-review.googlesource.com/99999 math: improved Sin, Cos and Tan precision for very large arguments
</pre>
<h3>Reviewing code</h3>
<p>
Running <code>git</code> <code>mail</code> will send an email to you and the
reviewers asking them to visit the issue's URL and make comments on the change.
When done, the reviewer adds comments through the Gerrit user interface
and clicks "Reply" to send comments back.
You will receive a mail notification when this happens.
You must reply through the web interface.
(Unlike with the old Rietveld review system, replying by mail has no effect.)
Running <code>hg mail</code> will send an email to you and the reviewers
asking them to visit the issue's URL and make comments on the change.
When done, the reviewer clicks &ldquo;Publish and Mail comments&rdquo;
to send comments back.
</p>
<h3>Revise and upload</h3>
<p>
You must respond to review comments through the web interface.
(Unlike with the old Rietveld review system, responding by mail has no effect.)
When you have revised the code and are ready for another round of review,
you can upload your change and send mail asking the reviewers to
please take another look (<code>PTAL</code>). Use the change list number
assigned during <code>hg change</code>
</p>
<pre>
$ hg mail 99999
</pre>
<p>
When you have revised the code and are ready for another round of review,
stage those changes and use <code>git</code> <code>change</code> to update the
commit.
To send the update change list for another round of review,
run <code>git</code> <code>mail</code> again.
Or to upload your change without sending a notification, run
</p>
<pre>
$ hg upload 99999
</pre>
<p>
You will probably revise your code in response to the reviewer comments.
You might also visit the code review web page and reply to the comments,
letting the reviewer know that you've addressed them or explain why you
haven't. When you're done replying, click &ldquo;Publish and Mail comments&rdquo;
to send the line-by-line replies and any other comments.
</p>
<p>
The reviewer can comment on the new copy, and the process repeats.
The reviewer approves the change by giving it a positive score
(+1 or +2) and replying <code>LGTM</code>: looks good to me.
The reviewer approves the change by replying with a mail that says
<code>LGTM</code>: looks good to me.
</p>
<p>
You can see a list of your pending changes by running <code>git</code>
<code>pending</code>, and switch between change branches with <code>git</code>
<code>change</code> <code><i>&lt;branch&gt;</i></code>.
</p>
<h3>Synchronize your client</h3>
<p>
While you were working, others might have submitted changes to the repository.
To update your local branch, run
</p>
<pre>
$ git sync
</pre>
<p>
(In git terms, <code>git</code> <code>sync</code> runs
<code>git</code> <code>pull</code> <code>-r</code>.)
</p>
<p>
If files you were editing have changed, Git does its best to merge the
remote changes into your local changes.
It may leave some files to merge by hand.
</p>
<p>
For example, suppose you have edited <code>sin.go</code> but
someone else has committed an independent change.
When you run <code>git</code> <code>sync</code>,
you will get the (scary-looking) output:
<pre>
$ git sync
Failed to merge in the changes.
Patch failed at 0023 math: improved Sin, Cos and Tan precision for very large arguments
The copy of the patch that failed is found in:
   /home/you/repo/.git/rebase-apply/patch
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".
</pre>
<p>
If this happens, run
</p>
<pre>
$ git status
</pre>
<p>
to see which files failed to merge.
The output will look something like this:
</p>
<pre>
rebase in progress; onto a24c3eb
You are currently rebasing branch 'mcgillicutty' on 'a24c3eb'.
  (fix conflicts and then run "git rebase --continue")
  (use "git rebase --skip" to skip this patch)
  (use "git rebase --abort" to check out the original branch)
Unmerged paths:
  (use "git reset HEAD &lt;file&gt;..." to unstage)
  (use "git add &lt;file&gt;..." to mark resolution)
<i>both modified:   sin.go</i>
</pre>
<p>
The only important part in that transcript is the italicized "both modified"
line: Git failed to merge your changes with the conflicting change.
When this happens, Git leaves both sets of edits in the file,
with conflicts marked by <code>&lt;&lt;&lt;&lt;&lt;&lt;&lt;</code> and
<code>&gt;&gt;&gt;&gt;&gt;&gt;&gt;</code>.
It is now your job to edit the file to combine them.
Continuing the example, searching for those strings in <code>sin.go</code>
might turn up:
</p>
<pre>
arg = scale(arg)
&lt;&lt;&lt;&lt;&lt;&lt;&lt; HEAD
if arg > 1e9 {
=======
if arg > 1e10 {
&gt;&gt;&gt;&gt;&gt;&gt;&gt; mcgillicutty
largeReduce(arg)
</pre>
<p>
Git doesn't show it, but suppose the original text that both edits
started with was 1e8; you changed it to 1e10 and the other change to 1e9,
so the correct answer might now be 1e10. First, edit the section
to remove the markers and leave the correct code:
</p>
<pre>
arg = scale(arg)
if arg > 1e10 {
largeReduce(arg)
</pre>
<p>
Then tell Git that the conflict is resolved by running
</p>
<pre>
$ git add sin.go
</pre>
<p>
If you had been editing the file, say for debugging, but do not
care to preserve your changes, you can run
<code>git</code> <code>reset</code> <code>HEAD</code> <code>sin.go</code>
to abandon your changes.
Then run <code>git</code> <code>rebase</code> <code>--continue</code> to
restore the change commit.
You can see a list of your pending changes by running <code>hg pending</code> (<code>hg p</code> for short).
</p>
<h3>Reviewing code by others</h3>
<p>
You can import a change proposed by someone else into your local Git repository.
On the Gerrit review page, click the "Download ▼" link in the upper right
corner, copy the "Checkout" command and run it from your local Git repo.
It should look something like this:
You can import a CL proposed by someone else into your local Mercurial client
by using the <code>hg clpatch</code> command. Running
</p>
<pre>
$ git fetch https://go.googlesource.com/review refs/changes/21/1221/1 && git checkout FETCH_HEAD
$ hg clpatch 99999
</pre>
<p>
To revert, change back to the branch you were working in.
will apply the latest diff for CL 99999 to your working copy. If any of the
files referenced in CL 99999 have local modifications, <code>clpatch</code>
will refuse to apply the whole diff. Once applied, CL 99999 will show up in
the output of <code>hg pending</code> and others.
</p>
<p>
To revert a CL you have applied locally, use the <code>hg revert</code>
command. Running
</p>
<pre>
$ hg revert @99999
</pre>
<p>
will revert any files mentioned on CL 99999 to their original state. This can
be an effective way of reverting one CL revision and applying another.
</p>
<p>
Once the CL has been submitted, the next time you run <code>hg sync</code>
it will be removed from your local pending list. Occasionally the pending list
can get out of sync leaving stale references to closed or abandoned CLs.
You can use <code>hg change -D 99999</code> to remove the reference to CL 99999.
</p>
<h3>Submit the change after the review</h3>
<p>
After the code has been <code>LGTM</code>'ed, an approver may
submit it to the master branch using the Gerrit UI.
There is a "Submit" button on the web page for the change
that appears once the change is approved (marked +2).
After the code has been <code>LGTM</code>'ed, it is time to submit
it to the Mercurial repository.
</p>
<p>
If you are not a committer, you cannot submit the change directly.
Instead a committer, usually the reviewer who said <code>LGTM</code>,
will run:
</p>
<pre>
$ hg clpatch 99999
$ hg submit 99999
</pre>
<p>
The <code>submit</code> command submits the code. You will be listed as the
author, but the change message will also indicate who the committer was.
Your local client will notice that the change has been submitted
when you next run <code>hg sync</code>.
</p>
<p>
If you are a committer, you can run:
</p>
<pre>
$ hg submit 99999
</pre>
<p>
This checks the change into the repository.
The change description will include a link to the code review,
and the code review will be updated with a link to the change
in the repository.
Since the method used to integrate the changes is "Cherry Pick",
the commit hashes in the repository will be changed by
the submit operation.
</p>
<p>
If your local copy of the repository is out of date,
<code>hg submit</code> will refuse the change:
</p>
<pre>
$ hg submit 99999
local repository out of date; must sync before submit
</pre>
<h3>More information</h3>
<p>
In addition to the information here, the Go community maintains a <a href="https://golang.org/wiki/CodeReview">CodeReview</a> wiki page.
In addition to the information here, the Go community maintains a <a href="https://code.google.com/p/go-wiki/wiki/CodeReview">CodeReview</a> wiki page.
Feel free to contribute to this page as you learn the review process.
</p>
@@ -614,8 +617,7 @@ Feel free to contribute to this page as you learn the review process.
<p>Files in the Go repository don't list author names,
both to avoid clutter and to avoid having to keep the lists up to date.
Instead, your name will appear in the
<a href="https://golang.org/change">change log</a>
Instead, your name will appear in the <a href="https://code.google.com/p/go/source/list">Mercurial change log</a>
and in the <a href="/CONTRIBUTORS"><code>CONTRIBUTORS</code></a> file
and perhaps the <a href="/AUTHORS"><code>AUTHORS</code></a> file.
</p>
@@ -652,7 +654,7 @@ This rigmarole needs to be done only for your first submission.
<p>Code that you contribute should use the standard copyright header:</p>
<pre>
// Copyright 2015 The Go Authors. All rights reserved.
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
</pre>

View File

@@ -120,7 +120,7 @@ For example:
<p>
If you'd like to see how this works, or want to extend it, take a look at <a
href="/src/runtime/runtime-gdb.py">src/runtime/runtime-gdb.py</a> in
href="/src/pkg/runtime/runtime-gdb.py">src/pkg/runtime/runtime-gdb.py</a> in
the Go source distribution. It depends on some special magic types
(<code>hash&lt;T,U&gt;</code>) and variables (<code>runtime.m</code> and
<code>runtime.g</code>) that the linker
@@ -153,7 +153,7 @@ the form <code>pkg.(*MyType).Meth</code>.
<p>
In this tutorial we will inspect the binary of the
<a href="/pkg/regexp/">regexp</a> package's unit tests. To build the binary,
change to <code>$GOROOT/src/regexp</code> and run <code>go test -c</code>.
change to <code>$GOROOT/src/pkg/regexp</code> and run <code>go test -c</code>.
This should produce an executable file named <code>regexp.test</code>.
</p>
@@ -172,7 +172,7 @@ License GPLv 3+: GNU GPL version 3 or later &lt;http://gnu.org/licenses/gpl.htm
Type "show copying" and "show warranty" for licensing/warranty details.
This GDB was configured as "x86_64-linux".
Reading symbols from /home/user/go/src/regexp/regexp.test...
Reading symbols from /home/user/go/src/pkg/regexp/regexp.test...
done.
Loading Go Runtime support.
(gdb)
@@ -180,7 +180,7 @@ Loading Go Runtime support.
<p>
The message <code>"Loading Go Runtime support"</code> means that GDB loaded the
extension from <code>$GOROOT/src/runtime/runtime-gdb.py</code>.
extension from <code>$GOROOT/src/pkg/runtime/runtime-gdb.py</code>.
</p>
<p>
@@ -199,7 +199,7 @@ it by hand by telling gdb (assuming you have the go sources in
</p>
<pre>
(gdb) <b>source ~/go/src/runtime/runtime-gdb.py</b>
(gdb) <b>source ~/go/src/pkg/runtime/runtime-gdb.py</b>
Loading Go Runtime support.
</pre>
@@ -259,7 +259,7 @@ Set a breakpoint at the <code>TestFind</code> function:
<pre>
(gdb) <b>b 'regexp.TestFind'</b>
Breakpoint 1 at 0x424908: file /home/user/go/src/regexp/find_test.go, line 148.
Breakpoint 1 at 0x424908: file /home/user/go/src/pkg/regexp/find_test.go, line 148.
</pre>
<p>
@@ -268,9 +268,9 @@ Run the program:
<pre>
(gdb) <b>run</b>
Starting program: /home/user/go/src/regexp/regexp.test
Starting program: /home/user/go/src/pkg/regexp/regexp.test
Breakpoint 1, regexp.TestFind (t=0xf8404a89c0) at /home/user/go/src/regexp/find_test.go:148
Breakpoint 1, regexp.TestFind (t=0xf8404a89c0) at /home/user/go/src/pkg/regexp/find_test.go:148
148 func TestFind(t *testing.T) {
</pre>
@@ -297,9 +297,9 @@ Look at the stack trace for where weve paused the program:
<pre>
(gdb) <b>bt</b> <i># backtrace</i>
#0 regexp.TestFind (t=0xf8404a89c0) at /home/user/go/src/regexp/find_test.go:148
#1 0x000000000042f60b in testing.tRunner (t=0xf8404a89c0, test=0x573720) at /home/user/go/src/testing/testing.go:156
#2 0x000000000040df64 in runtime.initdone () at /home/user/go/src/runtime/proc.c:242
#0 regexp.TestFind (t=0xf8404a89c0) at /home/user/go/src/pkg/regexp/find_test.go:148
#1 0x000000000042f60b in testing.tRunner (t=0xf8404a89c0, test=0x573720) at /home/user/go/src/pkg/testing/testing.go:156
#2 0x000000000040df64 in runtime.initdone () at /home/user/go/src/pkg/runtime/proc.c:242
#3 0x000000f8404a89c0 in ?? ()
#4 0x0000000000573720 in ?? ()
#5 0x0000000000000000 in ?? ()
@@ -311,18 +311,18 @@ The other goroutine, number 1, is stuck in <code>runtime.gosched</code>, blocked
<pre>
(gdb) <b>goroutine 1 bt</b>
#0 0x000000000040facb in runtime.gosched () at /home/user/go/src/runtime/proc.c:873
#0 0x000000000040facb in runtime.gosched () at /home/user/go/src/pkg/runtime/proc.c:873
#1 0x00000000004031c9 in runtime.chanrecv (c=void, ep=void, selected=void, received=void)
at /home/user/go/src/runtime/chan.c:342
#2 0x0000000000403299 in runtime.chanrecv1 (t=void, c=void) at/home/user/go/src/runtime/chan.c:423
at /home/user/go/src/pkg/runtime/chan.c:342
#2 0x0000000000403299 in runtime.chanrecv1 (t=void, c=void) at/home/user/go/src/pkg/runtime/chan.c:423
#3 0x000000000043075b in testing.RunTests (matchString={void (struct string, struct string, bool *, error *)}
0x7ffff7f9ef60, tests= []testing.InternalTest = {...}) at /home/user/go/src/testing/testing.go:201
0x7ffff7f9ef60, tests= []testing.InternalTest = {...}) at /home/user/go/src/pkg/testing/testing.go:201
#4 0x00000000004302b1 in testing.Main (matchString={void (struct string, struct string, bool *, error *)}
0x7ffff7f9ef80, tests= []testing.InternalTest = {...}, benchmarks= []testing.InternalBenchmark = {...})
at /home/user/go/src/testing/testing.go:168
#5 0x0000000000400dc1 in main.main () at /home/user/go/src/regexp/_testmain.go:98
#6 0x00000000004022e7 in runtime.mainstart () at /home/user/go/src/runtime/amd64/asm.s:78
#7 0x000000000040ea6f in runtime.initdone () at /home/user/go/src/runtime/proc.c:243
at /home/user/go/src/pkg/testing/testing.go:168
#5 0x0000000000400dc1 in main.main () at /home/user/go/src/pkg/regexp/_testmain.go:98
#6 0x00000000004022e7 in runtime.mainstart () at /home/user/go/src/pkg/runtime/amd64/asm.s:78
#7 0x000000000040ea6f in runtime.initdone () at /home/user/go/src/pkg/runtime/proc.c:243
#8 0x0000000000000000 in ?? ()
</pre>
@@ -333,7 +333,7 @@ The stack frame shows were currently executing the <code>regexp.TestFind</cod
<pre>
(gdb) <b>info frame</b>
Stack level 0, frame at 0x7ffff7f9ff88:
rip = 0x425530 in regexp.TestFind (/home/user/go/src/regexp/find_test.go:148);
rip = 0x425530 in regexp.TestFind (/home/user/go/src/pkg/regexp/find_test.go:148);
saved rip 0x430233
called by frame at 0x7ffff7f9ffa8
source language minimal.
@@ -410,7 +410,7 @@ We can step into the <code>String</code>function call with <code>"s"</code>:
<pre>
(gdb) <b>s</b>
regexp.(*Regexp).String (re=0xf84068d070, noname=void) at /home/user/go/src/regexp/regexp.go:97
regexp.(*Regexp).String (re=0xf84068d070, noname=void) at /home/user/go/src/pkg/regexp/regexp.go:97
97 func (re *Regexp) String() string {
</pre>
@@ -421,12 +421,12 @@ Get a stack trace to see where we are:
<pre>
(gdb) <b>bt</b>
#0 regexp.(*Regexp).String (re=0xf84068d070, noname=void)
at /home/user/go/src/regexp/regexp.go:97
at /home/user/go/src/pkg/regexp/regexp.go:97
#1 0x0000000000425615 in regexp.TestFind (t=0xf840688b60)
at /home/user/go/src/regexp/find_test.go:151
at /home/user/go/src/pkg/regexp/find_test.go:151
#2 0x0000000000430233 in testing.tRunner (t=0xf840688b60, test=0x5747b8)
at /home/user/go/src/testing/testing.go:156
#3 0x000000000040ea6f in runtime.initdone () at /home/user/go/src/runtime/proc.c:243
at /home/user/go/src/pkg/testing/testing.go:156
#3 0x000000000040ea6f in runtime.initdone () at /home/user/go/src/pkg/runtime/proc.c:243
....
</pre>

View File

@@ -3,34 +3,16 @@
}-->
<p>This page summarizes the changes between official stable releases of Go.
The <a href="//golang.org/change">change log</a> has the full details.</p>
The <a href="http://code.google.com/p/go/source/list">Mercurial change log</a>
has the full details.</p>
<p>To update to a specific release, use:</p>
<pre>
git pull
git checkout <i>release-branch</i>
hg pull
hg update <i>tag</i>
</pre>
<h2 id="go1.4">go1.4 (released 2014/12/10)</h2>
<p>
Go 1.4 is a major release of Go.
Read the <a href="/doc/go1.4">Go 1.4 Release Notes</a> for more information.
</p>
<h3 id="go1.4.minor">Minor revisions</h3>
<p>
go1.4.1 (released 2015/01/15) includes bug fixes to the linker and the <code>log</code>, <code>syscall</code>, and <code>runtime</code> packages.
See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.4.1">Go 1.4.1 milestone on our issue tracker</a> for details.
</p>
<p>
go1.4.2 (released 2015/02/17) includes bug fixes to the <code>go</code> command, the compiler and linker, and the <code>runtime</code>, <code>syscall</code>, <code>reflect</code>, and <code>math/big</code> packages.
See the <a href="https://github.com/golang/go/issues?q=milestone%3AGo1.4.2">Go 1.4.2 milestone on our issue tracker</a> for details.
</p>
<h2 id="go1.3">go1.3 (released 2014/06/18)</h2>
<p>
@@ -38,23 +20,6 @@ Go 1.3 is a major release of Go.
Read the <a href="/doc/go1.3">Go 1.3 Release Notes</a> for more information.
</p>
<h3 id="go1.3.minor">Minor revisions</h3>
<p>
go1.3.1 (released 2014/08/13) includes bug fixes to the compiler and the <code>runtime</code>, <code>net</code>, and <code>crypto/rsa</code> packages.
See the <a href="//code.google.com/p/go/source/list?name=release-branch.go1.3&r=073fc578434bf3e1e22749b559d273c8da728ebb">change history</a> for details.
</p>
<p>
go1.3.2 (released 2014/09/25) includes bug fixes to cgo and the crypto/tls packages.
See the <a href="//code.google.com/p/go/source/list?name=release-branch.go1.3&r=go1.3.2">change history</a> for details.
</p>
<p>
go1.3.3 (released 2014/09/30) includes further bug fixes to cgo, the runtime package, and the nacl port.
See the <a href="//code.google.com/p/go/source/list?name=release-branch.go1.3&r=go1.3.3">change history</a> for details.
</p>
<h2 id="go1.2">go1.2 (released 2013/12/01)</h2>
<p>
@@ -66,12 +31,12 @@ Read the <a href="/doc/go1.2">Go 1.2 Release Notes</a> for more information.
<p>
go1.2.1 (released 2014/03/02) includes bug fixes to the <code>runtime</code>, <code>net</code>, and <code>database/sql</code> packages.
See the <a href="//code.google.com/p/go/source/list?name=release-branch.go1.2&r=7ada9e760ce34e78aee5b476c9621556d0fa5d31">change history</a> for details.
See the <a href="https://code.google.com/p/go/source/list?name=release-branch.go1.2&r=7ada9e760ce34e78aee5b476c9621556d0fa5d31">change history</a> for details.
</p>
<p>
go1.2.2 (released 2014/05/05) includes a
<a href="//code.google.com/p/go/source/detail?r=bda3619e7a2c&repo=tools">security fix</a>
<a href="https://code.google.com/p/go/source/detail?r=bda3619e7a2c&repo=tools">security fix</a>
that affects the tour binary included in the binary distributions (thanks to Guillaume T).
</p>
@@ -86,18 +51,18 @@ Read the <a href="/doc/go1.1">Go 1.1 Release Notes</a> for more information.
<p>
go1.1.1 (released 2013/06/13) includes several compiler and runtime bug fixes.
See the <a href="//code.google.com/p/go/source/list?name=release-branch.go1.1&r=43c4a41d24382a56a90e924800c681e435d9e399">change history</a> for details.
See the <a href="https://code.google.com/p/go/source/list?name=release-branch.go1.1&r=43c4a41d24382a56a90e924800c681e435d9e399">change history</a> for details.
</p>
<p>
go1.1.2 (released 2013/08/13) includes fixes to the <code>gc</code> compiler
and <code>cgo</code>, and the <code>bufio</code>, <code>runtime</code>,
<code>syscall</code>, and <code>time</code> packages.
See the <a href="//code.google.com/p/go/source/list?name=release-branch.go1.1&r=a6a9792f94acd4ff686b2bc57383d163608b91cf">change history</a> for details.
See the <a href="https://code.google.com/p/go/source/list?name=release-branch.go1.1&r=a6a9792f94acd4ff686b2bc57383d163608b91cf">change history</a> for details.
If you use package syscall's <code>Getrlimit</code> and <code>Setrlimit</code>
functions under Linux on the ARM or 386 architectures, please note change
<a href="//golang.org/change/55ac276af5a7">55ac276af5a7</a>
that fixes <a href="//golang.org/issue/5949">issue 5949</a>.
<a href="http://golang.org/change/55ac276af5a7">55ac276af5a7</a>
that fixes <a href="http://golang.org/issue/5949">issue 5949</a>.
</p>
<h2 id="go1">go1 (released 2012/03/28)</h2>
@@ -123,17 +88,17 @@ The go1 release corresponds to
<p>
go1.0.1 (released 2012/04/25) was issued to
<a href="//golang.org/change/a890477d3dfb">fix</a> an
<a href="//golang.org/issue/3545">escape analysis bug</a>
that can lead to memory corruption.
<a href="https://code.google.com/p/go/source/detail?r=a890477d3dfb">fix</a> an
<a href="https://code.google.com/p/go/issues/detail?id=3545">escape analysis
bug</a> that can lead to memory corruption.
It also includes several minor code and documentation fixes.
</p>
<p>
go1.0.2 (released 2012/06/13) was issued to fix two bugs in the implementation
of maps using struct or array keys:
<a href="//golang.org/issue/3695">issue 3695</a> and
<a href="//golang.org/issue/3573">issue 3573</a>.
<a href="http://code.google.com/p/go/issues/detail?id=3695">issue 3695</a> and
<a href="http://code.google.com/p/go/issues/detail?id=3573">issue 3573</a>.
It also includes many minor code and documentation fixes.
</p>
@@ -142,7 +107,7 @@ go1.0.3 (released 2012/09/21) includes minor code and documentation fixes.
</p>
<p>
See the <a href="//code.google.com/p/go/source/list?name=release-branch.go1">go1 release branch history</a> for the complete list of changes.
See the <a href="http://code.google.com/p/go/source/list?name=release-branch.go1">go1 release branch history</a> for the complete list of changes.
</p>
<h2 id="r60">r60 (released 2011/09/07)</h2>
@@ -154,7 +119,7 @@ This section highlights the most significant changes in this release.
For a more detailed summary, see the
<a href="weekly.html#2011-08-17">weekly release notes</a>.
For complete information, see the
<a href="//code.google.com/p/go/source/list?r=release-branch.r60">Mercurial change list</a>.
<a href="http://code.google.com/p/go/source/list?r=release-branch.r60">Mercurial change list</a>.
</p>
<h3 id="r60.lang">Language</h3>
@@ -224,26 +189,26 @@ more accessible.
<p>
r60.1 includes a
<a href="//golang.org/change/1824581bf62d">linker
<a href="http://code.google.com/p/go/source/detail?r=1824581bf62d">linker
fix</a>, a pair of
<a href="//golang.org/change/9ef4429c2c64">goplay</a>
<a href="//golang.org/change/d42ed8c3098e">fixes</a>,
<a href="http://code.google.com/p/go/source/detail?r=9ef4429c2c64">goplay</a>
<a href="http://code.google.com/p/go/source/detail?r=d42ed8c3098e">fixes</a>,
and a <code>json</code> package
<a href="//golang.org/change/d5e97874fe84">fix</a> and
<a href="http://code.google.com/p/go/source/detail?r=d5e97874fe84">fix</a> and
a new
<a href="//golang.org/change/4f0e6269213f">struct tag
<a href="http://code.google.com/p/go/source/detail?r=4f0e6269213f">struct tag
option</a>.
</p>
<p>
r60.2
<a href="//golang.org/change/ff19536042ac">fixes</a>
<a href="http://code.google.com/p/go/source/detail?r=ff19536042ac">fixes</a>
a memory leak involving maps.
</p>
<p>
r60.3 fixes a
<a href="//golang.org/change/01fa62f5e4e5">reflect bug</a>.
<a href="http://code.google.com/p/go/source/detail?r=01fa62f5e4e5">reflect bug</a>.
</p>
<h2 id="r59">r59 (released 2011/08/01)</h2>
@@ -255,7 +220,7 @@ This section highlights the most significant changes in this release.
For a more detailed summary, see the
<a href="weekly.html#2011-07-07">weekly release notes</a>.
For complete information, see the
<a href="//code.google.com/p/go/source/list?r=release-branch.r59">Mercurial change list</a>.
<a href="http://code.google.com/p/go/source/list?r=release-branch.r59">Mercurial change list</a>.
</p>
<h3 id="r59.lang">Language</h3>
@@ -265,7 +230,7 @@ This release includes a language change that restricts the use of
<code>goto</code>. In essence, a <code>goto</code> statement outside a block
cannot jump to a label inside that block. Your code may require changes if it
uses <code>goto</code>.
See <a href="//golang.org/change/dc6d3cf9279d">this
See <a href="http://code.google.com/p/go/source/detail?r=dc6d3cf9279d">this
changeset</a> for how the new rule affected the Go tree.
</p>
@@ -363,13 +328,13 @@ This section highlights the most significant changes in this release.
For a more detailed summary, see the
<a href="weekly.html#2011-06-09">weekly release notes</a>.
For complete information, see the
<a href="//code.google.com/p/go/source/list?r=release-branch.r58">Mercurial change list</a>.
<a href="http://code.google.com/p/go/source/list?r=release-branch.r58">Mercurial change list</a>.
</p>
<h3 id="r58.lang">Language</h3>
<p>
This release fixes a <a href="//golang.org/change/b720749486e1">use of uninitialized memory in programs that misuse <code>goto</code></a>.
This release fixes a <a href="http://code.google.com/p/go/source/detail?r=b720749486e1">use of uninitialized memory in programs that misuse <code>goto</code></a>.
</p>
<h3 id="r58.pkg">Packages</h3>
@@ -428,8 +393,8 @@ the Go tree (and avoid writing Makefiles).
<h3 id="r58.minor">Minor revisions</h3>
<p>r58.1 adds
<a href="//golang.org/change/293c25943586">build</a> and
<a href="//golang.org/change/bf17e96b6582">runtime</a>
<a href="http://code.google.com/p/go/source/detail?r=293c25943586">build</a> and
<a href="http://code.google.com/p/go/source/detail?r=bf17e96b6582">runtime</a>
changes to make Go run on OS X 10.7 Lion.
</p>
@@ -443,7 +408,7 @@ This section highlights the most significant changes in this release.
For a more detailed summary, see the
<a href="weekly.html#2011-04-27">weekly release notes</a>.
For complete information, see the
<a href="//code.google.com/p/go/source/list?r=release-branch.r57">Mercurial change list</a>.
<a href="http://code.google.com/p/go/source/list?r=release-branch.r57">Mercurial change list</a>.
</p>
<p>The new <a href="/cmd/gofix">gofix</a> tool finds Go programs that use old APIs and rewrites them to use
@@ -454,7 +419,7 @@ future changes to the libraries.
Gofix cant
handle all situations perfectly, so read and test the changes it makes before
committing them.
See <a href="//blog.golang.org/2011/04/introducing-gofix.html">the gofix blog post</a> for more
See <a href="http://blog.golang.org/2011/04/introducing-gofix.html">the gofix blog post</a> for more
information.</p>
<h3 id="r57.lang">Language</h3>
@@ -500,7 +465,7 @@ For clients, there are new
<a href="/pkg/http/#Client">Client</a> and <a href="/pkg/http/#Transport">Transport</a>
abstractions that give more control over HTTP details such as headers sent
and redirections followed. These abstractions make it easy to implement
custom clients that add functionality such as <a href="//code.google.com/p/goauth2/source/browse/oauth/oauth.go">OAuth2</a>.
custom clients that add functionality such as <a href="http://code.google.com/p/goauth2/source/browse/oauth/oauth.go">OAuth2</a>.
For servers, <a href="/pkg/http/#ResponseWriter">ResponseWriter</a>
has dropped its non-essential methods.
The Hijack and Flush methods are no longer required;
@@ -544,7 +509,7 @@ implements all the possible value methods.
Instead of a type switch on a Value <code>v</code>, switch on <code>v.Kind()</code>.
Typeof and NewValue are now called <a href="/pkg/reflect/#Type.TypeOf">TypeOf</a> and <a href="/pkg/reflect/#Value.ValueOf">ValueOf</a>
To create a writable Value, use <code>New(t).Elem()</code> instead of <code>Zero(t)</code>.
See <a href="//golang.org/change/843855f3c026">the change description</a>
See <a href="http://code.google.com/p/go/source/detail?r=843855f3c026">the change description</a>
for the full details.
The new API allows a more efficient implementation of Value
that avoids many of the allocations required by the previous API.
@@ -580,8 +545,8 @@ For other uses, see the <a href="/pkg/runtime/pprof/">runtime/pprof</a> document
<h3 id="r57.minor">Minor revisions</h3>
<p>r57.1 fixes a <a href="//golang.org/change/ff2bc62726e7145eb2ecc1e0f076998e4a8f86f0">nil pointer dereference in http.FormFile</a>.</p>
<p>r57.2 fixes a <a href="//golang.org/change/063b0ff67d8277df03c956208abc068076818dae">use of uninitialized memory in programs that misuse <code>goto</code></a>.</p>
<p>r57.1 fixes a <a href="http://code.google.com/p/go/source/detail?r=ff2bc62726e7145eb2ecc1e0f076998e4a8f86f0">nil pointer dereference in http.FormFile</a>.</p>
<p>r57.2 fixes a <a href="http://code.google.com/p/go/source/detail?r=063b0ff67d8277df03c956208abc068076818dae">use of uninitialized memory in programs that misuse <code>goto</code></a>.</p>
<h2 id="r56">r56 (released 2011/03/16)</h2>

View File

@@ -5,7 +5,7 @@
<p>This page summarizes the changes between tagged weekly snapshots of Go.
Such snapshots are no longer created. This page remains as a historical reference only.</p>
<p>For recent information, see the <a href="//golang.org/change">change log</a> and <a href="//groups.google.com/group/golang-dev/">development mailing list</a>.</p>
<p>For recent information, see the <a href="http://code.google.com/p/go/source/list">Mercurial change log</a> and <a href="http://groups.google.com/group/golang-dev/">development mailing list</a>.</p>
<h2 id="2012-03-27">2012-03-27 (<a href="release.html#go1">Go 1</a>)</h2>

View File

@@ -33,20 +33,20 @@ libraries.
<img class="gopher" src="/doc/gopher/doc.png"/>
<h3 id="go_tour"><a href="//tour.golang.org/">A Tour of Go</a></h3>
<h3 id="go_tour"><a href="http://tour.golang.org/">A Tour of Go</a></h3>
<p>
An interactive introduction to Go in three sections.
The first section covers basic syntax and data structures; the second discusses
methods and interfaces; and the third introduces Go's concurrency primitives.
Each section concludes with a few exercises so you can practice what you've
learned. You can <a href="//tour.golang.org/">take the tour online</a> or
<a href="//code.google.com/p/go-tour/">install it locally</a>.
learned. You can <a href="http://tour.golang.org/">take the tour online</a> or
<a href="http://code.google.com/p/go-tour/">install it locally</a>.
</p>
<h3 id="code"><a href="code.html">How to write Go code</a></h3>
<p>
Also available as a
<a href="//www.youtube.com/watch?v=XCsL89YtqCs">screencast</a>, this doc
<a href="http://www.youtube.com/watch?v=XCsL89YtqCs">screencast</a>, this doc
explains how to use the <a href="/cmd/go/">go command</a> to fetch, build, and
install packages, commands, and run tests.
</p>
@@ -103,7 +103,7 @@ same variable in a different goroutine.
<h2 id="articles">Articles</h2>
<h3 id="blog"><a href="//blog.golang.org/">The Go Blog</a></h3>
<h3 id="blog"><a href="http://blog.golang.org/">The Go Blog</a></h3>
<p>The official blog of the Go project, featuring news and in-depth articles by
the Go team and guests.</p>
@@ -147,8 +147,8 @@ Guided tours of Go programs.
<li><a href="/blog/godoc-documenting-go-code">Godoc: documenting Go code</a> - writing good documentation for <a href="/cmd/godoc/">godoc</a>.</li>
<li><a href="/blog/profiling-go-programs">Profiling Go Programs</a></li>
<li><a href="/doc/articles/race_detector.html">Data Race Detector</a> - a manual for the data race detector.</li>
<li><a href="/blog/race-detector">Introducing the Go Race Detector</a> - an introduction to the race detector.</li>
<li><a href="/doc/asm">A Quick Guide to Go's Assembler</a> - an introduction to the assembler used by Go.</li>
<li><a href="/blog/race-detector">Introducing the Go Race Detector</a> - an introduction to the race detector.
<li><a href="/doc/asm">A Quick Guide to Go's Assembler</a> - an introduction to the assembler used by Go.
</ul>
<h4 id="articles_more">More</h4>
@@ -169,17 +169,17 @@ interfaces, reflection, and concurrency. Builds a toy web crawler to
demonstrate these.
</p>
<h3 id="go_code_that_grows"><a href="//vimeo.com/53221560">Code that grows with grace</a></h3>
<h3 id="go_code_that_grows"><a href="http://vimeo.com/53221560">Code that grows with grace</a></h3>
<p>
One of Go's key design goals is code adaptability; that it should be easy to take a simple design and build upon it in a clean and natural way. In this talk Andrew Gerrand describes a simple "chat roulette" server that matches pairs of incoming TCP connections, and then use Go's concurrency mechanisms, interfaces, and standard library to extend it with a web interface and other features. While the function of the program changes dramatically, Go's flexibility preserves the original design as it grows.
</p>
<h3 id="go_concurrency_patterns"><a href="//www.youtube.com/watch?v=f6kdp27TYZs">Go Concurrency Patterns</a></h3>
<h3 id="go_concurrency_patterns"><a href="http://www.youtube.com/watch?v=f6kdp27TYZs">Go Concurrency Patterns</a></h3>
<p>
Concurrency is the key to designing high performance network services. Go's concurrency primitives (goroutines and channels) provide a simple and efficient means of expressing concurrent execution. In this talk we see how tricky concurrency problems can be solved gracefully with simple Go code.
</p>
<h3 id="advanced_go_concurrency_patterns"><a href="//www.youtube.com/watch?v=QDDwwePbDtw">Advanced Go Concurrency Patterns</a></h3>
<h3 id="advanced_go_concurrency_patterns"><a href="http://www.youtube.com/watch?v=QDDwwePbDtw">Advanced Go Concurrency Patterns</a></h3>
<p>
This talk expands on the <i>Go Concurrency Patterns</i> talk to dive deeper into Go's concurrency primitives.
</p>

View File

@@ -28,7 +28,7 @@ will be easy for other Go programmers to understand.
<p>
This document gives tips for writing clear, idiomatic Go code.
It augments the <a href="/ref/spec">language specification</a>,
the <a href="//tour.golang.org/">Tour of Go</a>,
the <a href="http://tour.golang.org/">Tour of Go</a>,
and <a href="/doc/code.html">How to Write Go Code</a>,
all of which you
should read first.
@@ -37,14 +37,14 @@ should read first.
<h3 id="examples">Examples</h3>
<p>
The <a href="/src/">Go package sources</a>
The <a href="/src/pkg/">Go package sources</a>
are intended to serve not
only as the core library but also as examples of how to
use the language.
Moreover, many of the packages contain working, self-contained
executable examples you can run directly from the
<a href="//golang.org">golang.org</a> web site, such as
<a href="//golang.org/pkg/strings/#example_Map">this one</a> (if
<a href="http://golang.org">golang.org</a> web site, such as
<a href="http://golang.org/pkg/strings/#example_Map">this one</a> (if
necessary, click on the word "Example" to open it up).
If you have a question about how to approach a problem or how something
might be implemented, the documentation, code and examples in the
@@ -344,7 +344,7 @@ determines just which package is being used.
<p>
Another convention is that the package name is the base name of
its source directory;
the package in <code>src/encoding/base64</code>
the package in <code>src/pkg/encoding/base64</code>
is imported as <code>"encoding/base64"</code> but has name <code>base64</code>,
not <code>encoding_base64</code> and not <code>encodingBase64</code>.
</p>
@@ -3214,7 +3214,7 @@ Although the concurrency features of Go can make some problems easy
to structure as parallel computations, Go is a concurrent language,
not a parallel one, and not all parallelization problems fit Go's model.
For a discussion of the distinction, see the talk cited in
<a href="//blog.golang.org/2013/01/concurrency-is-not-parallelism.html">this
<a href="http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html">this
blog post</a>.
<h3 id="leaky_buffer">A leaky buffer</h3>

View File

@@ -30,7 +30,7 @@ contribution rules</a>.
<p>
The master sources for the gccgo frontend may be found at
<a href="//code.google.com/p/gofrontend">http://code.google.com/p/gofrontend</a>.
<a href="http://code.google.com/p/gofrontend">http://code.google.com/p/gofrontend</a>.
The master sources are not buildable by themselves, but only in
conjunction with GCC (in the future, other compilers may be
supported). Changes made to the gccgo frontend are also applied to
@@ -40,7 +40,7 @@ is mirrored to the <code>gcc/go/gofrontend</code> directory in the GCC
repository, and the <code>gofrontend</code> <code>libgo</code>
directory is mirrored to the GCC <code>libgo</code> directory. In
addition, the <code>test</code> directory
from <a href="//go.googlesource.com/go">the main Go repository</a>
from <a href="http://code.google.com/p/go">the main Go repository</a>
is mirrored to the <code>gcc/testsuite/go.test/test</code> directory
in the GCC repository.
</p>
@@ -65,7 +65,7 @@ from <code>gcc/go/gofrontend</code> to <code>gcc/go</code>.
<p>
The run-time library for gccgo is mostly the same as the library
in <a href="//go.googlesource.com/go">the main Go repository</a>.
in <a href="http://code.google.com/p/go">the main Go repository</a>.
The library code in the Go repository is periodically merged into
the <code>libgo/go</code> directory of the <code>gofrontend</code> and
then the GCC repositories, using the shell
@@ -73,7 +73,7 @@ script <code>libgo/merge.sh</code>. Accordingly, most library changes
should be made in the main Go repository. The files outside
of <code>libgo/go</code> are gccgo-specific; that said, some of the
files in <code>libgo/runtime</code> are based on files
in <code>src/runtime</code> in the main Go repository.
in <code>src/pkg/runtime</code> in the main Go repository.
</p>
<h2>Testing</h2>
@@ -105,7 +105,7 @@ or <code>gcc/testsuite/go.dg</code> directories in the GCC repository.
<p>
Changes to the Go frontend should follow the same process as for the
main Go repository, only for the <code>gofrontend</code> project and
the <code>gofrontend-dev@googlegroups.com</code> mailing list
the<code>gofrontend-dev@googlegroups.com</code> mailing list
rather than the <code>go</code> project and the
<code>golang-dev@googlegroups.com</code> mailing list. Those changes
will then be merged into the GCC sources.

View File

@@ -42,10 +42,6 @@ identical to Go 1.1. The GCC 4.8.2 release includes a complete Go
1.1.2 implementation.
</p>
<p>
The GCC 4.9 releases include a complete Go 1.2 implementation.
</p>
<h2 id="Source_code">Source code</h2>
<p>

View File

@@ -304,7 +304,7 @@ The race detector is documented in <a href="/doc/articles/race_detector.html">a
<p>
Due to the change of the <a href="#int"><code>int</code></a> to 64 bits and
a new internal <a href="//golang.org/s/go11func">representation of functions</a>,
a new internal <a href="http://golang.org/s/go11func">representation of functions</a>,
the arrangement of function arguments on the stack has changed in the gc tool chain.
Functions written in assembly will need to be revised at least
to adjust frame pointer offsets.

View File

@@ -63,7 +63,7 @@ The implementation may inject extra tests into the compiled program to enforce t
<p>
Further details are in the
<a href="//golang.org/s/go12nil">design document</a>.
<a href="http://golang.org/s/go12nil">design document</a>.
</p>
<p>
@@ -115,7 +115,7 @@ It is possible that future releases of Go may introduce default values for these
<p>
Further details are in the
<a href="//golang.org/s/go12slice">design document</a>.
<a href="http://golang.org/s/go12slice">design document</a>.
</p>
<p>
@@ -199,7 +199,7 @@ compiler to build any pieces of the linked-to library that are written in C++;
<p>
Both binaries are still included with the distribution, but the source code for the
godoc and vet commands has moved to the
<a href="//code.google.com/p/go.tools">go.tools</a> subrepository.
<a href="http://code.google.com/p/go.tools">go.tools</a> subrepository.
</p>
<p>
@@ -218,7 +218,7 @@ no client Go code depends on the their source and no updating is required.
</p>
<p>
The binary distributions available from <a href="//golang.org">golang.org</a>
The binary distributions available from <a href="http://golang.org">golang.org</a>
include these binaries, so users of these distributions are unaffected.
</p>
@@ -448,7 +448,7 @@ The new interfaces are called
and
<a href="/pkg/encoding/#TextUnmarshaler"><code>TextUnmarshaler</code></a>.
Full details are in the <a href="/pkg/encoding/">documentation</a> for the package
and a separate <a href="//golang.org/s/go12encoding">design document</a>.
and a separate <a href="http://golang.org/s/go12encoding">design document</a>.
</p>
<h3 id="fmt_indexed_arguments">The fmt package</h3>

View File

@@ -66,7 +66,7 @@ It runs on the 32-bit Intel architectures (<code>GOARCH=386</code>) and also on
There is not yet support for Native Client on ARM.
Note that this is Native Client (NaCl), not Portable Native Client (PNaCl).
Details about Native Client are <a href="https://developers.google.com/native-client/dev/">here</a>;
how to set up the Go version is described <a href="//golang.org/wiki/NativeClient">here</a>.
how to set up the Go version is described <a href="http://golang.org/wiki/NativeClient">here</a>.
</p>
<h3 id="netbsd">Support for NetBSD</h3>
@@ -118,7 +118,7 @@ than is available, its stack is transferred to a larger single block of memory.
The overhead of this transfer operation amortizes well and eliminates the old "hot spot"
problem when a calculation repeatedly steps across a segment boundary.
Details including performance numbers are in this
<a href="//golang.org/s/contigstacks">design document</a>.
<a href="http://golang.org/s/contigstacks">design document</a>.
</p>
<h3 id="garbage_collector">Changes to the garbage collector</h3>
@@ -141,7 +141,7 @@ Programs that use <a href="/pkg/unsafe/">package unsafe</a> to store pointers
in integer-typed values are also illegal but more difficult to diagnose during execution.
Because the pointers are hidden from the runtime, a stack expansion or garbage collection
may reclaim the memory they point at, creating
<a href="//en.wikipedia.org/wiki/Dangling_pointer">dangling pointers</a>.
<a href="http://en.wikipedia.org/wiki/Dangling_pointer">dangling pointers</a>.
</p>
<p>
@@ -154,7 +154,7 @@ Such code can be identified by <code>go vet</code>.
<p>
Iterations over small maps no longer happen in a consistent order.
Go 1 defines that &ldquo;<a href="//golang.org/ref/spec#For_statements">The iteration order over maps
Go 1 defines that &ldquo;<a href="http://golang.org/ref/spec#For_statements">The iteration order over maps
is not specified and is not guaranteed to be the same from one iteration to the next.</a>&rdquo;
To keep code from depending on map iteration order,
Go 1.0 started each map iteration at a random index in the map.
@@ -175,7 +175,7 @@ Because only small maps are affected, the problem arises most often in tests.
<h3 id="liblink">The linker</h3>
<p>
As part of the general <a href="//golang.org/s/go13linker">overhaul</a> to
As part of the general <a href="http://golang.org/s/go13linker">overhaul</a> to
the Go linker, the compilers and linkers have been refactored.
The linker is still a C program, but now the instruction selection phase that
was part of the linker has been moved to the compiler through the creation of a new
@@ -298,7 +298,7 @@ For example,
<h3 id="godoc">Changes to godoc</h3>
<p>
When invoked with the <code>-analysis</code> flag,
<a href="//godoc.org/golang.org/x/tools/cmd/godoc">godoc</a>
<a href="http://godoc.org/code.google.com/p/go.tools/cmd/godoc">godoc</a>
now performs sophisticated <a href="/lib/godoc/analysis/help.html">static
analysis</a> of the code it indexes.
The results of analysis are presented in both the source view and the
@@ -318,7 +318,7 @@ call sites and their callees.
The program <code>misc/benchcmp</code> that compares
performance across benchmarking runs has been rewritten.
Once a shell and awk script in the main repository, it is now a Go program in the <code>go.tools</code> repo.
Documentation is <a href="//godoc.org/golang.org/x/tools/cmd/benchcmp">here</a>.
Documentation is <a href="http://godoc.org/code.google.com/p/go.tools/cmd/benchcmp">here</a>.
</p>
<p>
@@ -521,15 +521,6 @@ field to specify an end-to-end timeout on requests made using the
client.
</li>
<li>
The <a href="/pkg/net/http/"><code>net/http</code></a> package's
<a href="/pkg/net/http/#Request.ParseMultipartForm"><code>Request.ParseMultipartForm</code></a>
method will now return an error if the body's <code>Content-Type</code>
is not <code>mutipart/form-data</code>.
Prior to Go 1.3 it would silently fail and return <code>nil</code>.
Code that relies on the previous behavior should be updated.
</li>
<li> In the <a href="/pkg/net/"><code>net</code></a> package,
the <a href="/pkg/net/#Dialer"><code>Dialer</code></a> struct now
has a <code>KeepAlive</code> option to specify a keep-alive period for the connection.

View File

@@ -1,896 +0,0 @@
<!--{
"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/crypo/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>&amp;map[string]int{"one":</code> <code>1}</code> now prints by default as
<code>&amp;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>

View File

@@ -1,55 +0,0 @@
Overall:
build: Go 1.4 required to build (https://golang.org/cl/2470, https://golang.org/cl/2993)
New Ports:
Darwin/ARM, a.k.a iOS. (https://golang.org/cl/2118, 2119, 3273, 2121, 2122, ..., 2127)
API additions and behavior changes:
bufio: add Reader.Discard (https://golang.org/cl/2260)
crypto/cipher: clarify what will happen if len(src) != len(dst) for the Stream interface. (https://golang.org/cl/1754)
crypto/elliptic: add Name field to CurveParams struct (https://golang.org/cl/2133)
crypto/tls: change default minimum version to TLS 1.0. (https://golang.org/cl/1791)
encoding/base64: add unpadded encodings (https://golang.org/cl/1511)
log: add SetOutput functions (https://golang.org/cl/2686, https://golang.org/cl/3023)
net/http: support for setting trailers from a server Handler (https://golang.org/cl/2157)
net/http/cgi: fix REMOTE_ADDR, REMOTE_HOST, add REMOTE_PORT (https://golang.org/cl/4933)
net/smtp: add TLSConnectionState accessor (https://golang.org/cl/2151)
os/signal: add Ignore and Reset (https://golang.org/cl/3580)
runtime, syscall: use SYSCALL instruction on FreeBSD (Go 1.5 now requires FreeBSD 8-STABLE+) (https://golang.org/cl/3020)
strings: add Compare(x, y string) int, for symmetry with bytes.Compare (https://golang.org/cl/2828)
testing/quick: support generation of arrays (https://golang.org/cl/3865)
Tools:
cmd/go: std wildcard now excludes commands in main repo (https://golang.org/cl/5550)
cmd/vet: better validation of struct tags (https://golang.org/cl/2685)
cmd/ld: no longer record build timestamp in Windows PE file header (https://golang.org/cl/3740)
Performance:
cmd/gc: optimize memclr of slices and arrays (https://golang.org/cl/2520)
sort: number of Sort performance optimizations (https://golang.org/cl/2100, https://golang.org/cl/2614, ...)
strconv: optimize decimal to string conversion (https://golang.org/cl/2105)
math/big: faster assembly kernels for amd64 and 386 (https://golang.org/cl/2503, https://golang.org/cl/2560)
math/big: faster "pure Go" kernels for platforms w/o assembly kernels (https://golang.org/cl/2480)
Assembler:
ARM assembly syntax has had some features removed.
- mentioning SP or PC as a hardware register
These are always pseudo-registers except that in some contexts
they're not, and it's confusing because the context should not affect
which register you mean. Change the references to the hardware
registers to be explicit: R13 for SP, R15 for PC.
- constant creation using assignment
The files say a=b when they could instead say #define a b.
There is no reason to have both mechanisms.
- R(0) to refer to R0.
Some macros use this to a great extent. Again, it's easy just to
use a #define to rename a register.
Also expression evaluation now uses uint64s instead of signed integers and the
precedence of operators is now Go-like rather than C-like.

View File

@@ -486,7 +486,7 @@ into subdirectories. For instance, <code>utf8</code> and
<code>utf16</code> now occupy subdirectories of <code>unicode</code>.
Also, <a href="#subrepo">some packages</a> have moved into
subrepositories of
<a href="//code.google.com/p/go"><code>code.google.com/p/go</code></a>
<a href="http://code.google.com/p/go"><code>code.google.com/p/go</code></a>
while <a href="#deleted">others</a> have been deleted outright.
</p>
@@ -565,7 +565,7 @@ by hand.
<p>
Because they are not standardized, the packages under the <code>exp</code> directory will not be available in the
standard Go 1 release distributions, although they will be available in source code form
in <a href="//code.google.com/p/go/">the repository</a> for
in <a href="http://code.google.com/p/go/">the repository</a> for
developers who wish to use them.
</p>
@@ -651,7 +651,7 @@ and also the command <code>gotry</code>.
<em>Updating</em>:
Code that uses <code>container/vector</code> should be updated to use
slices directly. See
<a href="//code.google.com/p/go-wiki/wiki/SliceTricks">the Go
<a href="http://code.google.com/p/go-wiki/wiki/SliceTricks">the Go
Language Community Wiki</a> for some suggestions.
Code that uses the other packages (there should be almost zero) will need to be rethought.
</p>
@@ -660,7 +660,7 @@ Code that uses the other packages (there should be almost zero) will need to be
<p>
Go 1 has moved a number of packages into other repositories, usually sub-repositories of
<a href="//code.google.com/p/go/">the main Go repository</a>.
<a href="http://code.google.com/p/go/">the main Go repository</a>.
This table lists the old and new import paths:
<table class="codetable" frame="border" summary="Sub-repositories">
@@ -1695,7 +1695,7 @@ The compiler will catch code using the old interface.
The <a href="/pkg/regexp/"><code>regexp</code></a> package has been rewritten.
It has the same interface but the specification of the regular expressions
it supports has changed from the old "egrep" form to that of
<a href="//code.google.com/p/re2/">RE2</a>.
<a href="http://code.google.com/p/re2/">RE2</a>.
</p>
<p>
@@ -1912,7 +1912,7 @@ package <a href="/pkg/reflect/"><code>reflect</code></a>.
<em>Updating</em>:
Code using these functions must be rewritten to use
package <a href="/pkg/reflect/"><code>reflect</code></a>.
The changes to <a href="//golang.org/change/2646dc956207">encoding/gob</a> and the <a href="//code.google.com/p/goprotobuf/source/detail?r=5340ad310031">protocol buffer library</a>
The changes to <a href="http://code.google.com/p/go/source/detail?r=2646dc956207">encoding/gob</a> and the <a href="http://code.google.com/p/goprotobuf/source/detail?r=5340ad310031">protocol buffer library</a>
may be helpful as examples.
</p>
@@ -2035,4 +2035,4 @@ They are available for many combinations of architecture and operating system
Installation details are described on the
<a href="/doc/install">Getting Started</a> page, while
the distributions themselves are listed on the
<a href="https://golang.org/dl/">downloads page</a>.
<a href="/dl/">downloads page</a>.

View File

@@ -83,16 +83,16 @@ break if the bug is fixed. We reserve the right to fix such bugs.
<li>
Struct literals. For the addition of features in later point
releases, it may be necessary to add fields to exported structs in
the API. Code that uses unkeyed struct literals (such as pkg.T{3,
the API. Code that uses untagged struct literals (such as pkg.T{3,
"x"}) to create values of these types would fail to compile after
such a change. However, code that uses keyed literals (pkg.T{A:
such a change. However, code that uses tagged literals (pkg.T{A:
3, B: "x"}) will continue to compile after such a change. We will
update such data structures in a way that allows keyed struct
literals to remain compatible, although unkeyed literals may fail
update such data structures in a way that allows tagged struct
literals to remain compatible, although untagged literals may fail
to compile. (There are also more intricate cases involving nested
data structures or interfaces, but they have the same resolution.)
We therefore recommend that composite literals whose type is defined
in a separate package should use the keyed notation.
in a separate package should use the tagged notation.
</li>
<li>
@@ -104,14 +104,6 @@ outside of tests, and using it may cause a program to fail
to compile in future releases.
</li>
<li>
Use of package <code>unsafe</code>. Packages that import
<a href="/pkg/unsafe/"><code>unsafe</code></a>
may depend on internal properties of the Go implementation.
We reserve the right to make changes to the implementation
that may break such programs.
</li>
</ul>
<p>
@@ -153,28 +145,13 @@ developed software based on Go 1.
<p>
Code in sub-repositories of the main go tree, such as
<a href="//golang.org/x/net">golang.org/x/net</a>,
<a href="http://code.google.com/p/go.net">code.google.com/p/go.net</a>,
may be developed under
looser compatibility requirements. However, the sub-repositories
will be tagged as appropriate to identify versions that are compatible
with the Go 1 point releases.
</p>
<h2 id="operating_systems">Operating systems</h2>
<p>
It is impossible to guarantee long-term compatibility with operating
system interfaces, which are changed by outside parties.
The <a href="/pkg/syscall/"><code>syscall</code></a> package
is therefore outside the purview of the guarantees made here.
As of Go version 1.4, the <code>syscall</code> package is frozen.
Any evolution of the system call interface must be supported elsewhere,
such as in the
<a href="//golang.org/x/sys">go.sys</a> subrepository.
For details and background, see
<a href="//golang.org/s/go1.4-syscall">this document</a>.
</p>
<h2 id="tools">Tools</h2>
<p>

View File

@@ -57,7 +57,7 @@ software on multicore machines.
<p>
A much more expansive answer to this question is available in the article,
<a href="//talks.golang.org/2012/splash.article">Go at Google:
<a href="http://talks.golang.org/2012/splash.article">Go at Google:
Language Design in the Service of Software Engineering</a>.
<h3 id="What_is_the_status_of_the_project">
@@ -66,7 +66,7 @@ What is the status of the project?</h3>
<p>
Go became a public open source project on November 10, 2009.
After a couple of years of very active design and development, stability was called for and
Go 1 was <a href="//blog.golang.org/2012/03/go-version-1-is-released.html">released</a>
Go 1 was <a href="http://blog.golang.org/2012/03/go-version-1-is-released.html">released</a>
on March 28, 2012.
Go 1, which includes a <a href="/ref/spec">language specification</a>,
<a href="/pkg/">standard libraries</a>,
@@ -163,7 +163,7 @@ language was called for.
</p>
<p>
The article <a href="//talks.golang.org/2012/splash.article">Go at Google</a>
The article <a href="http://talks.golang.org/2012/splash.article">Go at Google</a>
discusses the background and motivation behind the design of the Go language,
as well as providing more detail about many of the answers presented in this FAQ.
</p>
@@ -221,14 +221,14 @@ easier to understand what happens when things combine.
<p>
Yes. There are now several Go programs deployed in
production inside Google. A public example is the server behind
<a href="//golang.org">golang.org</a>.
<a href="http://golang.org">http://golang.org</a>.
It's just the <a href="/cmd/godoc"><code>godoc</code></a>
document server running in a production configuration on
<a href="https://developers.google.com/appengine/">Google App Engine</a>.
</p>
<p>
Other examples include the <a href="//github.com/youtube/vitess/">Vitess</a>
Other examples include the <a href="https://code.google.com/p/vitess/">Vitess</a>
system for large-scale SQL installations and Google's download server, <code>dl.google.com</code>,
which delivers Chrome binaries and other large installables such as <code>apt-get</code>
packages.
@@ -260,7 +260,7 @@ Does Go support Google's protocol buffers?</h3>
<p>
A separate open source project provides the necessary compiler plugin and library.
It is available at
<a href="//github.com/golang/protobuf">github.com/golang/protobuf/</a>
<a href="http://code.google.com/p/goprotobuf/">http://code.google.com/p/goprotobuf/</a>
</p>
@@ -270,9 +270,9 @@ Can I translate the Go home page into another language?</h3>
<p>
Absolutely. We encourage developers to make Go Language sites in their own languages.
However, if you choose to add the Google logo or branding to your site
(it does not appear on <a href="//golang.org/">golang.org</a>),
(it does not appear on <a href="http://golang.org/">golang.org</a>),
you will need to abide by the guidelines at
<a href="//www.google.com/permissions/guidelines.html">www.google.com/permissions/guidelines.html</a>
<a href="http://www.google.com/permissions/guidelines.html">http://www.google.com/permissions/guidelines.html</a>
</p>
<h2 id="Design">Design</h2>
@@ -466,7 +466,7 @@ Will you accept my language change?</h3>
<p>
People often suggest improvements to the language—the
<a href="//groups.google.com/group/golang-nuts">mailing list</a>
<a href="http://groups.google.com/group/golang-nuts">mailing list</a>
contains a rich history of such discussions—but very few of these changes have
been accepted.
</p>
@@ -484,7 +484,7 @@ to start talking about what that might be.
<p>
Even if your proposal is compatible with the Go 1 spec, it might
not be in the spirit of Go's design goals.
The article <i><a href="//talks.golang.org/2012/splash.article">Go
The article <i><a href="http://talks.golang.org/2012/splash.article">Go
at Google: Language Design in the Service of Software Engineering</a></i>
explains Go's origins and the motivation behind its design.
</p>
@@ -889,11 +889,6 @@ type is generic; if you care about how many bits an integer holds, Go
encourages you to be explicit.
</p>
<p>
A blog post, title <a href="http://blog.golang.org/constants">Constants</a>,
explores this topic in more detail.
</p>
<h3 id="builtin_maps">
Why are maps built in?</h3>
<p>
@@ -945,9 +940,9 @@ How are libraries documented?</h3>
There is a program, <code>godoc</code>, written in Go, that extracts
package documentation from the source code. It can be used on the
command line or on the web. An instance is running at
<a href="/pkg/">golang.org/pkg/</a>.
<a href="/pkg/">http://golang.org/pkg/</a>.
In fact, <code>godoc</code> implements the full site at
<a href="/">golang.org/</a>.
<a href="/">http://golang.org/</a>.
</p>
<h3 id="Is_there_a_Go_programming_style_guide">
@@ -966,7 +961,7 @@ All the Go code in the repository has been run through <code>gofmt</code>.
<p>
The document titled
<a href="//golang.org/s/comments">Go Code Review Comments</a>
<a href="http://golang.org/s/comments">Go Code Review Comments</a>
is a collection of very short essays about details of Go idiom that are often
missed by programmers.
It is a handy reference for people doing code reviews for Go projects.
@@ -976,7 +971,7 @@ It is a handy reference for people doing code reviews for Go projects.
How do I submit patches to the Go libraries?</h3>
<p>
The library sources are in the <code>src</code> directory of the repository.
The library sources are in <code>go/src/pkg</code>.
If you want to make a significant change, please discuss on the mailing list before embarking.
</p>
@@ -986,6 +981,32 @@ See the document
for more information about how to proceed.
</p>
<h3 id="Why_does_the_project_use_Mercurial_and_not_git">
Why does the project use Mercurial and not git?</h3>
<p>
The Go project, hosted by Google Code at
<a href="http://code.google.com/p/go">code.google.com/p/go</a>,
uses Mercurial as its version control system.
When the project launched,
Google Code supported only Subversion and Mercurial.
Mercurial was a better choice because of its plugin mechanism
that allowed us to create the "codereview" plugin to connect
the project to the excellent code review tools at
<a href="http://codereview.appspot.com">codereview.appspot.com</a>.
</p>
<p>
Programmers who work
with the Go project's source rather than release downloads sometimes
ask for the project to switch to git.
That would be possible, but it would be a lot of work and
would also require reimplementing the codereview plugin.
Given that Mercurial works today, with code review support,
combined with the Go project's mostly linear, non-branching use of
version control, a switch to git doesn't seem worthwhile.
</p>
<h3 id="git_https">
Why does "go get" use HTTPS when cloning a repository?</h3>
@@ -1089,7 +1110,7 @@ error but the situation can still be confusing, because sometimes a
<a href="#different_method_sets">pointer
is necessary to satisfy an interface</a>.
The insight is that although a pointer to a concrete type can satisfy
an interface, with one exception <em>a pointer to an interface can never satisfy an interface</em>.
an interface, with one exception <em>a pointer to an interface can never satisfy a interface</em>.
</p>
<p>
@@ -1283,7 +1304,7 @@ Do not communicate by sharing memory. Instead, share memory by communicating.
</p>
<p>
See the <a href="/doc/codewalk/sharemem/">Share Memory By Communicating</a> code walk and its <a href="//blog.golang.org/2010/07/share-memory-by-communicating.html">associated article</a> for a detailed discussion of this concept.
See the <a href="/doc/codewalk/sharemem/">Share Memory By Communicating</a> code walk and its <a href="http://blog.golang.org/2010/07/share-memory-by-communicating.html">associated article</a> for a detailed discussion of this concept.
</p>
<h3 id="Why_no_multi_CPU">
@@ -1300,7 +1321,7 @@ run-time support to utilize more than one OS thread.
Programs that perform parallel computation should benefit from an increase in
<code>GOMAXPROCS</code>.
However, be aware that
<a href="//blog.golang.org/2013/01/concurrency-is-not-parallelism.html">concurrency
<a href="http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html">concurrency
is not parallelism</a>.
</p>
@@ -1330,14 +1351,14 @@ to speed it up.
</p>
<p>
Go's goroutine scheduler is not as good as it needs to be. In the future, it
Go's goroutine scheduler is not as good as it needs to be. In future, it
should recognize such cases and optimize its use of OS threads. For now,
<code>GOMAXPROCS</code> should be set on a per-application basis.
</p>
<p>
For more detail on this topic see the talk entitled,
<a href="//blog.golang.org/2013/01/concurrency-is-not-parallelism.html">Concurrency
<a href="http://blog.golang.org/2013/01/concurrency-is-not-parallelism.html">Concurrency
is not Parallelism</a>.
<h2 id="Functions_methods">Functions and Methods</h2>
@@ -1550,7 +1571,7 @@ table-driven, iterating over a list of inputs and outputs defined
in a data structure (Go has excellent support for data structure literals).
The work to write a good test and good error messages will then be amortized over many
test cases. The standard Go library is full of illustrative examples, such as in
<a href="/src/fmt/fmt_test.go">the formatting tests for the <code>fmt</code> package</a>.
<a href="/src/pkg/fmt/fmt_test.go">the formatting tests for the <code>fmt</code> package</a>.
</p>
@@ -1569,40 +1590,30 @@ and uses a variant of the Plan 9 loader to generate ELF/Mach-O/PE binaries.
</p>
<p>
We considered using LLVM for <code>gc</code> but we felt it was too large and
slow to meet our performance goals.
</p>
<p>
We also considered writing <code>gc</code>, the original Go compiler, in Go itself but
We considered writing <code>gc</code>, the original Go compiler, in Go itself but
elected not to do so because of the difficulties of bootstrapping and
especially of open source distribution&mdash;you'd need a Go compiler to
set up a Go environment. <code>Gccgo</code>, which came later, makes it possible to
consider writing a compiler in Go.
A plan to do that by machine translation of the existing compiler is under development.
<a href="http://golang.org/s/go13compiler">A separate document</a>
explains the reason for this approach.
consider writing a compiler in Go, which might well happen.
(Go would be a
fine language in which to implement a compiler; a native lexer and
parser are already available in the <a href="/pkg/go/"><code>go</code></a> package
and a type checker is in the works.)
</p>
<p>
That plan aside,
Go is a
fine language in which to implement a self-hosting compiler: a native lexer and
parser are already available in the <a href="/pkg/go/"><code>go</code></a> package
and a separate type checking
<a href="http://godoc.org/golang.org/x/tools/go/types">package</a>
has also been written.
We also considered using LLVM for <code>gc</code> but we felt it was too large and
slow to meet our performance goals.
</p>
<h3 id="How_is_the_run_time_support_implemented">
How is the run-time support implemented?</h3>
<p>
Again due to bootstrapping issues, the run-time code was originally written mostly in C (with a
tiny bit of assembler) although much of it has been translated to Go since then
and one day all of it might be (except for the assembler bits).
<code>Gccgo</code>'s run-time support uses <code>glibc</code>.
<code>Gc</code> uses a custom C library to keep the footprint under
Again due to bootstrapping issues, the run-time code is mostly in C (with a
tiny bit of assembler) although Go is capable of implementing most of
it now. <code>Gccgo</code>'s run-time support uses <code>glibc</code>.
<code>Gc</code> uses a custom library to keep the footprint under
control; it is
compiled with a version of the Plan 9 C compiler that supports
resizable stacks for goroutines.
@@ -1626,8 +1637,8 @@ A simple C "hello, world" program compiled and linked statically using gcc
on Linux is around 750 kB,
including an implementation of <code>printf</code>.
An equivalent Go program using <code>fmt.Printf</code>
is around 1.9 MB, but
that includes more powerful run-time support and type information.
is around 1.2 MB, but
that includes more powerful run-time support.
</p>
<h3 id="unused_variables_and_imports">
@@ -1635,17 +1646,14 @@ Can I stop these complaints about my unused variable/import?</h3>
<p>
The presence of an unused variable may indicate a bug, while
unused imports just slow down compilation,
an effect that can become substantial as a program accumulates
code and programmers over time.
For these reasons, Go refuses to compile programs with unused
variables or imports,
trading short-term convenience for long-term build speed and
program clarity.
unused imports just slow down compilation.
Accumulate enough unused imports in your code tree and
things can get very slow.
For these reasons, Go allows neither.
</p>
<p>
Still, when developing code, it's common to create these situations
When developing code, it's common to create these situations
temporarily and it can be annoying to have to edit them out before the
program will compile.
</p>
@@ -1687,14 +1695,6 @@ func main() {
}
</pre>
<p>
Nowadays, most Go programmers use a tool,
<a href="http://godoc.org/golang.org/x/tools/cmd/goimports">goimports</a>,
which automatically rewrites a Go source file to have the correct imports,
eliminating the unused imports issue in practice.
This program is easily connected to most editors to run automatically when a Go source file is written.
</p>
<h2 id="Performance">Performance</h2>
<h3 id="Why_does_Go_perform_badly_on_benchmark_x">
@@ -1736,7 +1736,7 @@ In any case, Go can often be very competitive.
There has been significant improvement in the performance of many programs
as the language and tools have developed.
See the blog post about
<a href="//blog.golang.org/2011/06/profiling-go-programs.html">profiling
<a href="http://blog.golang.org/2011/06/profiling-go-programs.html">profiling
Go programs</a> for an informative example.
<h2 id="change_from_c">Changes from C</h2>
@@ -1895,7 +1895,7 @@ considerable control over memory layout and allocation, much more than
is typical in garbage-collected languages. A careful programmer can reduce
the garbage collection overhead dramatically by using the language well;
see the article about
<a href="//blog.golang.org/2011/06/profiling-go-programs.html">profiling
<a href="http://blog.golang.org/2011/06/profiling-go-programs.html">profiling
Go programs</a> for a worked example, including a demonstration of Go's
profiling tools.
</p>

View File

@@ -21,29 +21,6 @@ reads of a variable in one goroutine can be guaranteed to
observe values produced by writes to the same variable in a different goroutine.
</p>
<h2>Advice</h2>
<p>
Programs that modify data being simultaneously accessed by multiple goroutines
must serialize such access.
</p>
<p>
To serialize access, protect the data with channel operations or other synchronization primitives
such as those in the <a href="/pkg/sync/"><code>sync</code></a>
and <a href="/pkg/sync/atomic/"><code>sync/atomic</code></a> packages.
</p>
<p>
If you must read the rest of this document to understand the behavior of your program,
you are being too clever.
</p>
<p>
Don't be clever.
</p>
<h2>Happens Before</h2>
<p>

File diff suppressed because it is too large Load Diff

Binary file not shown.

Before

Width:  |  Height:  |  Size: 199 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 215 KiB

View File

@@ -20,11 +20,11 @@ Need help with Go? Try these resources.
<h3 id="wiki"><a href="/wiki">The Go Wiki</a></h3>
<p>A wiki maintained by the Go community.</p>
<h3 id="mailinglist"><a href="//groups.google.com/group/golang-nuts">Go Nuts Mailing List</a></h3>
<h3 id="mailinglist"><a href="http://groups.google.com/group/golang-nuts">Go Nuts Mailing List</a></h3>
<p>
Search the <a href="//groups.google.com/group/golang-nuts">golang-nuts</a>
Search the <a href="http://groups.google.com/group/golang-nuts">golang-nuts</a>
archives and consult the <a href="/doc/go_faq.html">FAQ</a> and
<a href="//golang.org/wiki">wiki</a> before posting.
<a href="http://code.google.com/p/go-wiki/wiki">wiki</a> before posting.
</p>
<h3 id="irc"><a href="irc:irc.freenode.net/go-nuts">Go IRC Channel</a></h3>
@@ -37,7 +37,7 @@ Go IRC channel.</p>
<h3 id="plus"><a href="https://plus.google.com/101406623878176903605/posts">The Go Programming Language at Google+</a></h3>
<p>The Go project's Google+ page.</p>
<h3 id="twitter"><a href="//twitter.com/golang">@golang at Twitter</a></h3>
<h3 id="twitter"><a href="http://twitter.com/golang">@golang at Twitter</a></h3>
<p>The Go project's official Twitter account.</p>
<p>Tweeting about your problem with the <code>#golang</code> hashtag usually
generates some helpful responses.</p>

View File

@@ -77,38 +77,42 @@ The full set of supported combinations is listed in the discussion of
</div>
<h2 id="go14">Install Go compiler binaries</h2>
<h2 id="ctools">Install C tools, if needed</h2>
<p>
The Go tool chain is written in Go. To build it, you need a Go compiler installed.
The scripts that do the initial build of the tools look for an existing Go tool
chain in <code>$HOME/go1.4</code>.
(This path may be overridden by setting the <code>GOROOT_BOOTSTRAP</code>
environment variable.)
The Go tool chain is written in C. To build it, you need a C compiler installed.
Please refer to the <a href="http://code.google.com/p/go-wiki/wiki/InstallFromSource#Install_C_tools">InstallFromSource</a>
page on the Go community Wiki for operating system specific instructions.
</p>
<h2 id="mercurial">Install Mercurial, if needed</h2>
<p>
To perform the next step you must have Mercurial installed. (Check that you
have an <code>hg</code> command.)
</p>
<p>
Build the tools with Go version 1.4 or a point release (1.4.1, 1.4.2 etc.).
Go 1.4 binaries can be found at <a href="/dl/">the downloads page</a>.
</p>
<p>
Download the zip or tarball of Go 1.4 for your platform and extract it to
<code>$HOME/go1.4</code> (or your nominated <code>GOROOT_BOOTSTRAP</code>
location).
</p>
<h2 id="git">Install Git, if needed</h2>
<p>
To perform the next step you must have Git installed. (Check that you
have a <code>git</code> command before proceeding.)
</p>
<p>
If you do not have a working Git installation,
If you do not have a working Mercurial installation,
follow the instructions on the
<a href="http://git-scm.com/downloads">Git downloads</a> page.
<a href="http://mercurial.selenic.com/downloads">Mercurial downloads</a> page.
</p>
<p>
Mercurial versions 1.7.x and up require the configuration of
<a href="http://mercurial.selenic.com/wiki/CACertificates">Certification Authorities</a>
(CAs). Error messages of the form:
</p>
<pre>
warning: code.google.com certificate with fingerprint b1:af: ... bc not verified (check hostfingerprints or web.cacerts config setting)
</pre>
<p>
when using Mercurial indicate that the CAs are missing.
Check your Mercurial version (<code>hg --version</code>) and
<a href="http://mercurial.selenic.com/wiki/CACertificates#Configuration_of_HTTPS_certificate_authorities">configure the CAs</a>
if necessary.
</p>
@@ -117,24 +121,22 @@ follow the instructions on the
<p>Go will install to a directory named <code>go</code>.
Change to the directory that will be its parent
and make sure the <code>go</code> directory does not exist.
Then clone the repository and check out the latest release tag:</p>
Then check out the repository:</p>
<pre>
$ git clone https://go.googlesource.com/go
$ cd go
$ git checkout go1.4
$ hg clone -u release https://code.google.com/p/go
</pre>
<h2 id="head">(Optional) Switch to the master branch</h2>
<h2 id="head">(Optional) Switch to the default branch</h2>
<p>If you intend to modify the go source code, and
<a href="/doc/contribute.html">contribute your changes</a>
to the project, then move your repository
off the release branch, and onto the master (development) branch.
off the release branch, and onto the default (development) branch.
Otherwise, skip this step.</p>
<pre>
$ git checkout master
$ hg update default
</pre>
<h2 id="install">Install Go</h2>
@@ -239,12 +241,12 @@ provides <b>essential setup instructions</b> for using the Go tools.
<p>
The source code for several Go tools (including <a href="/cmd/godoc/">godoc</a>)
is kept in <a href="https://golang.org/x/tools">the go.tools repository</a>.
is kept in <a href="https://code.google.com/p/go.tools">the go.tools repository</a>.
To install all of them, run the <code>go</code> <code>get</code> command:
</p>
<pre>
$ go get golang.org/x/tools/cmd/...
$ go get code.google.com/p/go.tools/cmd/...
</pre>
<p>
@@ -252,12 +254,12 @@ Or if you just want to install a specific command (<code>godoc</code> in this ca
</p>
<pre>
$ go get golang.org/x/tools/cmd/godoc
$ go get code.google.com/p/go.tools/cmd/godoc
</pre>
<p>
To install these tools, the <code>go</code> <code>get</code> command requires
that <a href="#git">Git</a> be installed locally.
that <a href="#mercurial">Mercurial</a> be installed locally.
</p>
<p>
@@ -281,27 +283,31 @@ You can access the latter commands with
The usual community resources such as
<code>#go-nuts</code> on the <a href="http://freenode.net/">Freenode</a> IRC server
and the
<a href="//groups.google.com/group/golang-nuts">Go Nuts</a>
<a href="http://groups.google.com/group/golang-nuts">Go Nuts</a>
mailing list have active developers that can help you with problems
with your installation or your development work.
For those who wish to keep up to date,
there is another mailing list, <a href="//groups.google.com/group/golang-checkins">golang-checkins</a>,
there is another mailing list, <a href="http://groups.google.com/group/golang-checkins">golang-checkins</a>,
that receives a message summarizing each checkin to the Go repository.
</p>
<p>
Bugs can be reported using the <a href="//golang.org/issue/new">Go issue tracker</a>.
Bugs can be reported using the <a href="http://code.google.com/p/go/issues/list">Go issue tracker</a>.
</p>
<h2 id="releases">Keeping up with releases</h2>
<p>
New releases are announced on the
<a href="//groups.google.com/group/golang-announce">golang-announce</a>
The Go project maintains a stable tag in its Mercurial repository:
<code>release</code>.
</p>
<p>
The <code>release</code> tag refers to the current stable release of Go.
Most Go users should use this version. New releases are announced on the
<a href="http://groups.google.com/group/golang-announce">golang-announce</a>
mailing list.
Each announcement mentions the latest release tag, for instance,
<code>go1.4</code>.
</p>
<p>
@@ -310,13 +316,11 @@ To update an existing tree to the latest release, you can run:
<pre>
$ cd go/src
$ git fetch
$ git checkout <i>&lt;tag&gt;</i>
$ hg pull
$ hg update release
$ ./all.bash
</pre>
Where <code>&lt;tag&gt;</code> is the version string of the release.
<h2 id="environment">Optional environment variables</h2>
@@ -478,8 +482,8 @@ should target. If you are compiling on the target system, its value will be auto
<p>
If in doubt, leave this variable unset, and adjust it if required
when you first run the Go executable.
The <a href="//golang.org/wiki/GoArm">GoARM</a> page
on the <a href="//golang.org/wiki">Go community wiki</a>
The <a href="http://code.google.com/p/go-wiki/wiki/GoArm">GoARM</a> page
on the <a href="http://code.google.com/p/go-wiki/w/list">Go community wiki</a>
contains further details regarding Go's ARM support.
</p>

View File

@@ -6,18 +6,17 @@
<h2 id="download">Download the Go distribution</h2>
<p>
<a href="https://golang.org/dl/" id="start" class="download" target="_blank">
<a href="/dl/" id="start" class="download" target="_blank">
<span class="big">Download Go</span>
<span class="desc">Click here to visit the downloads page</span>
</a>
</p>
<p>
<a href="https://golang.org/dl/" target="_blank">Official binary
distributions</a> are available for the FreeBSD (release 8-STABLE and above),
Linux, Mac OS X (Snow Leopard and above), and Windows operating systems and
the 32-bit (<code>386</code>) and 64-bit (<code>amd64</code>) x86 processor
architectures.
<a href="https://code.google.com/p/go/wiki/Downloads?tm=2" target="_blank">Official binary
distributions</a> are available for the FreeBSD (release 8 and above), Linux, Mac OS X (Snow Leopard
and above), and Windows operating systems and the 32-bit (<code>386</code>) and
64-bit (<code>amd64</code>) x86 processor architectures.
</p>
<p>
@@ -45,10 +44,10 @@ proceeding. If your OS or architecture is not on the list, it's possible that
<th align="center">Notes</th>
</tr>
<tr><td colspan="3"><hr></td></tr>
<tr><td>FreeBSD 8-STABLE or later</td> <td>amd64, 386, arm</td> <td>Debian GNU/kFreeBSD not supported; FreeBSD/ARM needs FreeBSD 10 or later</td></tr>
<tr><td>FreeBSD 8 or later</td> <td>amd64, 386, arm</td> <td>Debian GNU/kFreeBSD not supported; FreeBSD/ARM needs FreeBSD 10 or later</td></tr>
<tr><td>Linux 2.6.23 or later with glibc</td> <td>amd64, 386, arm</td> <td>CentOS/RHEL 5.x not supported; no binary distribution for ARM yet</td></tr>
<tr><td>Mac OS X 10.6 or later</td> <td>amd64, 386</td> <td>use the gcc<sup>&#8224;</sup> that comes with Xcode<sup>&#8225;</sup></td></tr>
<tr><td>Windows XP or later</td> <td>amd64, 386</td> <td>use MinGW gcc<sup>&#8224;</sup>. No need for cygwin or msys.</td></tr>
<tr><td>Windows XP or later</td> <td>amd64, 386</td> <td>use MinGW gcc<sup>&#8224;</sup>. No need for cgywin or msys.</td></tr>
</table>
<p>
@@ -71,7 +70,7 @@ first <a href="#uninstall">remove the existing version</a>.
<h3 id="tarball">Linux, Mac OS X, and FreeBSD tarballs</h3>
<p>
<a href="https://golang.org/dl/">Download the archive</a>
<a href="https://code.google.com/p/go/wiki/Downloads?tm=2">Download the archive</a>
and extract it into <code>/usr/local</code>, creating a Go tree in
<code>/usr/local/go</code>. For example:
</p>
@@ -128,7 +127,7 @@ location.
<h3 id="osx">Mac OS X package installer</h3>
<p>
<a href="https://golang.org/dl/">Download the package file</a>,
<a href="https://code.google.com/p/go/wiki/Downloads?tm=2">Download the package file</a>,
open it, and follow the prompts to install the Go tools.
The package installs the Go distribution to <code>/usr/local/go</code>.
</p>
@@ -151,7 +150,7 @@ MSI installer that configures your installation automatically.
<h4 id="windows_msi">MSI installer</h4>
<p>
Open the <a href="https://golang.org/dl/">MSI file</a>
Open the <a href="https://code.google.com/p/go/wiki/Downloads?tm=2">MSI file</a>
and follow the prompts to install the Go tools.
By default, the installer puts the Go distribution in <code>c:\Go</code>.
</p>
@@ -165,7 +164,7 @@ command prompts for the change to take effect.
<h4 id="windows_zip">Zip archive</h4>
<p>
<a href="https://golang.org/dl/">Download the zip file</a> and extract it into the directory of your choice (we suggest <code>c:\Go</code>).
<a href="https://code.google.com/p/go/wiki/Downloads?tm=2">Download the zip file</a> and extract it into the directory of your choice (we suggest <code>c:\Go</code>).
</p>
<p>
@@ -225,12 +224,19 @@ If you see the "hello, world" message then your Go installation is working.
<p>
You're almost done.
You just need to set up your environment.
You just need to do a little more setup.
</p>
<p>
Read the <a href="/doc/code.html">How to Write Go Code</a> document,
which provides <b>essential setup instructions</b> for using the Go tools.
<a href="/doc/code.html" class="download" id="writing">
<span class="big">How to Write Go Code</span>
<span class="desc">Learn how to set up and use the Go tools</span>
</a>
</p>
<p>
The <a href="/doc/code.html">How to Write Go Code</a> document
provides <b>essential setup instructions</b> for using the Go tools.
</p>
@@ -264,10 +270,12 @@ For real-time help, ask the helpful gophers in <code>#go-nuts</code> on the
<p>
The official mailing list for discussion of the Go language is
<a href="//groups.google.com/group/golang-nuts">Go Nuts</a>.
<a href="http://groups.google.com/group/golang-nuts">Go Nuts</a>.
</p>
<p>
Report bugs using the
<a href="//golang.org/issue">Go issue tracker</a>.
<a href="http://code.google.com/p/go/issues/list">Go issue tracker</a>.
</p>

BIN
doc/logo-153x55.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.3 KiB

View File

@@ -3,9 +3,9 @@
// (the nodes are the data).
// http://en.wikipedia.org/wiki/Peano_axioms
// This program demonstrates that Go's automatic
// stack management can handle heavily recursive
// computations.
// This program demonstrates the power of Go's
// segmented stacks when doing massively
// recursive computations.
package main

View File

@@ -26,7 +26,7 @@ Hello, 世界
<div class="buttons">
<a class="run" href="#" title="Run this code [shift-enter]">Run</a>
<a class="share" href="#" title="Share this code">Share</a>
<a class="tour" href="//tour.golang.org/" title="Learn Go from your browser">Tour</a>
<a class="tour" href="http://tour.golang.org/" title="Learn Go from your browser">Tour</a>
</div>
<div class="toys">
<select>
@@ -78,7 +78,7 @@ Linux, Mac OS X, Windows, and more.
<div id="blog">
<div class="rootHeading">Featured articles</div>
<div class="read"><a href="//blog.golang.org/">Read more</a></div>
<div class="read"><a href="http://blog.golang.org/">Read more</a></div>
</div>
</div>
@@ -124,7 +124,7 @@ window.initFuncs.push(function() {
"outputEl": "#learn .output",
"runEl": "#learn .run",
"shareEl": "#learn .share",
"shareRedirect": "//play.golang.org/p/",
"shareRedirect": "http://play.golang.org/p/",
"toysEl": "#learn .toys select"
});
} else {
@@ -133,7 +133,7 @@ window.initFuncs.push(function() {
// Load blog feed.
$('<script/>').attr('text', 'text/javascript')
.attr('src', '//blog.golang.org/.json?jsonp=feedLoaded')
.attr('src', 'http://blog.golang.org/.json?jsonp=feedLoaded')
.appendTo('body');
// Set the video at random.

BIN
doc/sieve.gif Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 11 KiB

View File

@@ -5,7 +5,7 @@
<p>
The Go website (the "Website") is hosted by Google.
By using and/or visiting the Website, you consent to be bound by Google's general
<a href="//www.google.com/intl/en/policies/terms/">Terms of Service</a>
<a href="http://www.google.com/intl/en/policies/terms/">Terms of Service</a>
and Google's general
<a href="//www.google.com/intl/en/privacy/privacy-policy.html">Privacy Policy</a>.
<a href="http://www.google.com/intl/en/privacy/privacy-policy.html">Privacy Policy</a>.
</p>

View File

@@ -129,14 +129,6 @@ int Bungetc(Biobuf*);
int Bungetrune(Biobuf*);
long Bwrite(Biobuf*, void*, long);
int Bvprint(Biobuf*, char*, va_list);
/*c2go
int BGETC(Biobuf*);
int BGETLE2(Biobuf*);
int BGETLE4(Biobuf*);
int BPUTC(Biobuf*, int);
int BPUTLE2(Biobuf*, int);
int BPUTLE4(Biobuf*, int);
*/
#if defined(__cplusplus)
}

View File

@@ -292,8 +292,6 @@ extern char* getgoversion(void);
extern char* getgoarm(void);
extern char* getgo386(void);
extern char* getgoextlinkenabled(void);
extern char* getgohostos(void);
extern char* getgohostarch(void);
extern char* mktempdir(void);
extern void removeall(char*);
@@ -312,15 +310,24 @@ extern void flagprint(int);
#ifdef _WIN32
#if !defined(_WIN64) && !defined(__MINGW64_VERSION_MAJOR)
struct timespec {
int tv_sec;
long tv_nsec;
};
#define execv(prog, argv) execv(prog, (const char* const*)(argv))
#define execvp(prog, argv) execvp(prog, (const char**)(argv))
#endif
extern int nanosleep(const struct timespec *rqtp, struct timespec *rmtp);
extern int fork(void);
extern int pread(int fd, void *buf, int n, int off);
extern int pwrite(int fd, void *buf, int n, int off);
#undef getwd
#define getwd(s, ns) getcwd(s, ns)
#undef lseek
#define lseek(fd, n, base) _lseeki64(fd, n, base)
#define mkdir(path, perm) mkdir(path)
#define pipe(fd) _pipe(fd, 512, O_BINARY)
#else
#define O_BINARY 0
#endif

View File

@@ -43,156 +43,32 @@ typedef struct Pcln Pcln;
typedef struct Pcdata Pcdata;
typedef struct Pciter Pciter;
// An Addr is an argument to an instruction.
// The general forms and their encodings are:
//
// sym±offset(symkind)(reg)(index*scale)
// Memory reference at address &sym(symkind) + offset + reg + index*scale.
// Any of sym(symkind), ±offset, (reg), (index*scale), and *scale can be omitted.
// If (reg) and *scale are both omitted, the resulting expression (index) is parsed as (reg).
// To force a parsing as index*scale, write (index*1).
// Encoding:
// type = TYPE_MEM
// name = symkind (NAME_AUTO, ...) or 0 (NAME_NONE)
// sym = sym
// offset = ±offset
// reg = reg (REG_*)
// index = index (REG_*)
// scale = scale (1, 2, 4, 8)
//
// $<mem>
// Effective address of memory reference <mem>, defined above.
// Encoding: same as memory reference, but type = TYPE_ADDR.
//
// $<±integer value>
// This is a special case of $<mem>, in which only ±offset is present.
// It has a separate type for easy recognition.
// Encoding:
// type = TYPE_CONST
// offset = ±integer value
//
// *<mem>
// Indirect reference through memory reference <mem>, defined above.
// Only used on x86 for CALL/JMP *sym(SB), which calls/jumps to a function
// pointer stored in the data word sym(SB), not a function named sym(SB).
// Encoding: same as above, but type = TYPE_INDIR.
//
// $*$<mem>
// No longer used.
// On machines with actual SB registers, $*$<mem> forced the
// instruction encoding to use a full 32-bit constant, never a
// reference relative to SB.
//
// $<floating point literal>
// Floating point constant value.
// Encoding:
// type = TYPE_FCONST
// u.dval = floating point value
//
// $<string literal, up to 8 chars>
// String literal value (raw bytes used for DATA instruction).
// Encoding:
// type = TYPE_SCONST
// u.sval = string
//
// <register name>
// Any register: integer, floating point, control, segment, and so on.
// If looking for specific register kind, must check type and reg value range.
// Encoding:
// type = TYPE_REG
// reg = reg (REG_*)
//
// x(PC)
// Encoding:
// type = TYPE_BRANCH
// u.branch = Prog* reference OR ELSE offset = target pc (branch takes priority)
//
// $±x-±y
// Final argument to TEXT, specifying local frame size x and argument size y.
// In this form, x and y are integer literals only, not arbitrary expressions.
// This avoids parsing ambiguities due to the use of - as a separator.
// The ± are optional.
// If the final argument to TEXT omits the -±y, the encoding should still
// use TYPE_TEXTSIZE (not TYPE_CONST), with u.argsize = ArgsSizeUnknown.
// Encoding:
// type = TYPE_TEXTSIZE
// offset = x
// u.argsize = y
//
// reg<<shift, reg>>shift, reg->shift, reg@>shift
// Shifted register value, for ARM.
// In this form, reg must be a register and shift can be a register or an integer constant.
// Encoding:
// type = TYPE_SHIFT
// offset = (reg&15) | shifttype<<5 | count
// shifttype = 0, 1, 2, 3 for <<, >>, ->, @>
// count = (reg&15)<<8 | 1<<4 for a register shift count, (n&31)<<7 for an integer constant.
//
// (reg, reg)
// A destination register pair. When used as the last argument of an instruction,
// this form makes clear that both registers are destinations.
// Encoding:
// type = TYPE_REGREG
// reg = first register
// offset = second register
//
// reg, reg
// TYPE_REGREG2, to be removed.
//
// prevent incompatible type signatures between liblink and 8l on Plan 9
#pragma incomplete struct Node
struct Addr
{
int16 type; // could be int8
int16 reg;
int16 index;
int8 scale;
int8 name;
int64 offset;
LSym* sym;
vlong offset;
union
{
char sval[8];
float64 dval;
Prog* branch;
int32 argsize; // for 5l, 8l
uint64 bits; // raw union bits, for testing if anything has been written to any field
Prog* branch; // for 5g, 6g, 8g
} u;
// gotype is the name of the Go type descriptor for sym.
// It cannot be set using assembly syntax.
// It is generated by the Go compiler for global declarations,
// to convey information about pointer locations to the back end
// and for use in generating debug information.
LSym* sym;
LSym* gotype;
int8 class; // for internal use by liblink
uint8 etype; // for internal use by 5g, 6g, 8g
void* node; // for internal use by 5g, 6g, 8g
int64 width; // for internal use by 5g, 6g, 8g
};
enum {
NAME_NONE = 0,
NAME_EXTERN,
NAME_STATIC,
NAME_AUTO,
NAME_PARAM,
};
enum {
TYPE_NONE = 0,
TYPE_BRANCH = 5, // avoid accidental conflicts with NAME_*
TYPE_TEXTSIZE,
TYPE_MEM,
TYPE_CONST,
TYPE_FCONST,
TYPE_SCONST,
TYPE_REG,
TYPE_ADDR,
TYPE_SHIFT,
TYPE_REGREG,
TYPE_REGREG2,
TYPE_INDIR,
short type;
uint8 index;
int8 scale;
int8 reg; // for 5l
int8 name; // for 5l
int8 class; // for 5l
uint8 etype; // for 5g, 6g, 8g
int32 offset2; // for 5l, 8l
struct Node* node; // for 5g, 6g, 8g
int64 width; // for 5g, 6g, 8g
};
struct Reloc
@@ -201,86 +77,43 @@ struct Reloc
uchar siz;
uchar done;
int32 type;
int32 variant; // RV_*: variant on computed value
int64 add;
int64 xadd;
LSym* sym;
LSym* xsym;
};
// TODO(rsc): Describe prog.
// TODO(rsc): Describe TEXT/GLOBL flag in from3, DATA width in from3.
struct Prog
{
vlong pc;
int32 lineno;
Prog* link;
short as;
uchar scond; // arm only; condition codes
// operands
uchar reg; // arm only
uchar scond; // arm only
Addr from;
int16 reg; // arm, ppc64 only (e.g., ADD from, reg, to);
// starts at 0 for both GPRs and FPRs;
// also used for ADATA width on arm, ppc64
Addr from3; // addl source argument (e.g., RLWM/FMADD from, reg, from3, to)
Addr to;
// for 5g, 6g, 8g internal use
void* opt;
// for liblink internal use
// for 5l, 6l, 8l internal use
Prog* forwd;
Prog* pcond;
Prog* comefrom; // amd64, 386
Prog* pcrel; // arm
Prog* comefrom; // 6l, 8l
Prog* pcrel; // 5l
int32 spadj;
uint16 mark;
uint16 optab; // arm, ppc64
uchar back; // amd64, 386
uchar ft; // oclass cache
uchar tt; // oclass cache
uchar isize; // amd64, 386
uchar printed;
uchar mark;
uchar back; // 6l, 8l
char ft; /* 6l, 8l oclass cache */
char tt; // 6l, 8l
uchar optab; // 5l
uchar isize; // 6l, 8l
char width; /* fake for DATA */
char mode; /* 16, 32, or 64 in 6l, 8l; internal use in 5g, 6g, 8g */
};
extern Prog zprog; // zeroed Prog
// Prog.as opcodes.
// These are the portable opcodes, common to all architectures.
// Each architecture defines many more arch-specific opcodes,
// with values starting at A_ARCHSPECIFIC.
enum {
AXXX = 0,
ACALL,
ACHECKNIL,
ADATA,
ADUFFCOPY,
ADUFFZERO,
AEND,
AFUNCDATA,
AGLOBL,
AJMP,
ANOP,
APCDATA,
ARET,
ATEXT,
ATYPE,
AUNDEF,
AUSEFIELD,
AVARDEF,
AVARKILL,
A_ARCHSPECIFIC, // first architecture-specific opcode value
};
void nopout(Prog*);
void nocache(Prog*);
// prevent incompatible type signatures between liblink and 8l on Plan 9
#pragma incomplete struct Section
@@ -291,7 +124,6 @@ struct LSym
short type;
short version;
uchar dupok;
uchar cfunc;
uchar external;
uchar nosplit;
uchar reachable;
@@ -301,10 +133,8 @@ struct LSym
uchar hide;
uchar leaf; // arm only
uchar fnptr; // arm only
uchar localentry; // ppc64: instrs between global & local entry
uchar seenglobl;
uchar onlist; // on the textp or datap lists
uchar printed;
int16 symid; // for writing .5/.6/.8 files
int32 dynid;
int32 sig;
@@ -337,7 +167,7 @@ struct LSym
// SDATA, SBSS
uchar* p;
int np;
int32 np;
int32 maxp;
Reloc* r;
int32 nr;
@@ -371,11 +201,10 @@ enum
SELFSECT,
SMACHO, /* Mach-O __nl_symbol_ptr */
SMACHOGOT,
SWINDOWS,
SELFGOT, /* also .toc in ppc64 ABI */
SNOPTRDATA,
SINITARR,
SDATA,
SWINDOWS,
SBSS,
SNOPTRBSS,
STLSBSS,
@@ -401,12 +230,10 @@ enum
enum
{
R_ADDR = 1,
R_ADDRPOWER, // relocation for loading 31-bit address using addis and addi/ld/st for Power
R_SIZE,
R_CALL, // relocation for direct PC-relative call
R_CALLARM, // relocation for ARM direct call
R_CALLIND, // marker for indirect call (no actual relocating necessary)
R_CALLPOWER, // relocation for Power direct call
R_CONST,
R_PCREL,
R_TLS,
@@ -417,23 +244,9 @@ enum
R_PLT1,
R_PLT2,
R_USEFIELD,
R_POWER_TOC, // ELF R_PPC64_TOC16*
};
// Reloc.variant
enum
{
RV_NONE, // identity variant
RV_POWER_LO, // x & 0xFFFF
RV_POWER_HI, // x >> 16
RV_POWER_HA, // (x + 0x8000) >> 16
RV_POWER_DS, // x & 0xFFFC, check x&0x3 == 0
RV_CHECK_OVERFLOW = 1<<8, // check overflow flag
RV_TYPE_MASK = (RV_CHECK_OVERFLOW - 1),
};
// Auto.name
// Auto.type
enum
{
A_AUTO = 1,
@@ -445,7 +258,7 @@ struct Auto
LSym* asym;
Auto* link;
int32 aoffset;
int16 name;
int16 type;
LSym* gotype;
};
@@ -460,7 +273,6 @@ struct Hist
char* name;
int32 line;
int32 offset;
uchar printed;
};
struct Plist
@@ -558,7 +370,6 @@ struct Link
char* trimpath;
char* goroot;
char* goroot_final;
int32 enforce_data_order; // for use by assembler
// hash table of all symbols
LSym* hash[LINKHASH];
@@ -578,9 +389,9 @@ struct Link
LSym* sym_divu;
LSym* sym_mod;
LSym* sym_modu;
LSym* symmorestack[2];
LSym* tlsg;
LSym* plan9privates;
LSym* symmorestack[20];
LSym* gmsym;
LSym* plan9tos;
Prog* curp;
Prog* printp;
Prog* blitrl;
@@ -592,7 +403,7 @@ struct Link
int asmode;
uchar* andptr;
uchar and[100];
int64 instoffset;
int32 instoffset;
int32 autosize;
int32 armsize;
@@ -618,26 +429,52 @@ struct Link
LSym* filesyms;
};
enum {
LittleEndian = 0x04030201,
BigEndian = 0x01020304,
};
// LinkArch is the definition of a single architecture.
struct LinkArch
{
char* name; // "arm", "amd64", and so on
int thechar; // '5', '6', and so on
int32 endian; // LittleEndian or BigEndian
void (*preprocess)(Link*, LSym*);
void (*addstacksplit)(Link*, LSym*);
void (*assemble)(Link*, LSym*);
int (*datasize)(Prog*);
void (*follow)(Link*, LSym*);
int (*iscall)(Prog*);
int (*isdata)(Prog*);
Prog* (*prg)(void);
void (*progedit)(Link*, Prog*);
void (*settextflag)(Prog*, int);
int (*symtype)(Addr*);
int (*textflag)(Prog*);
int minlc;
int ptrsize;
int regsize;
// TODO: Give these the same values on all systems.
int D_ADDR;
int D_AUTO;
int D_BRANCH;
int D_CONST;
int D_EXTERN;
int D_FCONST;
int D_NONE;
int D_PARAM;
int D_SCONST;
int D_STATIC;
int ACALL;
int ADATA;
int AEND;
int AFUNCDATA;
int AGLOBL;
int AJMP;
int ANOP;
int APCDATA;
int ARET;
int ATEXT;
int ATYPE;
int AUSEFIELD;
};
/* executable header types */
@@ -681,9 +518,6 @@ void span6(Link *ctxt, LSym *s);
// asm8.c
void span8(Link *ctxt, LSym *s);
// asm9.c
void span9(Link *ctxt, LSym *s);
// data.c
vlong addaddr(Link *ctxt, LSym *s, LSym *t);
vlong addaddrplus(Link *ctxt, LSym *s, LSym *t, vlong add);
@@ -698,7 +532,6 @@ vlong adduint8(Link *ctxt, LSym *s, uint8 v);
vlong adduintxx(Link *ctxt, LSym *s, uint64 v, int wid);
void mangle(char *file);
void savedata(Link *ctxt, LSym *s, Prog *p, char *pn);
void savedata1(Link *ctxt, LSym *s, Prog *p, char *pn, int enforce_order);
vlong setaddr(Link *ctxt, LSym *s, vlong off, LSym *t);
vlong setaddrplus(Link *ctxt, LSym *s, vlong off, LSym *t, vlong add);
vlong setuint16(Link *ctxt, LSym *s, vlong r, uint16 v);
@@ -714,11 +547,6 @@ void* emallocz(long n);
void* erealloc(void *p, long n);
char* estrdup(char *p);
char* expandpkg(char *t0, char *pkg);
void linksetexp(void);
char* expstring(void);
extern int fieldtrack_enabled;
extern int framepointer_enabled;
// ld.c
void addhist(Link *ctxt, int32 line, int type);
@@ -730,17 +558,16 @@ int find1(int32 l, int c);
void linkgetline(Link *ctxt, int32 line, LSym **f, int32 *l);
void histtoauto(Link *ctxt);
void mkfwd(LSym*);
void nuxiinit(LinkArch*);
void nuxiinit(void);
void savehist(Link *ctxt, int32 line, int32 off);
Prog* copyp(Link*, Prog*);
Prog* appendp(Link*, Prog*);
vlong atolwhex(char*);
// list[5689].c
// list[568].c
void listinit5(void);
void listinit6(void);
void listinit8(void);
void listinit9(void);
// obj.c
int linklinefmt(Link *ctxt, Fmt *fp);
@@ -772,33 +599,17 @@ char* headstr(int);
extern char* anames5[];
extern char* anames6[];
extern char* anames8[];
extern char* anames9[];
extern char* cnames5[];
extern char* cnames9[];
extern char* dnames5[];
extern char* dnames6[];
extern char* dnames8[];
extern char* dnames9[];
extern LinkArch link386;
extern LinkArch linkamd64;
extern LinkArch linkamd64p32;
extern LinkArch linkarm;
extern LinkArch linkppc64;
extern LinkArch linkppc64le;
extern int linkbasepointer;
extern void linksetexp(void);
#pragma varargck type "A" int
#pragma varargck type "E" uint
#pragma varargck type "D" Addr*
#pragma varargck type "lD" Addr*
#pragma varargck type "P" Prog*
#pragma varargck type "R" int
#pragma varargck type "^" int // for 5l/9l, C_* classes (liblink internal)
// TODO(ality): remove this workaround.
// It's here because Pconv in liblink/list?.c references %L.

View File

@@ -14,10 +14,6 @@ char* getgoversion(void);
char* getgoarm(void);
char* getgo386(void);
char* getgoextlinkenabled(void);
char* getgohostos(void);
char* getgohostarch(void);
int runcmd(char**);
void flagcount(char*, char*, int*);
void flagint32(char*, char*, int32*);

View File

@@ -40,9 +40,8 @@ extern "C" {
#endif
#define _BSD_SOURCE 1
#define _NETBSD_SOURCE 1 /* NetBSD */
#define _DEFAULT_SOURCE 1 /* glibc > 2.19 */
#define _SVID_SOURCE 1
#if !defined(__APPLE__) && !defined(__OpenBSD__) && !defined(__sun__)
#if !defined(__APPLE__) && !defined(__OpenBSD__)
# define _XOPEN_SOURCE 1000
# define _XOPEN_SOURCE_EXTENDED 1
#endif
@@ -69,11 +68,8 @@ extern "C" {
#include <stddef.h>
#include <math.h>
#include <ctype.h> /* for tolower */
#include <time.h>
#ifdef _WIN32
#include <signal.h>
#endif
#include <time.h>
/*
* OS-specific crap

View File

@@ -0,0 +1 @@
defaultcc: golang-codereviews@googlegroups.com

3621
lib/codereview/codereview.py Normal file

File diff suppressed because it is too large Load Diff

198
lib/codereview/test.sh Executable file
View File

@@ -0,0 +1,198 @@
#!/bin/bash
# Copyright 2011 The Go Authors. All rights reserved.
# Use of this source code is governed by a BSD-style
# license that can be found in the LICENSE file.
# Test the code review plugin.
# Assumes a local Rietveld is running using the App Engine SDK
# at http://localhost:7777/
#
# dev_appserver.py -p 7777 $HOME/pub/rietveld
codereview_script=$(pwd)/codereview.py
server=localhost:7777
master=/tmp/go.test
clone1=/tmp/go.test1
clone2=/tmp/go.test2
export HGEDITOR=true
must() {
if ! "$@"; then
echo "$@" failed >&2
exit 1
fi
}
not() {
if "$@"; then
false
else
true
fi
}
status() {
echo '+++' "$@" >&2
}
firstcl() {
hg pending | sed 1q | tr -d ':'
}
# Initial setup.
status Create repositories.
rm -rf $master $clone1 $clone2
mkdir $master
cd $master
must hg init .
echo Initial state >file
must hg add file
must hg ci -m 'first commit' file
must hg clone $master $clone1
must hg clone $master $clone2
echo "
[ui]
username=Grace R Emlin <gre@golang.org>
[extensions]
codereview=$codereview_script
[codereview]
server=$server
" >>$clone1/.hg/hgrc
cp $clone1/.hg/hgrc $clone2/.hg/hgrc
status Codereview should be disabled.
cd $clone1
must hg status
must not hg pending
status Enabling code review.
must mkdir lib lib/codereview
must touch lib/codereview/codereview.cfg
status Code review should work even without CONTRIBUTORS.
must hg pending
status Add CONTRIBUTORS.
echo 'Grace R Emlin <gre@golang.org>' >CONTRIBUTORS
must hg add lib/codereview/codereview.cfg CONTRIBUTORS
status First submit.
must hg submit -r gre@golang.org -m codereview \
lib/codereview/codereview.cfg CONTRIBUTORS
status Should see change in other client.
cd $clone2
must hg pull -u
must test -f lib/codereview/codereview.cfg
must test -f CONTRIBUTORS
test_clpatch() {
# The email address must be test@example.com to match
# the test code review server's default user.
# Clpatch will check.
cd $clone1
# Tried to use UTF-8 here to test that, but dev_appserver.py crashes. Ha ha.
if false; then
status Using UTF-8.
name="Grácè T Emlïn <test@example.com>"
else
status Using ASCII.
name="Grace T Emlin <test@example.com>"
fi
echo "$name" >>CONTRIBUTORS
cat .hg/hgrc | sed "s/Grace.*/$name/" >/tmp/x && mv /tmp/x .hg/hgrc
echo '
Reviewer: gre@golang.org
Description:
CONTRIBUTORS: add $name
Files:
CONTRIBUTORS
' | must hg change -i
num=$(hg pending | sed 1q | tr -d :)
status Patch CL.
cd $clone2
must hg clpatch $num
must [ "$num" = "$(firstcl)" ]
must hg submit $num
status Issue should be open with no reviewers.
must curl http://$server/api/$num >/tmp/x
must not grep '"closed":true' /tmp/x
must grep '"reviewers":\[\]' /tmp/x
status Sync should close issue.
cd $clone1
must hg sync
must curl http://$server/api/$num >/tmp/x
must grep '"closed":true' /tmp/x
must grep '"reviewers":\[\]' /tmp/x
must [ "$(firstcl)" = "" ]
}
test_reviewer() {
status Submit without reviewer should fail.
cd $clone1
echo dummy >dummy
must hg add dummy
echo '
Description:
no reviewer
Files:
dummy
' | must hg change -i
num=$(firstcl)
must not hg submit $num
must hg revert dummy
must rm dummy
must hg change -d $num
}
test_linearity() {
status Linearity of changes.
cd $clone1
echo file1 >file1
must hg add file1
echo '
Reviewer: gre@golang.org
Description: file1
Files: file1
' | must hg change -i
must hg submit $(firstcl)
cd $clone2
echo file2 >file2
must hg add file2
echo '
Reviewer: gre@golang.org
Description: file2
Files: file2
' | must hg change -i
must not hg submit $(firstcl)
must hg sync
must hg submit $(firstcl)
}
test_restrict() {
status Cannot use hg ci.
cd $clone1
echo file1a >file1a
hg add file1a
must not hg ci -m commit file1a
must rm file1a
must hg revert file1a
status Cannot use hg rollback.
must not hg rollback
status Cannot use hg backout
must not hg backout -r -1
}
test_reviewer
test_clpatch
test_linearity
test_restrict
status ALL TESTS PASSED.

View File

@@ -7,8 +7,8 @@
# downloaded from the ICANN/IANA distribution.
# Versions to use.
CODE=2014j
DATA=2014j
CODE=2014d
DATA=2014d
set -e
rm -rf work

Binary file not shown.

99
misc/IntelliJIDEA/Go.xml Normal file
View File

@@ -0,0 +1,99 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
Copyright 2011 The Go Authors. All rights reserved.
Use of this source code is governed by a BSD-style
license that can be found in the LICENSE file.
Copy this custom language definition & configuration file to
* Mac : ~/Library/Preferences/IntelliJIdea10/filetypes/
* Linux & Windows : ~/.IntelliJIdea10/config/filetypes/
-->
<filetype binary="false" default_extension="" description="Go" name="Go">
<highlighting>
<options>
<option name="LINE_COMMENT" value="//"/>
<option name="COMMENT_START" value="/*"/>
<option name="COMMENT_END" value="*/"/>
<option name="HEX_PREFIX" value="0x"/>
<option name="NUM_POSTFIXES" value=""/>
<option name="HAS_BRACKETS" value="true"/>
<option name="HAS_BRACES" value="true"/>
<option name="HAS_PARENS" value="true"/>
<option name="HAS_STRING_ESCAPES" value="true"/>
</options>
<keywords ignore_case="false">
<keyword name="break"/>
<keyword name="case"/>
<keyword name="chan"/>
<keyword name="const"/>
<keyword name="continue"/>
<keyword name="default"/>
<keyword name="defer"/>
<keyword name="else"/>
<keyword name="fallthrough"/>
<keyword name="for"/>
<keyword name="func"/>
<keyword name="go"/>
<keyword name="goto"/>
<keyword name="if"/>
<keyword name="import"/>
<keyword name="interface"/>
<keyword name="map"/>
<keyword name="package"/>
<keyword name="range"/>
<keyword name="return"/>
<keyword name="select"/>
<keyword name="struct"/>
<keyword name="switch"/>
<keyword name="type"/>
<keyword name="var"/>
</keywords>
<keywords2>
<keyword name="bool"/>
<keyword name="byte"/>
<keyword name="complex64"/>
<keyword name="complex128"/>
<keyword name="float32"/>
<keyword name="float64"/>
<keyword name="int"/>
<keyword name="int8"/>
<keyword name="int16"/>
<keyword name="int32"/>
<keyword name="int64"/>
<keyword name="string"/>
<keyword name="uint"/>
<keyword name="uint8"/>
<keyword name="uint16"/>
<keyword name="uint32"/>
<keyword name="uint64"/>
<keyword name="uintptr"/>
</keywords2>
<keywords3>
<keyword name="append"/>
<keyword name="cap"/>
<keyword name="close"/>
<keyword name="complex"/>
<keyword name="copy"/>
<keyword name="delete"/>
<keyword name="imag"/>
<keyword name="len"/>
<keyword name="make"/>
<keyword name="new"/>
<keyword name="panic"/>
<keyword name="print"/>
<keyword name="println"/>
<keyword name="real"/>
<keyword name="recover"/>
</keywords3>
<keywords4>
<keyword name="false"/>
<keyword name="iota"/>
<keyword name="nil"/>
<keyword name="true"/>
</keywords4>
</highlighting>
<extensionMap>
<mapping ext="go"/>
</extensionMap>
</filetype>

View File

@@ -1,11 +0,0 @@
Android
=======
For details on developing Go for Android, see the documentation in the
mobile subrepository:
https://github.com/golang/mobile
To run the standard library tests, see androidtest.bash. Run it as
CC_FOR_TARGET=.../ndk-gcc GOARCH=arm GOARM=7 ./androidtest.bash

View File

@@ -1,132 +0,0 @@
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// This program can be used as go_android_GOARCH_exec by the Go tool.
// It executes binaries on an android device using adb.
package main
import (
"bytes"
"fmt"
"go/build"
"io"
"log"
"os"
"os/exec"
"path/filepath"
"runtime"
"strconv"
"strings"
)
func run(args ...string) string {
buf := new(bytes.Buffer)
cmd := exec.Command("adb", args...)
cmd.Stdout = io.MultiWriter(os.Stdout, buf)
cmd.Stderr = os.Stderr
log.Printf("adb %s", strings.Join(args, " "))
err := cmd.Run()
if err != nil {
log.Fatalf("adb %s: %v", strings.Join(args, " "), err)
}
return buf.String()
}
const (
// Directory structure on the target device androidtest.bash assumes.
deviceGoroot = "/data/local/tmp/goroot"
deviceGopath = "/data/local/tmp/gopath"
)
func main() {
log.SetFlags(0)
log.SetPrefix("go_android_exec: ")
// Prepare a temporary directory that will be cleaned up at the end.
deviceGotmp := fmt.Sprintf("/data/local/tmp/%s-%d",
filepath.Base(os.Args[1]), os.Getpid())
run("shell", "mkdir", "-p", deviceGotmp)
// Determine the package by examining the current working
// directory, which will look something like
// "$GOROOT/src/mime/multipart" or "$GOPATH/src/golang.org/x/mobile".
// We extract everything after the $GOROOT or $GOPATH to run on the
// same relative directory on the target device.
subdir, inGoRoot := subdir()
deviceCwd := filepath.Join(deviceGoroot, subdir)
if !inGoRoot {
deviceCwd = filepath.Join(deviceGopath, subdir)
}
// Binary names can conflict.
// E.g. template.test from the {html,text}/template packages.
binName := filepath.Base(os.Args[1])
deviceBin := fmt.Sprintf("%s/%s-%d", deviceGotmp, binName, os.Getpid())
// The push of the binary happens in parallel with other tests.
// Unfortunately, a simultaneous call to adb shell hold open
// file descriptors, so it is necessary to push then move to
// avoid a "text file busy" error on execution.
// https://code.google.com/p/android/issues/detail?id=65857
run("push", os.Args[1], deviceBin+"-tmp")
run("shell", "cp '"+deviceBin+"-tmp' '"+deviceBin+"'")
run("shell", "rm '"+deviceBin+"-tmp'")
// The adb shell command will return an exit code of 0 regardless
// of the command run. E.g.
// $ adb shell false
// $ echo $?
// 0
// https://code.google.com/p/android/issues/detail?id=3254
// So we append the exitcode to the output and parse it from there.
const exitstr = "exitcode="
cmd := `export TMPDIR="` + deviceGotmp + `"` +
`; export GOROOT="` + deviceGoroot + `"` +
`; export GOPATH="` + deviceGopath + `"` +
`; cd "` + deviceCwd + `"` +
"; '" + deviceBin + "' " + strings.Join(os.Args[2:], " ") +
"; echo -n " + exitstr + "$?"
output := run("shell", cmd)
run("shell", "rm", "-rf", deviceGotmp) // Clean up.
output = output[strings.LastIndex(output, "\n")+1:]
if !strings.HasPrefix(output, exitstr) {
log.Fatalf("no exit code: %q", output)
}
code, err := strconv.Atoi(output[len(exitstr):])
if err != nil {
log.Fatalf("bad exit code: %v", err)
}
os.Exit(code)
}
// subdir determines the package based on the current working directory,
// and returns the path to the package source relative to $GOROOT (or $GOPATH).
func subdir() (pkgpath string, underGoRoot bool) {
cwd, err := os.Getwd()
if err != nil {
log.Fatal(err)
}
if root := runtime.GOROOT(); strings.HasPrefix(cwd, root) {
subdir, err := filepath.Rel(root, cwd)
if err != nil {
log.Fatal(err)
}
return subdir, true
}
for _, p := range filepath.SplitList(build.Default.GOPATH) {
if !strings.HasPrefix(cwd, p) {
continue
}
subdir, err := filepath.Rel(p, cwd)
if err == nil {
return subdir, false
}
}
log.Fatalf("the current path %q is not in either GOROOT(%q) or GOPATH(%q)",
cwd, runtime.GOROOT(), build.Default.GOPATH)
return "", false
}

237
misc/bash/go Normal file
View File

@@ -0,0 +1,237 @@
# install in /etc/bash_completion.d/ or your personal directory
complete -f -X '!*.8' 8l
complete -f -X '!*.6' 6l
complete -f -X '!*.5' 5l
complete -f -X '!*.go' 8g 6g 5g gofmt gccgo
_go_importpath()
{
echo "$(compgen -W "$(go list all) all std" -- "$1")"
}
_go()
{
# TODO: Only allow flags before other arguments. run already does
# this.
local cur=`_get_cword`
local prev="${COMP_WORDS[COMP_CWORD-1]}"
local cmd="${COMP_WORDS[1]}"
local cmds="build clean env fix fmt get
install list run test tool version vet"
local addhelp="c gopath importpath packages testflag testfunc"
local other="help"
if [ "$COMP_CWORD" == 1 ]; then
for opt in $cmds; do
if [[ "$opt" == "$cmd" ]]; then
COMPREPLY=("$opt")
return
fi
done
fi
case "$cmd" in
'build')
case "$prev" in
'-o')
_filedir
;;
'-p')
;;
*)
if [[ "$cur" == -* ]]; then
COMPREPLY=($(compgen -W "-a -n -o -p -v -x" -- "$cur"))
else
local found=0
for ((i=0; i < ${#COMP_WORDS[@]}; i++)); do
case "$i" in
0|1|"$COMP_CWORD")
continue
;;
esac
local opt="${COMP_WORDS[i]}"
if [[ "$opt" != -* ]]; then
if [[ "$opt" == *.go && -f "$opt" ]]; then
found=1
break
else
found=2
break
fi
fi
done
case "$found" in
0)
_filedir go
COMPREPLY+=(`_go_importpath "$cur"`)
;;
1)
_filedir go
;;
2)
COMPREPLY=(`_go_importpath "$cur"`)
;;
esac
fi
;;
esac
;;
'clean')
if [[ "$cur" == -* ]]; then
COMPREPLY=($(compgen -W "-i -r -n -x" -- "$cur"))
else
COMPREPLY=(`_go_importpath "$cur"`)
fi
;;
'fix')
COMPREPLY=(`_go_importpath "$cur"`)
;;
'fmt')
COMPREPLY=(`_go_importpath "$cur"`)
;;
'get')
case "$prev" in
'-p')
;;
*)
if [[ "$cur" == -* ]]; then
COMPREPLY=($(compgen -W "-a -d -fix -n -p -u -v -x" -- "$cur"))
else
COMPREPLY=(`_go_importpath "$cur"`)
fi
;;
esac
;;
'install')
case "$prev" in
'-p')
;;
*)
if [[ "$cur" == -* ]]; then
COMPREPLY=($(compgen -W "-a -n -p -v -x" -- "$cur"))
else
COMPREPLY=(`_go_importpath "$cur"`)
fi
;;
esac
;;
'list')
case "$prev" in
'-f')
;;
*)
if [[ "$cur" == -* ]]; then
COMPREPLY=($(compgen -W "-e -f -json" -- "$cur"))
else
COMPREPLY=(`_go_importpath "$cur"`)
fi
;;
esac
;;
'run')
if [[ "$cur" == -* && "$prev" != *.go ]]; then
COMPREPLY=($(compgen -W "-a -n -x" -- "$cur"))
else
_filedir
fi
;;
'test') # TODO: Support for testflags.
case "$prev" in
'-file')
_filedir go
;;
'-p')
;;
*)
if [[ "$cur" == -* ]]; then
COMPREPLY=($(compgen -W "-c -file -i -p -x" -- "$cur"))
else
COMPREPLY=(`_go_importpath "$cur"`)
fi
;;
esac
;;
'tool')
if [ "$COMP_CWORD" == 2 ]; then
COMPREPLY=($(compgen -W "$(go tool)" -- "$cur"))
else
case "${COMP_WORDS[2]}" in
[568]a) # TODO: Implement something.
#_go_tool_568a
;;
[568]c) # TODO: Implement something.
#_go_tool_568c
;;
[568]g) # TODO: Implement something.
#_go_tool_568g
;;
[568]l) # TODO: Implement something.
#_go_tool_568l
;;
'api') # TODO: Implement something.
#_go_tool_api
;;
'cgo') # TODO: Implement something.
#_go_tool_cgo
;;
'cov') # TODO: Implement something.
#_go_tool_cov
;;
'dist') # TODO: Implement something.
#_go_tool_dist
;;
'fix') # TODO: Implement something.
#_go_tool_fix
;;
'nm') # TODO: Implement something.
#_go_tool_nm
;;
'pack') # TODO: Implement something.
#_go_tool_pack
;;
'pprof') # TODO: Implement something.
#_go_tool_pprof
;;
'vet') # TODO: Implement something.
#_go_tool_vet
;;
'yacc') # TODO: Implement something.
#_go_tool_yacc
;;
esac
if [[ "$cur" == -* ]]; then
COMPREPLY=($(compgen -W "${COMPREPLY[*]} -h" -- "$cur"))
fi
fi
;;
'version')
;;
'vet')
if [[ "$cur" == -* ]]; then
:
else
COMPREPLY=(`_go_importpath "$cur"`)
fi
;;
'help')
if [ "$COMP_CWORD" == 2 ]; then
COMPREPLY=($(compgen -W "$cmds $addhelp" -- "$cur"))
fi
;;
*)
if [ "$COMP_CWORD" == 1 ]; then
COMPREPLY=($(compgen -W "$cmds $other" -- "$cur"))
else
_filedir
fi
;;
esac
}
complete $filenames -F _go go
# vim:ts=2 sw=2 et syn=sh

104
misc/bbedit/Go.plist Normal file
View File

@@ -0,0 +1,104 @@
// Copyright 2009 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
{
BBEditDocumentType = "CodelessLanguageModule";
BBLMColorsSyntax = YES;
BBLMIsCaseSensitive = YES;
BBLMKeywordList = (
append,
bool,
break,
byte,
cap,
case,
chan,
close,
complex,
complex128,
complex64,
const,
continue,
copy,
default,
defer,
delete,
else,
error,
fallthrough,
false,
float32,
float64,
for,
func,
go,
goto,
if,
iota,
imag,
import,
int,
int16,
int32,
int64,
int8,
interface,
len,
make,
map,
new,
nil,
package,
panic,
print,
println,
range,
real,
recover,
return,
rune,
select,
string,
struct,
switch,
true,
type,
uint,
uint16,
uint32,
uint64,
uint8,
uintptr,
var,
);
BBLMLanguageCode = go;
"BBLMLanguageDisplayName" = "Go";
BBLMScansFunctions = YES;
BBLMSuffixMap = (
{
BBLMLanguageSuffix = ".go";
},
);
"Language Features" = {
"Close Block Comments" = "*/";
"Close Parameter Lists" = ")";
"Close Statement Blocks" = "}";
"Close Strings 1" = "`";
"Close Strings 2" = "\"";
"End-of-line Ends Strings 1" = YES;
"End-of-line Ends Strings 2" = YES;
"Escape Char in Strings 1" = "\\";
"Escape Char in Strings 2" = "\\";
"Identifier and Keyword Characters" = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz";
"Open Block Comments" = "/*";
"Open Line Comments" = "//";
"Open Parameter Lists" = "(";
"Open Statement Blocks" = "{";
"Open Strings 1" = "`";
"Open Strings 2" = "\"";
"Prefix for Functions" = "func";
"Prefix for Procedures" = "func";
"Terminator for Prototypes 1" = ";";
"Terminator for Prototypes 2" = "";
};
}

View File

@@ -1,5 +1,5 @@
#!/bin/bash
echo 'misc/benchcmp has moved:' >&2
echo ' go get -u golang.org/x/tools/cmd/benchcmp' >&2
echo ' go get -u code.google.com/p/go.tools/cmd/benchcmp' >&2
exit 2

View File

@@ -1,14 +0,0 @@
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package main
/*
void foo() {}
*/
import "C"
func main() {
C.foo = C.foo // ERROR HERE
}

View File

@@ -1,17 +0,0 @@
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package main
// Issue 8442. Cgo output unhelpful error messages for
// invalid C preambles.
/*
void issue8442foo(UNDEF*); // ERROR HERE
*/
import "C"
func main() {
C.issue8442foo(nil)
}

View File

@@ -27,8 +27,6 @@ check() {
check err1.go
check err2.go
check err3.go
check issue7757.go
check issue8442.go
rm -rf errs _obj
exit 0

View File

@@ -1,11 +0,0 @@
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package cgotest
import _ "unsafe"
//go:linkname lockedOSThread runtime.lockedOSThread
//extern runtime_lockedOSThread
func lockedOSThread() bool

View File

@@ -0,0 +1,8 @@
// Copyright 2012 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package backdoor
func LockedOSThread() bool // in runtime.c
func Issue7695(x1, x2, x3, x4, x5, x6, x7, x8 uintptr)

View File

@@ -0,0 +1,11 @@
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// This is the gccgo version of the stub in runtime.c.
// +build gccgo
package backdoor
func Issue7695(x1, x2, x3, x4, x5, x6, x7, x8 uintptr) {}

View File

@@ -0,0 +1,32 @@
// Copyright 2011 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// Expose some runtime functions for testing.
// Must be in a non-cgo-using package so that
// the go command compiles this file with 6c, not gcc.
// +build gc
typedef char bool;
bool runtime·lockedOSThread(void);
static void
FLUSH(void*)
{
}
void
·LockedOSThread(bool b)
{
b = runtime·lockedOSThread();
FLUSH(&b);
}
// This is what a cgo-compiled stub declaration looks like.
void
·Issue7695(struct{void *y[8*sizeof(void*)];}p)
{
USED(p);
}

View File

@@ -0,0 +1,18 @@
// Copyright 2012 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// Expose some runtime functions for testing.
// This is the gccgo version of runtime.c.
// +build gccgo
_Bool runtime_lockedOSThread(void);
_Bool LockedOSThread(void) asm(GOPKGPATH ".LockedOSThread");
_Bool
LockedOSThread(void)
{
return runtime_lockedOSThread();
}

View File

@@ -157,8 +157,3 @@ func testUnsignedInt(t *testing.T) {
t.Errorf("Incorrect unsigned int - got %x, want %x", a, b)
}
}
// Static (build-time) test that syntax traversal visits all operands of s[i:j:k].
func sliceOperands(array [2000]int) {
_ = array[C.KILO:C.KILO:C.KILO] // no type error
}

View File

@@ -1,77 +0,0 @@
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package cgotest
// Test that we have no more than one build ID. In the past we used
// to generate a separate build ID for each package using cgo, and the
// linker concatenated them all. We don't want that--we only want
// one.
import (
"bytes"
"debug/elf"
"os"
"testing"
)
func testBuildID(t *testing.T) {
f, err := elf.Open("/proc/self/exe")
if err != nil {
if os.IsNotExist(err) {
t.Skip("no /proc/self/exe")
}
t.Fatalf("opening /proc/self/exe: ", err)
}
defer f.Close()
c := 0
for i, s := range f.Sections {
if s.Type != elf.SHT_NOTE {
continue
}
d, err := s.Data()
if err != nil {
t.Logf("reading data of note section %d: %v", i, err)
continue
}
for len(d) > 0 {
// ELF standards differ as to the sizes in
// note sections. Both the GNU linker and
// gold always generate 32-bit sizes, so that
// is what we assume here.
if len(d) < 12 {
t.Logf("note section %d too short (%d < 12)", i, len(d))
continue
}
namesz := f.ByteOrder.Uint32(d)
descsz := f.ByteOrder.Uint32(d[4:])
typ := f.ByteOrder.Uint32(d[8:])
an := (namesz + 3) &^ 3
ad := (descsz + 3) &^ 3
if int(12+an+ad) > len(d) {
t.Logf("note section %d too short for header (%d < 12 + align(%d,4) + align(%d,4))", i, len(d), namesz, descsz)
continue
}
// 3 == NT_GNU_BUILD_ID
if typ == 3 && namesz == 4 && bytes.Equal(d[12:16], []byte("GNU\000")) {
c++
}
d = d[12+an+ad:]
}
}
if c > 1 {
t.Errorf("found %d build ID notes", c)
}
}

View File

@@ -9,15 +9,11 @@ void callback(void *f);
void callGoFoo(void);
void callGoStackCheck(void);
void callPanic(void);
void callCgoAllocate(void);
int callGoReturnVal(void);
int returnAfterGrow(void);
int returnAfterGrowFromGo(void);
*/
import "C"
import (
"os"
"./backdoor"
"path"
"runtime"
"strings"
@@ -49,6 +45,8 @@ func testCallbackGC(t *testing.T) {
nestedCall(runtime.GC)
}
var lockedOSThread = backdoor.LockedOSThread
func testCallbackPanic(t *testing.T) {
// Make sure panic during callback unwinds properly.
if lockedOSThread() {
@@ -154,13 +152,11 @@ func testCallbackCallers(t *testing.T) {
n := 0
name := []string{
"test.goCallback",
"runtime.call16",
"runtime.cgocallbackg1",
"runtime.cgocallbackg",
"runtime.cgocallback_gofunc",
"asmcgocall",
"runtime.asmcgocall_errno",
"runtime.cgocall_errno",
"runtime.asmcgocall",
"runtime.cgocall",
"test._Cfunc_callback",
"test.nestedCall",
"test.testCallbackCallers",
@@ -168,9 +164,6 @@ func testCallbackCallers(t *testing.T) {
"testing.tRunner",
"runtime.goexit",
}
if unsafe.Sizeof((*byte)(nil)) == 8 {
name[1] = "runtime.call32"
}
nestedCall(func() {
n = runtime.Callers(2, pc)
})
@@ -188,12 +181,8 @@ func testCallbackCallers(t *testing.T) {
if strings.HasPrefix(fname, "_") {
fname = path.Base(f.Name()[1:])
}
namei := ""
if i < len(name) {
namei = name[i]
}
if fname != namei {
t.Errorf("stk[%d] = %q, want %q", i, fname, namei)
if fname != name[i] {
t.Errorf("expected function name %s, got %s", name[i], fname)
}
}
}
@@ -211,65 +200,6 @@ func testPanicFromC(t *testing.T) {
C.callPanic()
}
func testAllocateFromC(t *testing.T) {
if strings.Contains(os.Getenv("GODEBUG"), "wbshadow=") {
// This test is writing pointers to Go heap objects from C.
// As such, those writes have no write barriers, and
// wbshadow=2 mode correctly discovers that and crashes.
// Disable test if any wbshadow mode is enabled.
// TODO(rsc): I am not sure whether the test is fundamentally
// incompatible with concurrent collection and should be
// turned off or rewritten entirely. The test is attempting to
// mimic some SWIG behavior, so it is important to work
// through what we expect before trying SWIG and C++
// with the concurrent collector.
t.Skip("test is incompatible with wbshadow=")
}
C.callCgoAllocate() // crashes or exits on failure
}
// Test that C code can return a value if it calls a Go function that
// causes a stack copy.
func testReturnAfterGrow(t *testing.T) {
// Use a new goroutine so that we get a small stack.
c := make(chan int)
go func() {
c <- int(C.returnAfterGrow())
}()
if got, want := <-c, 123456; got != want {
t.Errorf("got %d want %d", got, want)
}
}
// Test that we can return a value from Go->C->Go if the Go code
// causes a stack copy.
func testReturnAfterGrowFromGo(t *testing.T) {
// Use a new goroutine so that we get a small stack.
c := make(chan int)
go func() {
c <- int(C.returnAfterGrowFromGo())
}()
if got, want := <-c, 129*128/2; got != want {
t.Errorf("got %d want %d", got, want)
}
}
//export goReturnVal
func goReturnVal() (r C.int) {
// Force a stack copy.
var f func(int) int
f = func(i int) int {
var buf [256]byte
use(buf[:])
if i == 0 {
return 0
}
return i + f(i-1)
}
r = C.int(f(128))
return
}
func testCallbackStack(t *testing.T) {
// Make cgo call and callback with different amount of stack stack available.
// We do not do any explicit checks, just ensure that it does not crash.

View File

@@ -64,19 +64,3 @@ callGoStackCheck(void)
extern void goStackCheck(void);
goStackCheck();
}
int
returnAfterGrow(void)
{
extern int goReturnVal(void);
goReturnVal();
return 123456;
}
int
returnAfterGrowFromGo(void)
{
extern int goReturnVal(void);
return goReturnVal();
}

View File

@@ -5,15 +5,11 @@
// +build gc
#include "_cgo_export.h"
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
/* Test calling panic from C. This is what SWIG does. */
extern void crosscall2(void (*fn)(void *, int), void *, int);
extern void _cgo_panic(void *, int);
extern void _cgo_allocate(void *, int);
void
callPanic(void)
@@ -23,58 +19,3 @@ callPanic(void)
crosscall2(_cgo_panic, &a, sizeof a);
*(int*)1 = 1;
}
/* Test calling cgo_allocate from C. This is what SWIG does. */
typedef struct List List;
struct List
{
List *next;
int x;
};
void
callCgoAllocate(void)
{
int i;
struct { size_t n; void *ret; } a;
List *l, *head, **tail;
// Make sure this doesn't crash.
// And make sure it returns non-nil.
a.n = 0;
a.ret = 0;
crosscall2(_cgo_allocate, &a, sizeof a);
if(a.ret == 0) {
fprintf(stderr, "callCgoAllocate: alloc 0 returned nil\n");
exit(2);
}
head = 0;
tail = &head;
for(i=0; i<100; i++) {
a.n = sizeof *l;
crosscall2(_cgo_allocate, &a, sizeof a);
l = a.ret;
l->x = i;
l->next = 0;
*tail = l;
tail = &l->next;
}
gc();
l = head;
for(i=0; i<100; i++) {
if(l->x != i) {
fprintf(stderr, "callCgoAllocate: lost memory\n");
exit(2);
}
l = l->next;
}
if(l != 0) {
fprintf(stderr, "callCgoAllocate: lost memory\n");
exit(2);
}
}

View File

@@ -5,66 +5,13 @@
// +build gccgo
#include "_cgo_export.h"
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
/* Test calling panic from C. This is what SWIG does. */
extern void _cgo_panic(const char *);
extern void *_cgo_allocate(size_t);
void
callPanic(void)
{
_cgo_panic("panic from C");
}
/* Test calling cgo_allocate from C. This is what SWIG does. */
typedef struct List List;
struct List
{
List *next;
int x;
};
void
callCgoAllocate(void)
{
int i;
List *l, *head, **tail;
// Make sure this doesn't crash.
// And make sure it returns non-nil.
if(_cgo_allocate(0) == 0) {
fprintf(stderr, "callCgoAllocate: alloc 0 returned nil\n");
exit(2);
}
head = 0;
tail = &head;
for(i=0; i<100; i++) {
l = _cgo_allocate(sizeof *l);
l->x = i;
l->next = 0;
*tail = l;
tail = &l->next;
}
gc();
l = head;
for(i=0; i<100; i++) {
if(l->x != i) {
fprintf(stderr, "callCgoAllocate: lost memory\n");
exit(2);
}
l = l->next;
}
if(l != 0) {
fprintf(stderr, "callCgoAllocate: lost memory\n");
exit(2);
}
}

View File

@@ -4,7 +4,7 @@
// Test that the #cgo CFLAGS directive works,
// with and without platform filters.
// See http://golang.org/issue/5224 for details.
// See http://code.google.com/p/go/issues/detail?id=5224 for details.
package cgotest
/*

View File

@@ -6,7 +6,5 @@ package cgotest
import "testing"
func TestSetgid(t *testing.T) { testSetgid(t) }
func Test6997(t *testing.T) { test6997(t) }
func TestBuildID(t *testing.T) { testBuildID(t) }
func Test9400(t *testing.T) { test9400(t) }
func TestSetgid(t *testing.T) { testSetgid(t) }
func Test6997(t *testing.T) { test6997(t) }

View File

@@ -10,59 +10,48 @@ import "testing"
// so that they can use cgo (import "C").
// These wrappers are here for gotest to find.
func TestAlign(t *testing.T) { testAlign(t) }
func TestConst(t *testing.T) { testConst(t) }
func TestEnum(t *testing.T) { testEnum(t) }
func TestAtol(t *testing.T) { testAtol(t) }
func TestErrno(t *testing.T) { testErrno(t) }
func TestMultipleAssign(t *testing.T) { testMultipleAssign(t) }
func TestUnsignedInt(t *testing.T) { testUnsignedInt(t) }
func TestCallback(t *testing.T) { testCallback(t) }
func TestCallbackGC(t *testing.T) { testCallbackGC(t) }
func TestCallbackPanic(t *testing.T) { testCallbackPanic(t) }
func TestCallbackPanicLoop(t *testing.T) { testCallbackPanicLoop(t) }
func TestCallbackPanicLocked(t *testing.T) { testCallbackPanicLocked(t) }
func TestPanicFromC(t *testing.T) { testPanicFromC(t) }
func TestAllocateFromC(t *testing.T) { testAllocateFromC(t) }
func TestZeroArgCallback(t *testing.T) { testZeroArgCallback(t) }
func TestBlocking(t *testing.T) { testBlocking(t) }
func Test1328(t *testing.T) { test1328(t) }
func TestParallelSleep(t *testing.T) { testParallelSleep(t) }
func TestSetEnv(t *testing.T) { testSetEnv(t) }
func TestHelpers(t *testing.T) { testHelpers(t) }
func TestLibgcc(t *testing.T) { testLibgcc(t) }
func Test1635(t *testing.T) { test1635(t) }
func TestPrintf(t *testing.T) { testPrintf(t) }
func Test4029(t *testing.T) { test4029(t) }
func TestBoolAlign(t *testing.T) { testBoolAlign(t) }
func Test3729(t *testing.T) { test3729(t) }
func Test3775(t *testing.T) { test3775(t) }
func TestCthread(t *testing.T) { testCthread(t) }
func TestCallbackCallers(t *testing.T) { testCallbackCallers(t) }
func Test5227(t *testing.T) { test5227(t) }
func TestCflags(t *testing.T) { testCflags(t) }
func Test5337(t *testing.T) { test5337(t) }
func Test5548(t *testing.T) { test5548(t) }
func Test5603(t *testing.T) { test5603(t) }
func Test6833(t *testing.T) { test6833(t) }
func Test3250(t *testing.T) { test3250(t) }
func TestCallbackStack(t *testing.T) { testCallbackStack(t) }
func TestFpVar(t *testing.T) { testFpVar(t) }
func Test4339(t *testing.T) { test4339(t) }
func Test6390(t *testing.T) { test6390(t) }
func Test5986(t *testing.T) { test5986(t) }
func Test7665(t *testing.T) { test7665(t) }
func TestNaming(t *testing.T) { testNaming(t) }
func Test7560(t *testing.T) { test7560(t) }
func Test5242(t *testing.T) { test5242(t) }
func Test8092(t *testing.T) { test8092(t) }
func Test7978(t *testing.T) { test7978(t) }
func Test8694(t *testing.T) { test8694(t) }
func Test8517(t *testing.T) { test8517(t) }
func Test8811(t *testing.T) { test8811(t) }
func TestReturnAfterGrow(t *testing.T) { testReturnAfterGrow(t) }
func TestReturnAfterGrowFromGo(t *testing.T) { testReturnAfterGrowFromGo(t) }
func Test9026(t *testing.T) { test9026(t) }
func Test9557(t *testing.T) { test9557(t) }
func TestAlign(t *testing.T) { testAlign(t) }
func TestConst(t *testing.T) { testConst(t) }
func TestEnum(t *testing.T) { testEnum(t) }
func TestAtol(t *testing.T) { testAtol(t) }
func TestErrno(t *testing.T) { testErrno(t) }
func TestMultipleAssign(t *testing.T) { testMultipleAssign(t) }
func TestUnsignedInt(t *testing.T) { testUnsignedInt(t) }
func TestCallback(t *testing.T) { testCallback(t) }
func TestCallbackGC(t *testing.T) { testCallbackGC(t) }
func TestCallbackPanic(t *testing.T) { testCallbackPanic(t) }
func TestCallbackPanicLoop(t *testing.T) { testCallbackPanicLoop(t) }
func TestCallbackPanicLocked(t *testing.T) { testCallbackPanicLocked(t) }
func TestPanicFromC(t *testing.T) { testPanicFromC(t) }
func TestZeroArgCallback(t *testing.T) { testZeroArgCallback(t) }
func TestBlocking(t *testing.T) { testBlocking(t) }
func Test1328(t *testing.T) { test1328(t) }
func TestParallelSleep(t *testing.T) { testParallelSleep(t) }
func TestSetEnv(t *testing.T) { testSetEnv(t) }
func TestHelpers(t *testing.T) { testHelpers(t) }
func TestLibgcc(t *testing.T) { testLibgcc(t) }
func Test1635(t *testing.T) { test1635(t) }
func TestPrintf(t *testing.T) { testPrintf(t) }
func Test4029(t *testing.T) { test4029(t) }
func TestBoolAlign(t *testing.T) { testBoolAlign(t) }
func Test3729(t *testing.T) { test3729(t) }
func Test3775(t *testing.T) { test3775(t) }
func TestCthread(t *testing.T) { testCthread(t) }
func TestCallbackCallers(t *testing.T) { testCallbackCallers(t) }
func Test5227(t *testing.T) { test5227(t) }
func TestCflags(t *testing.T) { testCflags(t) }
func Test5337(t *testing.T) { test5337(t) }
func Test5548(t *testing.T) { test5548(t) }
func Test5603(t *testing.T) { test5603(t) }
func Test6833(t *testing.T) { test6833(t) }
func Test3250(t *testing.T) { test3250(t) }
func TestCallbackStack(t *testing.T) { testCallbackStack(t) }
func TestFpVar(t *testing.T) { testFpVar(t) }
func Test4339(t *testing.T) { test4339(t) }
func Test6390(t *testing.T) { test6390(t) }
func Test5986(t *testing.T) { test5986(t) }
func Test7665(t *testing.T) { test7665(t) }
func TestNaming(t *testing.T) { testNaming(t) }
func Test7560(t *testing.T) { test7560(t) }
func BenchmarkCgoCall(b *testing.B) { benchCgoCall(b) }

View File

@@ -5,14 +5,8 @@
package cgotest
import "C"
import "runtime"
//export ReturnIntLong
func ReturnIntLong() (int, C.long) {
return 1, 2
}
//export gc
func gc() {
runtime.GC()
}

View File

@@ -1,31 +0,0 @@
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// Issue 5242. Cgo incorrectly computed the alignment of structs
// with no Go accessible fields as 0, and then panicked on
// modulo-by-zero computations.
package cgotest
/*
typedef struct {
} foo;
typedef struct {
int x : 1;
} bar;
int issue5242(foo f, bar b) {
return 5242;
}
*/
import "C"
import "testing"
func test5242(t *testing.T) {
if got := C.issue5242(C.foo{}, C.bar{}); got != 5242 {
t.Errorf("got %v", got)
}
}

View File

@@ -14,14 +14,13 @@ import "C"
//export issue5548FromC
func issue5548FromC(s string, i int) int {
if len(s) == 4 && s == "test" && i == 42 {
return 12345
return 1
}
println("got", len(s), i)
return 9876
return 0
}
func test5548(t *testing.T) {
if x := C.issue5548_in_c(); x != 12345 {
t.Errorf("issue5548_in_c = %d, want %d", x, 12345)
if C.issue5548_in_c() == 0 {
t.Fail()
}
}

View File

@@ -34,7 +34,7 @@ func test6997(t *testing.T) {
if r == 0 {
t.Error("pthread finished but wasn't cancelled??")
}
case <-time.After(30 * time.Second):
case <-time.After(5 * time.Second):
t.Error("hung in pthread_cancel/pthread_join")
}
}

View File

@@ -14,7 +14,7 @@ import "testing"
var v7234 = [...]string{"runtime/cgo"}
func Test7234(t *testing.T) {
func TestIssue7234(t *testing.T) {
if v7234[0] != "runtime/cgo" {
t.Errorf("bad string constant %q", v7234[0])
}

View File

@@ -0,0 +1,27 @@
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// Demo of deferred C function with untrue prototype
// breaking stack copying. See golang.org/issue/7695.
package cgotest
import (
"testing"
"./backdoor"
)
func TestIssue7695(t *testing.T) {
defer backdoor.Issue7695(1, 0, 2, 0, 0, 3, 0, 4)
recurse(100)
}
func recurse(n int) {
var x [128]int
n += x[0]
if n > 0 {
recurse(n - 1)
}
}

View File

@@ -1,124 +0,0 @@
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// Issue 7978. Stack tracing didn't work during cgo code after calling a Go
// callback. Make sure GC works and the stack trace is correct.
package cgotest
/*
#include <stdint.h>
void issue7978cb(void);
#if defined(__APPLE__) && defined(__arm__)
// on Darwin/ARM, libSystem doesn't provide implementation of the __sync_fetch_and_add
// primitive, and although gcc supports it, it doesn't inline its definition.
// Clang could inline its definition, so we require clang on Darwin/ARM.
#if defined(__clang__)
#define HAS_SYNC_FETCH_AND_ADD 1
#else
#define HAS_SYNC_FETCH_AND_ADD 0
#endif
#else
#define HAS_SYNC_FETCH_AND_ADD 1
#endif
// use ugly atomic variable sync since that doesn't require calling back into
// Go code or OS dependencies
static void issue7978c(uint32_t *sync) {
#if HAS_SYNC_FETCH_AND_ADD
while(__sync_fetch_and_add(sync, 0) != 0)
;
__sync_fetch_and_add(sync, 1);
while(__sync_fetch_and_add(sync, 0) != 2)
;
issue7978cb();
__sync_fetch_and_add(sync, 1);
while(__sync_fetch_and_add(sync, 0) != 6)
;
#endif
}
*/
import "C"
import (
"os"
"runtime"
"strings"
"sync/atomic"
"testing"
)
var issue7978sync uint32
func issue7978check(t *testing.T, wantFunc string, badFunc string, depth int) {
runtime.GC()
buf := make([]byte, 65536)
trace := string(buf[:runtime.Stack(buf, true)])
for _, goroutine := range strings.Split(trace, "\n\n") {
if strings.Contains(goroutine, "test.issue7978go") {
trace := strings.Split(goroutine, "\n")
// look for the expected function in the stack
for i := 0; i < depth; i++ {
if badFunc != "" && strings.Contains(trace[1+2*i], badFunc) {
t.Errorf("bad stack: found %s in the stack:\n%s", badFunc, goroutine)
return
}
if strings.Contains(trace[1+2*i], wantFunc) {
return
}
}
t.Errorf("bad stack: didn't find %s in the stack:\n%s", wantFunc, goroutine)
return
}
}
t.Errorf("bad stack: goroutine not found. Full stack dump:\n%s", trace)
}
func issue7978wait(store uint32, wait uint32) {
if store != 0 {
atomic.StoreUint32(&issue7978sync, store)
}
for atomic.LoadUint32(&issue7978sync) != wait {
runtime.Gosched()
}
}
//export issue7978cb
func issue7978cb() {
issue7978wait(3, 4)
}
func issue7978go() {
C.issue7978c((*C.uint32_t)(&issue7978sync))
issue7978wait(7, 8)
}
func test7978(t *testing.T) {
if runtime.Compiler == "gccgo" {
t.Skip("gccgo can not do stack traces of C code")
}
if C.HAS_SYNC_FETCH_AND_ADD == 0 {
t.Skip("clang required for __sync_fetch_and_add support on darwin/arm")
}
if os.Getenv("GOTRACEBACK") != "2" {
t.Fatalf("GOTRACEBACK must be 2")
}
issue7978sync = 0
go issue7978go()
// test in c code, before callback
issue7978wait(0, 1)
issue7978check(t, "runtime.cgocall_errno(", "", 1)
// test in go code, during callback
issue7978wait(2, 3)
issue7978check(t, "test.issue7978cb(", "test.issue7978go", 3)
// test in c code, after callback
issue7978wait(4, 5)
issue7978check(t, "runtime.cgocall_errno(", "runtime.cgocallback", 1)
// test in go code, after return from cgo
issue7978wait(6, 7)
issue7978check(t, "test.issue7978go(", "", 3)
atomic.StoreUint32(&issue7978sync, 8)
}

View File

@@ -1,36 +0,0 @@
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// Issue 8092. Test that linker defined symbols (e.g., text, data) don't
// conflict with C symbols.
package cgotest
/*
char text[] = "text";
char data[] = "data";
char *ctext(void) { return text; }
char *cdata(void) { return data; }
*/
import "C"
import "testing"
func test8092(t *testing.T) {
tests := []struct {
s string
a, b *C.char
}{
{"text", &C.text[0], C.ctext()},
{"data", &C.data[0], C.cdata()},
}
for _, test := range tests {
if test.a != test.b {
t.Errorf("%s: pointer mismatch: %v != %v", test.s, test.a, test.b)
}
if got := C.GoString(test.a); got != test.s {
t.Errorf("%s: points at %#v, want %#v", test.s, got, test.s)
}
}
}

View File

@@ -1,52 +0,0 @@
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// This test fails on older versions of OS X because they use older buggy
// versions of Clang that emit ambiguous DWARF info. See issue 8611.
// +build !darwin
package cgotest
// Issue 8428. Cgo inconsistently translated zero size arrays.
/*
struct issue8428one {
char b;
char rest[];
};
struct issue8428two {
void *p;
char b;
char rest[0];
};
struct issue8428three {
char w[1][2][3][0];
char x[2][3][0][1];
char y[3][0][1][2];
char z[0][1][2][3];
};
*/
import "C"
import "unsafe"
var _ = C.struct_issue8428one{
b: C.char(0),
rest: [0]C.char{},
}
var _ = C.struct_issue8428two{
p: unsafe.Pointer(nil),
b: C.char(0),
rest: [0]C.char{},
}
var _ = C.struct_issue8428three{
w: [1][2][3][0]C.char{},
x: [2][3][0][1]C.char{},
y: [3][0][1][2]C.char{},
z: [0][1][2][3]C.char{},
}

View File

@@ -1,27 +0,0 @@
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// Issue 8368 and 8441. Recursive struct definitions didn't work.
// No runtime test; just make sure it compiles.
package cgotest
/*
typedef struct one one;
typedef struct two two;
struct one {
two *x;
};
struct two {
one *x;
};
*/
import "C"
func issue8368(one *C.struct_one, two *C.struct_two) {
}
func issue8441(one *C.one, two *C.two) {
issue8441(two.x, one.x)
}

View File

@@ -1,13 +0,0 @@
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// +build !windows
package cgotest
import "testing"
func test8517(t *testing.T) {
t.Skip("skipping windows only test")
}

View File

@@ -1,24 +0,0 @@
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
#include "windows.h"
extern void testHandleLeaksCallback();
DWORD WINAPI testHandleLeaksFunc(LPVOID lpThreadParameter)
{
int i;
for(i = 0; i < 100; i++) {
testHandleLeaksCallback();
}
return 0;
}
void testHandleLeaks()
{
HANDLE h;
h = CreateThread(NULL, 0, &testHandleLeaksFunc, 0, 0, NULL);
WaitForSingleObject(h, INFINITE);
CloseHandle(h);
}

View File

@@ -1,45 +0,0 @@
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package cgotest
//void testHandleLeaks();
import "C"
import (
"syscall"
"testing"
"unsafe"
)
var issue8517counter int
var (
kernel32 = syscall.MustLoadDLL("kernel32.dll")
getProcessHandleCount = kernel32.MustFindProc("GetProcessHandleCount")
)
func processHandleCount(t *testing.T) int {
const current_process = ^uintptr(0)
var c uint32
r, _, err := getProcessHandleCount.Call(current_process, uintptr(unsafe.Pointer(&c)))
if r == 0 {
t.Fatal(err)
}
return int(c)
}
func test8517(t *testing.T) {
c1 := processHandleCount(t)
C.testHandleLeaks()
c2 := processHandleCount(t)
if c1+issue8517counter <= c2 {
t.Fatalf("too many handles leaked: issue8517counter=%v c1=%v c2=%v", issue8517counter, c1, c2)
}
}
//export testHandleLeaksCallback
func testHandleLeaksCallback() {
issue8517counter++
}

View File

@@ -1,38 +0,0 @@
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package cgotest
/*
#include <complex.h>
complex float complexFloatSquared(complex float a) { return a*a; }
complex double complexDoubleSquared(complex double a) { return a*a; }
*/
import "C"
import (
"runtime"
"testing"
)
func test8694(t *testing.T) {
if runtime.GOARCH == "arm" {
t.Skip("test8694 is disabled on ARM because 5l cannot handle thumb library.")
}
// Really just testing that this compiles, but check answer anyway.
x := complex64(2 + 3i)
x2 := x * x
cx2 := C.complexFloatSquared(x)
if cx2 != x2 {
t.Errorf("C.complexFloatSquared(%v) = %v, want %v", x, cx2, x2)
}
y := complex128(2 + 3i)
y2 := y * y
cy2 := C.complexDoubleSquared(y)
if cy2 != y2 {
t.Errorf("C.complexDoubleSquared(%v) = %v, want %v", y, cy2, y2)
}
}

View File

@@ -1,8 +0,0 @@
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
int issue8811Initialized = 0;
void issue8811Init() {
}

View File

@@ -1,22 +0,0 @@
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package cgotest
/*
extern int issue8811Initialized;
extern void issue8811Init();
void issue8811Execute() {
if(!issue8811Initialized)
issue8811Init();
}
*/
import "C"
import "testing"
func test8811(t *testing.T) {
C.issue8811Execute()
}

View File

@@ -1,16 +0,0 @@
// compile
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
// Issue 8828: compiling a file with -compiler=gccgo fails if a .c file
// has the same name as compiled directory.
package cgotest
import "./issue8828"
func p() {
issue8828.Bar()
}

View File

@@ -1,7 +0,0 @@
// Copyright 2014 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
void foo()
{
}

View File

@@ -1,8 +0,0 @@
package issue8828
//void foo();
import "C"
func Bar() {
C.foo()
}

View File

@@ -1,9 +0,0 @@
package cgotest
import (
"testing"
"./issue9026"
)
func test9026(t *testing.T) { issue9026.Test(t) }

Some files were not shown because too many files have changed in this diff Show More