Skip to content

G
golang
Switch branch/tag
  1. 30 Dec, 2018 2 commits
  3. 29 Dec, 2018 4 commits
  5. 28 Dec, 2018 3 commits
  7. 27 Dec, 2018 3 commits
  9. 26 Dec, 2018 1 commit
  11. 25 Dec, 2018 1 commit
  13. 24 Dec, 2018 3 commits
  15. 22 Dec, 2018 5 commits
    • Daniel Martí's avatar
      cmd/go: add regression test for cryptic vcs errors · 97d5cb24
      Daniel Martí authored 
      On Go 1.11.x, if one ran 'go build' on a main package within a module,
while a needed vcs program like git was missing, a confusing error would
show up:

	build testmod: cannot find module for path rsc.io/quote

The error should instead point at the source of the problem, which is
the missing vcs program. Thankfully, Go 1.12 doesn't have this bug, even
though it doesn't seem like the bug was fixed directly and
intentionally.

To ensure that this particular edge case isn't broken again, add a
regression test. Piggyback on mod_vcs_missing, since it already requires
a missing vcs program and network access.

I double-checked that Go 1.11 fails this test via /usr/bin/go, which is
1.11.3 on my system:

	$ PATH=~/tip/bin go test -v -run Script/mod_vcs_missing
	[...]
	> exec /usr/bin/go build
	[stderr]
	build m: cannot find module for path launchpad.net/gocheck

Fixes #28948.

Change-Id: Iff1bcf77d9f7c11d15935cb87d6f58d7981d33d2
Reviewed-on: https://go-review.googlesource.com/c/155537
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBryan C. Mills <bcmills@google.com>
      97d5cb24
    • Josh Bleecher Snyder's avatar
      cmd/compile/internal/ssa/gen: set wasm genfile · 3a3b98fd
      Josh Bleecher Snyder authored 
      This appears to have been an oversight and/or
left over from development.

Setting the genfile means that extra sanity
checks are executed when regenerating SSA files.
They already pass.

Change-Id: Icc01ecf85020d3d51355e8bccfbc521b52371747
Reviewed-on: https://go-review.googlesource.com/c/154459
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: 's avatarKeith Randall <khr@golang.org>
      3a3b98fd
    • Keith Randall's avatar
      cmd/compile: pad zero-sized stack variables · c5414457
      Keith Randall authored 
      If someone takes a pointer to a zero-sized stack variable, it can
be incorrectly interpreted as a pointer to the next object in the
stack frame. To avoid this, add some padding after zero-sized variables.

We only need to pad if the next variable in memory (which is the
previous variable in the order in which we allocate variables to the
stack frame) has pointers. If the next variable has no pointers, it
won't hurt to have a pointer to it.

Because we allocate all pointer-containing variables before all
non-pointer-containing variables, we should only have to pad once per
frame.

Fixes #24993

Change-Id: Ife561cdfdf964fdbf69af03ae6ba97d004e6193c
Reviewed-on: https://go-review.googlesource.com/c/155698
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      c5414457
    • Keith Randall's avatar
      cmd/compile: fix line number for implicitly declared method expressions · debca779
      Keith Randall authored 
      Method expressions where the method is implicitly declared have no
line number. The Error method of the built-in error type is one such
method.  We leave the line number at the use of the method expression
in this case.

Fixes #29389

Change-Id: I29c64bb47b1a704576abf086599eb5af7b78df53
Reviewed-on: https://go-review.googlesource.com/c/155639
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
      debca779
    • Ian Lance Taylor's avatar
      cmd/cgo: don't let inserted /*line*/ become a // comment · 08477a38
      Ian Lance Taylor authored 
      Fixes #29383

Change-Id: I0fb2929863e153b96d32d851e25e536231e4ae65
Reviewed-on: https://go-review.googlesource.com/c/155638
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBryan C. Mills <bcmills@google.com>
      08477a38
  17. 21 Dec, 2018 4 commits
  19. 20 Dec, 2018 13 commits
  21. 19 Dec, 2018 1 commit
    • Michael Anthony Knyszek's avatar
      runtime: don't clear lockedExt on locked M when G exits · d0f8a751
      Michael Anthony Knyszek authored 
      When a locked M has its G exit without calling UnlockOSThread, then
lockedExt on it was getting cleared. Unfortunately, this meant that
during P handoff, if a new M was started, it might get forked (on
most OSs besides Windows) from the locked M, which could have kernel
state attached to it.

To solve this, just don't clear lockedExt. At the point where the
locked M has its G exit, it will also exit in accordance with the
LockOSThread API. So, we can safely assume that it's lockedExt state
will no longer be used. For the case of the main thread where it just
gets wedged instead of exiting, it's probably better for it to keep
the locked marker since it more accurately represents its state.

Fixed #28979.

Change-Id: I7d3d71dd65bcb873e9758086d2cbcb9a06429b0f
Reviewed-on: https://go-review.googlesource.com/c/153078
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: 's avatarAustin Clements <austin@google.com>
      d0f8a751