Skip to content

G
golang
Switch branch/tag
  1. 19 Aug, 2015 1 commit
    • Russ Cox's avatar
      doc: adjust binary install page supported system list · 54575631
      Russ Cox authored 
      Make clear that this list is the list of supported systems
for binary distributions, and that other systems may be
able to build the distribution from source, in addition
to using gccgo.

Drop freebsd/arm from the list on this page.
We have never issued a binary distribution for freebsd/arm,
and we're not going to start in Go 1.5, since we don't even
have a working builder for it.

Drop freebsd/386 from the list on the page,
because we are unable to build binary distributions, per adg.

I think the wording here should probably be revised further,
but not now.

Change-Id: Ib43b6b64f5c438bfb9aa4d3daa43393f1e33b71f
Reviewed-on: https://go-review.googlesource.com/13690Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
Reviewed-by: 's avatarRob Pike <r@golang.org>
      54575631
  3. 18 Aug, 2015 8 commits
  5. 17 Aug, 2015 2 commits
  7. 16 Aug, 2015 1 commit
    • Dave Cheney's avatar
      cmd/compile/internal/arm64: remove Reginuse check in clearfat · 467a2cb7
      Dave Cheney authored 
      Fixes golang/go#12133

CL 13630 fixed the use of a stale reg[] array in the various arch
backends which was causing the check in clearfat to pass
unconditionally on arm64.

With this check fixed, arm64 now considers REGRT1 to always be in use
as it is part of the reserved register set, see arm64/gsubr.go.

However, ppc64 does not consider REGRT1 and REGRT2 to be part of its
reserved set, so its identical clearfat check passes.

This CL removes the Reginuse check inside clearfat as REGRT1 is
guarenteed always be free on arm64.

Change-Id: I4719150d3c3378fae155b863c474529df18d4c17
Reviewed-on: https://go-review.googlesource.com/13650Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      467a2cb7
  9. 15 Aug, 2015 3 commits
  11. 12 Aug, 2015 1 commit
  13. 11 Aug, 2015 7 commits
  15. 10 Aug, 2015 2 commits
  17. 07 Aug, 2015 4 commits
  19. 06 Aug, 2015 8 commits
    • Russ Cox's avatar
      doc: do not call WaitGroup a function · 4b145d42
      Russ Cox authored 
      Fixes #12060.

Change-Id: Ie2fd10bedded1a4f4e0daa0c0c77ecd898480767
Reviewed-on: https://go-review.googlesource.com/13324Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      4b145d42
    • Austin Clements's avatar
      runtime: call goexit1 instead of goexit · ad731887
      Austin Clements authored 
      Currently, runtime.Goexit() calls goexit()—the goroutine exit stub—to
terminate the goroutine. This *mostly* works, but can cause a
"leftover stack barriers" panic if the following happens:

1. Goroutine A has a reasonably large stack.

2. The garbage collector scan phase runs and installs stack barriers
   in A's stack. The top-most stack barrier happens to fall at address X.

3. Goroutine A unwinds the stack far enough to be a candidate for
   stack shrinking, but not past X.

4. Goroutine A calls runtime.Goexit(), which calls goexit(), which
   calls goexit1().

5. The garbage collector enters mark termination.

6. Goroutine A is preempted right at the prologue of goexit1() and
   performs a stack shrink, which calls gentraceback.

gentraceback stops as soon as it sees goexit on the stack, which is
only two frames up at this point, even though there may really be many
frames above it. More to the point, the stack barrier at X is above
the goexit frame, so gentraceback never sees that stack barrier. At
the end of gentraceback, it checks that it saw all of the stack
barriers and panics because it didn't see the one at X.

The fix is simple: call goexit1, which actually implements the process
of exiting a goroutine, rather than goexit, the exit stub.

To make sure this doesn't happen again in the future, we also add an
argument to the stub prototype of goexit so you really, really have to
want to call it in order to call it. We were able to reliably
reproduce the above sequence with a fair amount of awful code inserted
at the right places in the runtime, but chose to change the goexit
prototype to ensure this wouldn't happen again rather than pollute the
runtime with ugly testing code.

Change-Id: Ifb6fb53087e09a252baddadc36eebf954468f2a8
Reviewed-on: https://go-review.googlesource.com/13323Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      ad731887
    • Russ Cox's avatar
      runtime: fix race that dropped GoSysExit events from trace · 26baed6a
      Russ Cox authored 
      This makes TestTraceStressStartStop much less flaky.
