- 22 Dec, 2018 5 commits
-
-
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: Bryan C. Mills <bcmills@google.com>
-
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: Keith Randall <khr@golang.org>
-
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: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
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: Ian Lance Taylor <iant@golang.org>
-
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: Bryan C. Mills <bcmills@google.com>
-
- 21 Dec, 2018 4 commits
-
-
Ian Lance Taylor authored
Fixes #27808 Change-Id: Ia643d51004c47953642a2ba41dfed281f1112be6 Reviewed-on: https://go-review.googlesource.com/c/155637Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Jay Conrod authored
When "go list" is invoked with -find, it clears the list of imports for each package matched on the command line. This affects action IDs, since they incorporate dependencies' action IDs. Consequently, the build triggered by -compiled won't find sources cached by "go build". We can still safely cache compiled sources from multiple runs of "go list -find -compiled" though, since cgo generated sources are not affected by imported dependencies. This change adds a second look into the cache in this situation. Fixes #29371 Change-Id: Ia0ae5a403ab5d621feaa16f521e6a65ac0ae6d9a Reviewed-on: https://go-review.googlesource.com/c/155481Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Jay Conrod authored
When building runtime/internal/atomic, the toolchain writes a symabis2 file. This file is read back in, filtered, and appended to the symabis file. This breaks with -n, since the symabis2 file is never written. With this change, when -n is used, an equivalent "grep" command is printed instead. The output for -x is unchanged. Fixes #29346 Change-Id: Id25e06e06364fc6689e71660d000f09c649c4f0c Reviewed-on: https://go-review.googlesource.com/c/155480Reviewed-by: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com>
-
Michael Anthony Knyszek authored
This change splits a testprog out of TestLockOSThreadExit and makes it its own test. Then, this change makes the testprog exit prematurely with a special message if unshare fails with EPERM because not all of the builders allow the user to call the unshare syscall. Also, do some minor cleanup on the TestLockOSThread* tests. Fixes #29366. Change-Id: Id8a9f6c4b16e26af92ed2916b90b0249ba226dbe Reviewed-on: https://go-review.googlesource.com/c/155437 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
- 20 Dec, 2018 13 commits
-
-
Ian Lance Taylor authored
Updates #26650 Change-Id: I0ec070127dcacc7fc68dd5baf125eb762e1ea846 Reviewed-on: https://go-review.googlesource.com/c/155038Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Matthew Dempsky authored
It was possible that var X interface{} = 'x' could cause a compilation failure due to having not calculated rune's width yet. typecheck.go normally calculates the width of things, but it doesn't for implicit conversions to default type. We already compute the width of all of the standard numeric types in universe.go, but we failed to calculate it for the rune alias type. So we could later crash if the code never otherwise explicitly mentioned 'rune'. While here, explicitly compute widths for 'byte' and 'error' for consistency. Fixes #29350. Change-Id: Ifedd4899527c983ee5258dcf75aaf635b6f812f8 Reviewed-on: https://go-review.googlesource.com/c/155380Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com> Reviewed-by: Robert Griesemer <gri@golang.org>
-
Kevin Burke authored
I was confused by the juxtaposition of os.Interrupt docs, which are "guaranteed to exist on all platforms" in one sentence and then "not implemented" in the next sentence. Reading the code reveals "not implemented" refers specifically to the implementation of os.Process.Signal on Windows, not to the os.Interrupt variable itself. Reword the doc to make this distinction clearer. Fixes #27854. Change-Id: I5fe7cddea61fa1954cef2006dc51b8fa8ece4d6e Reviewed-on: https://go-review.googlesource.com/c/137336Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
-
Brian Kessler authored
Extended precision math/bits functions are unsigned. Change-Id: Ic1633e9c367fc3d5a80bc503008f035db4e78945 Reviewed-on: https://go-review.googlesource.com/c/155379Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Osamu TONOMORI authored
Change-Id: I84b74bc96516033bbf4a01f9aa81fe60d5a41355 Reviewed-on: https://go-review.googlesource.com/c/155317Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Ian Lance Taylor authored
Fixes #28699 Change-Id: Ic340c3171bb7d91d8cb9553967c2b51e7d9daba8 Reviewed-on: https://go-review.googlesource.com/c/155177Reviewed-by: Bryan C. Mills <bcmills@google.com>
-
Keith Randall authored
Out-of-bounds reads of globals can happen in dead code. For code like this: s := "a" if len(s) == 3 { load s[0], s[1], and s[2] } The out-of-bounds loads are dead code, but aren't removed yet when lowering. We need to not panic when compile-time evaluating those loads. This can only happen for dead code, so the result doesn't matter. Fixes #29215 Change-Id: I7fb765766328b9524c6f2a1e6ab8d8edd9875097 Reviewed-on: https://go-review.googlesource.com/c/154057 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>
-
Tobias Klauser authored
Currently the link works also with the non-existing GOARCH armd64, but let's correct in anyhow. Change-Id: Ida647b8f9dd2f8460b019f5a23759f10a6da8e60 Reviewed-on: https://go-review.googlesource.com/c/155277Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Tobias Klauser authored
Update to x/sys git revision 074acd46bca67915925527c07849494d115e7c43 This fixes TestFormatMessage and TestExample on windows/arm by pulling in CL 154560 and CL 154817. Change-Id: Ic6495fe3072b5bcc7ea68efb3f0be5fc1fe4c238 Reviewed-on: https://go-review.googlesource.com/c/155297 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
Before this CL we accepted timeouts in TestUDPZeroBytePayload to avoid flakiness and because, according to CL 9194, the test didn't work on some platforms. On Windows, before CL 132781, the read would always timeout, and so since the test accepted timeouts it would pass incorrectly. CL 132781 fixed Windows, and changed the test to not accept timeouts in the ReadFrom case. However, the timeout was short, and so on a loaded system the Read might timeout not due to an error in the code, but just because the read was not delivered. So ignoring timeouts made the test flaky, as reported in issue #29225. This CL tries to get to a better state by increasing the timeout to a large value and not permitting timeouts at all. If there are systems where the test fails, we will need to explicitly skip the test on those systems. Fixes #29225 Change-Id: I26863369898a69cac866b34fcb5b6ffbffab31f6 Reviewed-on: https://go-review.googlesource.com/c/154759 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Alex Brainman authored
If TMP environment variable is set to Z:\, TempDir returns Z:. But Z: refers to current directory on Z:, while Z:\ refers to root directory on Z:. Adjust TempDir to return Z:\. Fixes #29291 Change-Id: If04d0c7977a8ac2d9d558307502e81beb68776ef Reviewed-on: https://go-review.googlesource.com/c/154384 Run-TryBot: Alex Brainman <alex.brainman@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
catatsuy authored
Change-Id: Iaa1468296fbc98389165a152cf8b591216c22489 Reviewed-on: https://go-review.googlesource.com/c/155217Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Jordan Rhee authored
Tracing uses cputicks() to generate trace event timestamps. cputicks() is expected to be a high resolution clock source. On Windows/ARM, call QueryPerformanceCounter() which is the highest resolution clock source available. Updates #26148 Change-Id: I987fa556060b3d60c02f07b87b9e6320b9b026e2 Reviewed-on: https://go-review.googlesource.com/c/154762Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
- 19 Dec, 2018 8 commits
-
-
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: Austin Clements <austin@google.com>
-
Michael Anthony Knyszek authored
This change disables the test TestArenaCollision on Darwin in race mode to deal with the fact that Darwin 10.10 must use MAP_FIXED in race mode to ensure we retain our heap in a particular portion of the address space which the race detector needs. The test specifically checks to make sure a manually mapped region's space isn't re-used, which is definitely possible with MAP_FIXED because it replaces whatever mapping already exists at a given address. This change then also makes it so that MAP_FIXED is only used in race mode and on Darwin, not all BSDs, because using MAP_FIXED breaks this test for FreeBSD in addition to Darwin. Updates #26475. Fixes #29340. Change-Id: I1c59349408ccd7eeb30c4bf2593f48316b23ab2f Reviewed-on: https://go-review.googlesource.com/c/155097 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Jordan Rhee authored
This reverts change https://golang.org/cl/154758. Restore the previous implementations of nanotime and time.now, which are sufficiently high resolution and more efficient than QueryPerformanceCounter. The intent of the change was to improve resolution of tracing timestamps, but the change was overly broad as it was only necessary to fix cputicks(). cputicks() is fixed in a subsequent change. Updates #26148 Change-Id: Ib9883d02fe1af2cc4940e866d8f6dc7622d47781 Reviewed-on: https://go-review.googlesource.com/c/154761Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Agniva De Sarker authored
Change-Id: I767bf77aeab62f2d42239fac9d601a8e04fe860f Reviewed-on: https://go-review.googlesource.com/c/154957Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Tobias Klauser authored
Fix two typos and don't indent the go vet example. Change-Id: Iccec56ca5decfbae45547a00115500ed13b703e1 Reviewed-on: https://go-review.googlesource.com/c/154721Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Ian Lance Taylor authored
This was accidentally broken by CL 127755. Fixes #29333 Change-Id: I5e92048c64a55c1699d6c38eb4dbbd51c817b820 Reviewed-on: https://go-review.googlesource.com/c/155037 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Elias Naur authored
Change-Id: I3c8ba5fdb05b6b1324648622656cc10071c70a34 Reviewed-on: https://go-review.googlesource.com/c/154997Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Michael Anthony Knyszek authored
startpanic_m could be called correctly in a context where there's a valid G, a valid M, but no P, for example in a signal handler which panics. Currently, startpanic_m has write barriers enabled because write barriers are permitted if a G's M is dying. However, all the current write barrier implementations assume the current G has a P. Therefore, in this change we disable write barriers in startpanic_m, remove the only pointer write which clears g.writebuf, and fix up gwrite to ignore the writebuf if the current G's M is dying, rather than relying on it being nil in the dying case. Fixes #26575. Change-Id: I9b29e6b9edf00d8e99ffc71770c287142ebae086 Reviewed-on: https://go-review.googlesource.com/c/154837 Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
-
- 18 Dec, 2018 10 commits
-
-
Jordan Rhee authored
The previous implementation of nanotime and time.now used a time source that was updated on the system clock tick, which has a maximum resolution of about 1ms. On 386 and amd64, this time source maps to the system performance counter, so has much higher resolution. On ARM, use QueryPerformanceCounter() to get a high resolution timestamp. Updates #26148 Change-Id: I1abc99baf927a95b472ac05020a7788626c71d08 Reviewed-on: https://go-review.googlesource.com/c/154758Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Elias Naur authored
Change-Id: I4277f4130b460b42c5b51fd5a5e07f6c0e62163b Reviewed-on: https://go-review.googlesource.com/c/154720Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Filippo Valsorda authored
Change-Id: I9a30c76d1299a494cce69b1060156bc2932ac8d5 Reviewed-on: https://go-review.googlesource.com/c/154857Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Kevin Burke authored
Permission bits are most commonly viewed in string form (rwx-- etc) or in octal form (0755), but the latter is relatively rare in Go. Demonstrate how to print a FileMode in readable octal format. Change-Id: I41feb801bcecb5077d4eabafdea27c149fc179a1 Reviewed-on: https://go-review.googlesource.com/c/154423 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Michael Anthony Knyszek authored
This change makes it so that reserving more of the address space for the heap calls mmap with MAP_FIXED in race mode. Race mode requires certain guarantees on where the heap is located in the address space, and on Darwin 10.10 it appears that the kernel may end up ignoring the hint quite often (#26475). Using MAP_FIXED is relatively OK in race mode because nothing else should be mapped in the memory region provided by the initial hints. Fixes #26475. Change-Id: Id7ac1534ee74f6de491bc04441f27dbda09f0285 Reviewed-on: https://go-review.googlesource.com/c/153897Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
-
Ian Lance Taylor authored
When using //line directives and unformatted code it is possible for positions to repeat. Increment the final column position to avoid that. Fixes #27350 Change-Id: I2faccc31360075e9814d4a024b0f98b117f8ce97 Reviewed-on: https://go-review.googlesource.com/c/153061 Run-TryBot: Rob Pike <r@golang.org> Reviewed-by: Rob Pike <r@golang.org>
-
Ian Lance Taylor authored
This ensures that "go test cmd/cover" tests the current cover program, not the installed cover program. Change-Id: I58e718ded7eb1cd8da448d0194262209bb025b20 Reviewed-on: https://go-review.googlesource.com/c/153058 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Cherry Zhang authored
CL 138675 added the race detector support on Linux/ARM64, but it didn't enable the race detector tests in cmd/dist (therefore in all.bash). Enable them. Updates #28848 Change-Id: I4306dad2fb4167021d568436076b9f535d7f6e07 Reviewed-on: https://go-review.googlesource.com/c/149967 Run-TryBot: Cherry Zhang <cherryyz@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
-
Filippo Valsorda authored
Change-Id: I598c9a2031001a6780b75c31d9015c880741b170 Reviewed-on: https://go-review.googlesource.com/c/154637Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-
Dmitri Shuralyov authored
Also update a Go 1 compatibility promise link to canonical URL. Updates #27592 Updates #28264 Change-Id: I5994a0a63e0870c1795c65016590dfad829d26a7 Reviewed-on: https://go-review.googlesource.com/c/154618Reviewed-by: Richard Musiol <neelance@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
-