Skip to content

G
go
Switch branch/tag
  1. 27 Jun, 2018 1 commit
  3. 26 Jun, 2018 10 commits
  5. 25 Jun, 2018 10 commits
  7. 24 Jun, 2018 1 commit
  9. 23 Jun, 2018 1 commit
  11. 22 Jun, 2018 13 commits
  13. 21 Jun, 2018 4 commits
    • Matthew Dempsky's avatar
      cmd/compile: fix recursive inimport handling · 011ea879
      Matthew Dempsky authored 
      expandDecl can be called recursively, so it's not an appropriate place
to clean inimport. Instead, move this up to resolve, along with an
appropriate recursion check.

Passes toolstash-check.

Change-Id: I138d37b057dcc6525c780b4b3fbaa5e97f99655b
Reviewed-on: https://go-review.googlesource.com/120455
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarRobert Griesemer <gri@golang.org>
      011ea879
    • Terin Stock's avatar
      flag: add a Value example · 6c810027
      Terin Stock authored 
      Change-Id: I579cc9f4f8e5be5fd6447a99614797ab7bc53611
Reviewed-on: https://go-review.googlesource.com/120175
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      6c810027
    • Paul Jolly's avatar
      misc/wasm: fix permissions on wasm_exec.js · 4b342899
      Paul Jolly authored 
      Currently wasm_exec.js is executable (0755) yet has no interpreter.
Indeed wasm_exec.js is only ever used as an argument to Node or loaded
via a <script> tag in a browser-loaded HTML file.  Hence the execute
mode bits are superfluous and simply serve to clutter your PATH if
$GOROOT/misc/wasm is on your PATH (as is required if you want to run go
test syscall/js).

Change-Id: I279e2457094f8a12b9bf380ad7f1a9f47b22fc96
Reviewed-on: https://go-review.googlesource.com/120435
Run-TryBot: Paul Jolly <paul@myitcv.org.uk>
Reviewed-by: default avatarDaniel Martí <mvdan@mvdan.cc>
Reviewed-by: default avatarBrad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      4b342899
    • Andrei Tudor Călin's avatar
      internal/poll: use more fine-grained locking in Splice · 24fb2e01
      Andrei Tudor Călin authored 
      The previous code acquired a read lock on src and a write lock on
dst for the entire duration of Splice. This resulted in deadlock,
in a situation akin to the following:

Splice is blocking, waiting to read from src.

The caller tries to close dst from another goroutine, but Close on
dst blocks in runtime.semacquire, because Splice is still holding a
write lock on it, and the Close didn't unblock any I/O.

The caller cannot unblock the read side of Splice through other means,
because they are stuck waiting in dst.Close().

Use more fine-grained locking instead: acquire the read lock on src
just before trying to splice from the source socket to the pipe,
and acquire the write lock on dst just before trying to splice from
the pipe to the destination socket.

Fixes #25985

Change-Id: I264c91c7a69bb6c5e28610e2bd801244804cf86d
Reviewed-on: https://go-review.googlesource.com/120317
Run-TryBot: Aram Hăvărneanu <aram@mgk.ro>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: default avatarIan Lance Taylor <iant@golang.org>
      24fb2e01
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7