Running under stress, it changes the failure rate from
above 1/100 to under 1/50000. That very unlikely
failure happens when an unexpected GoSysExit is
written. Not sure how that happens yet, but it is much
less important.

Fixes #11953.

Change-Id: I034671936334b4f3ab733614ef239aa121d20247
Reviewed-on: https://go-review.googlesource.com/13321Reviewed-by: 's avatarDmitry Vyukov <dvyukov@google.com>
      26baed6a
    • Joe Shaw's avatar
      doc: remove duplicate -asmflags mention · 59735588
      Joe Shaw authored 
      Fixes #12053

Change-Id: Icd883b4f1ac944a8ec718c79770a8e3fc6542e3a
Reviewed-on: https://go-review.googlesource.com/13259Reviewed-by: 's avatarRuss Cox <rsc@golang.org>
      59735588
    • Russ Cox's avatar
      net/url: allow all valid host chars in RawPath · fced03a5
      Russ Cox authored 
      The old code was only allowing the chars we choose not to escape.
We sometimes prefer to escape chars that do not strictly need it.
Allowing those to be used in RawPath lets people override that
preference, which is in fact the whole point of RawPath (new in Go 1.5).

While we are here, also allow [ ] in RawPath.
This is not strictly spec-compliant, but it is what modern browers
do and what at least some people expect, and the [ ] do not cause
any ambiguity (the usual reason they would be escaped, as they are
part of the RFC gen-delims class).
The argument for allowing them now instead of waiting until Go 1.6
is that this way RawPath has one fixed meaning at the time it is
introduced, that we should not need to change or expand.

Fixes #5684.

Change-Id: If9c82a18f522d7ee1d10310a22821ada9286ee5c
Reviewed-on: https://go-review.googlesource.com/13258Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
      fced03a5
    • Russ Cox's avatar
      net/url: do not percent-encode valid host characters · e8be9a17
      Russ Cox authored 
      The code in question was added as part of allowing zone identifiers
in IPv6 literals like http://[ipv6%zone]:port/foo, in golang.org/cl/2431.

The old condition makes no sense. It refers to §3.2.1, which is the wrong section
of the RFC, it excludes all the sub-delims, which §3.2.2 (the right section)
makes clear are valid, and it allows ':', which is not actually valid,
without an explanation as to why (because we keep :port in the Host field
of the URL struct).

The new condition allows all the sub-delims, as specified in RFC 3986,
plus the additional characters [ ] : seen in IP address literals and :port suffixes,
which we also keep in the Host field.

This allows mysql://a,b,c/path to continue to parse, as it did in Go 1.4 and earlier.

This CL does not break any existing tests, suggesting the over-conservative
behavior was not intended and perhaps not realized.

It is especially important not to over-escape the host field, because
Go does not unescape the host field during parsing: it rejects any
host field containing % characters.

Fixes #12036.

Change-Id: Iccbe4985957b3dc58b6dfb5dcb5b63a51a6feefb
Reviewed-on: https://go-review.googlesource.com/13254Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
Reviewed-by: 's avatarMikio Hara <mikioh.mikioh@gmail.com>
      e8be9a17
    • Mikio Hara's avatar
      doc/go1.5.html: fix typo · 91e3b351
      Mikio Hara authored 
      Change-Id: Ic61fd38e7d2e0821c6adcaa210199a7dae8849a7
Reviewed-on: https://go-review.googlesource.com/13281Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
      91e3b351
    • Russ Cox's avatar
      net/url: restrict :port checking to [ipv6]:port form · fc22331c
      Russ Cox authored 
      Go 1.4 and earlier accepted mysql://x@y(z:123)/foo
and I don't see any compelling reason to break that.

The CL during Go 1.5 that broke this syntax was
trying to fix #11208 and was probably too aggressive.
I added a test case for #11208 to make sure that stays
fixed.

Relaxing the check did not re-break #11208 nor did
it cause any existing test to fail. I added a test for the
mysql://x@y(z:123)/foo syntax being preserved.

Fixes #12023.

Change-Id: I659d39f18c85111697732ad24b757169d69284fc
Reviewed-on: https://go-review.googlesource.com/13253Reviewed-by: 's avatarAndrew Gerrand <adg@golang.org>
Reviewed-by: 's avatarMikio Hara <mikioh.mikioh@gmail.com>
      fc22331c
  21. 05 Aug, 2015 3 commits