This resulted in our first "ok" on the dashboard for Plan 9 with the
buildlet, in 19 minutes. It only runs the std tests, and nothing else
after that.
Update golang/go#9491
Change-Id: Iad77a594f83bfd3fa72596bcc3057645d9c9bb4c
Reviewed-on: https://go-review.googlesource.com/2523
Reviewed-by: Andrew Gerrand <adg@golang.org>
Also: Better position for error messages related to wrong use of ... .
Fixes#9473.
Change-Id: I90565f51a42897b7292f651a84a23611a5d8f359
Reviewed-on: https://go-review.googlesource.com/2390
Reviewed-by: Alan Donovan <adonovan@google.com>
This got lost before in my git stash stack.
Change-Id: Id73cdb89e73ab83c26971c6c1c4e0fc74d91018f
Reviewed-on: https://go-review.googlesource.com/2521
Reviewed-by: Andrew Gerrand <adg@golang.org>
Godoc documentation did not mention the feature for showing example code
runnable by the testing package. Add a link to the testing package.
Update golang/go#9471
Change-Id: Ic15794c59732e9b0b42c5b16c60be0a47c41afa5
Reviewed-on: https://go-review.googlesource.com/2490
Reviewed-by: Andrew Gerrand <adg@golang.org>
When cover is used with cgo packages, the coverage profile is produced
from the cgo-generated Go source files, so the profile will reference
line and column numbers from that generated source, even though it names
the original file.
This is okay in general because the cgo-generated Go source files are
very similar to the original, with one significant exception:
the original source may refer to C identifiers such as C.foo(), but the
cgo tool generates source that rewrites these mentions to something like
_Cfunc_foo.
This means that column numbers in coverage profiles might be higher than
they should be, so be lenient when interpreting them.
Update golang/go#9479
Change-Id: Ic3abef07471614101ce0c686d35b85e7e5e6a777
Reviewed-on: https://go-review.googlesource.com/2410
Reviewed-by: Rob Pike <r@golang.org>
Move the parser for benchmark output from cmd/benchcmp into its own
package, benchmark/parse.
The majority of the change is just moving code around. Instead of
implementing the '-best' flag in ParseBenchSet, it is now implemented in
its own function 'selectBest' in cmd/benchcmp.
Bench.Ord (the ordinal position of a Bench within a BenchSet) has been
exported.
Change-Id: Id27032a220f9ff2596117b58b86243998695a804
Reviewed-on: https://go-review.googlesource.com/2102
Reviewed-by: Rob Pike <r@golang.org>
This uses the new JSON interface to the build dashboard (from
golang.org/cl/2290) to find all work, and re-enables the OpenBSD
builder[*], and can do multiple things at a time. Andrew and I just
watched it fire up 8 OpenBSD VMs at once to catch up.
[*] The OpenBSD builder was disabled because it would only report
results for the main repo, not subrepos, and the old
build.golang.org/todo interface didn't understand that was
possible. Now the steps are considered separate.
Update golang/go#8642 (OpenBSD)
Update golang/go#9492 (builds in VMs)
Change-Id: Ic6c2f73ee3da218dd54ef1a33f3afc97046ea3cc
Reviewed-on: https://go-review.googlesource.com/2282
Reviewed-by: Andrew Gerrand <adg@golang.org>
Currently this is running an OpenBSD amd64 builder, but other operating
systems are now easy.
Updates golang/go#8642
Updates golang/go#9492
Change-Id: I4e1026c49ee4d253dfcf78c7606767294784f02e
Reviewed-on: https://go-review.googlesource.com/2264
Reviewed-by: Andrew Gerrand <adg@golang.org>
Currently the coordinator only handles Docker container builders. An
upcoming change will add VM builders, running VMs on GCE for OpenBSD,
Plan 9, Windows, etc.
This change refactors the handling of the coordinator's build status
in prep for VM builders. Notably, it doesn't call "docker logs"
directly to get logs. It now keeps them in memory instead. Because
they're then in memory, we might as well make it keep the details of
the last N builds too, which we kept wanting earlier.
Updates #9492
Change-Id: I6bae4a5854e7efa3f8a6186ec3670a43c98c4df2
Reviewed-on: https://go-review.googlesource.com/2262
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This isn't used yet, but will be for the new-style builders (VMs on
GCE running the buildlet, started by the coordinator).
From the code's comments:
cleanUpOldVMs periodically enumerates virtual machines and deletes
any which have a "delete-at" attribute having a unix timestamp
before the current time. These VMs are created to run a single
build and should be shut down by a controlling process. Due to
various types of failures, they might get stranded. To prevent them
from getting stranded and wasting resources forever, we instead set
the "delete-at" metadata attribute on them when created to some
time that's well beyond their expected lifetime, and then this is
the backup mechanism to delete them if they get away.
Update golang/go#8639
Update golang/go#8640
Update golang/go#8642
Change-Id: I489e97926e7ab56487571c2bf0bd255cdf49570d
Reviewed-on: https://go-review.googlesource.com/2199
Reviewed-by: Burcu Dogan <jbd@google.com>
The Go wiki has moved to GitHub. Update links to use a golang.org/wiki/... target.
Change-Id: Iff7e1b2add469318f5e467aed5d1f3e67155b283
Reviewed-on: https://go-review.googlesource.com/2250
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It is sometimes useful for API clients to be able to disable the unused
import check, although for good reason this should not be exposed as part of
a user-facing interface. There are at least two use cases that I am aware of:
1) It allows for automated test case reduction tools such as delta or C-Reduce
to be more easily applied to type checker input. Disabling the check
makes it possible for the tool to identify and remove code that depends
on imported packages without any specific knowledge of Go, as the import
need not be removed simultaneously with the code.
2) Interactive tools (such as REPLs) that may have previously received a
list of imports and subsequently receive a line of code that may use any
number of these imports. It is simpler for such tools to import all the
packages in its list than to try to identify the correct set of imports.
Change-Id: I00091a4e5c8e1bd664efd82a636f255eaaa5a2db
Reviewed-on: https://go-review.googlesource.com/2136
Reviewed-by: Robert Griesemer <gri@golang.org>
The new interface makes the functions more useful by allowing clients to
check the various properties that TypeAndValue provides.
Change-Id: I8b41a27316081bea24a18ffe6fa1812e809d6f67
Reviewed-on: https://go-review.googlesource.com/2134
Reviewed-by: Robert Griesemer <gri@golang.org>
Requires Go tip to function, but compiles with old versions of Go, but
without returning the trailer, which we'll be able to detect in the
coordinator to make sure nobody used an old Go to cross-compile a
buildlet.
Change-Id: Ie5f71c0a4477563dea5f1526af10a49aa41536d6
Reviewed-on: https://go-review.googlesource.com/2159
Reviewed-by: Andrew Gerrand <adg@golang.org>
This is almost entirely the work of @mdempsky; I just ran
it a bunch and reported bugs or tweaked things until it worked
and booted the buildlet on GCE.
Update #8642
Change-Id: If5d50bcdf90bc6aa648472cc951ed1c53b46eef3
Reviewed-on: https://go-review.googlesource.com/2156
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
+ Tests:
Extend function name uniqueness check to exported wrappers.
Check that expected synthetic functions are created, reachable, and not duplicated.
Change-Id: I0e87ebb2712e33e1f49da3fa9a9dde0085bf3850
Reviewed-on: https://go-review.googlesource.com/2013
Reviewed-by: Robert Griesemer <gri@golang.org>
+ test
Change-Id: Ie37835577ffcdd764cf6a0b611e02f04386755cf
Reviewed-on: https://go-review.googlesource.com/1580
Reviewed-by: Robert Griesemer <gri@golang.org>
...like we do for "runtime" functions, so that they fail informatively
if executed. They all need intrinsics, but only some are yet defined.
Also:
- added test for issue 9462
- "BUG" in test output is now a failure in all tests (not just $GOROOT tests)
- added intrinsic for reflect.SliceOf
- show dynamic type of panic value
Fixes issue 9462
Change-Id: I3a504c7faeed81e922fedc7dd59222717f3a7e95
Reviewed-on: https://go-review.googlesource.com/2145
Reviewed-by: Robert Griesemer <gri@golang.org>
Fixes various problems reported by go vet.
Change-Id: I12a6fdba8f911b21805d8e42903f8f6a5033790a
Reviewed-on: https://go-review.googlesource.com/2163
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This will match the default behavior when running locally.
In fact, our http://blog.golang.org/godoc-documenting-go-code explicitly
documents this feature (see also golang.org/cl/1953).
Change-Id: I581b17b60229ce70900cb51d548d1e2a34df41ba
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/2116
Reviewed-by: Andrew Gerrand <adg@golang.org>
Close the `<h3>` header tag with a closing `</h3>` tag to fix the HTML
syntax.
Change-Id: Ic86c5f31ec5550d6875aa085eed8da6a75881405
Reviewed-on: https://go-review.googlesource.com/2104
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Suggestion by dsymonds: Save code not data.
Add an extra element to the index array and an if can be eliminated.
Old generated code:
const _Day_name = "MondayTuesdayWednesdayThursdayFridaySaturdaySunday"
var _Day_index = [...]uint8{6, 13, 22, 30, 36, 44, 50}
func (i Day) String() string {
if i < 0 || i >= Day(len(_Day_index)) {
return fmt.Sprintf("Day(%d)", i)
}
hi := _Day_index[i]
lo := uint8(0)
if i > 0 {
lo = _Day_index[i-1]
}
return _Day_name[lo:hi]
}
New generated code:
const _Day_name = "MondayTuesdayWednesdayThursdayFridaySaturdaySunday"
var _Day_index = [...]uint8{0, 6, 13, 22, 30, 36, 44, 50}
func (i Day) String() string {
if i < 0 || i+1 >= Day(len(_Day_index)) {
return fmt.Sprintf("Day(%d)", i)
}
return _Day_name[_Day_index[i]:_Day_index[i+1]]
}
Change-Id: I6f46a4892d5813a12ec1ad01738c6a21c7e45172
Reviewed-on: https://go-review.googlesource.com/1990
Reviewed-by: David Symonds <dsymonds@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
If id is a number greater than 150k, then it is a Rietveld CL, otherwise
treat it as a Gerrit change id.
Also add support for /cl/ID/, because go commit 0edafefc36 uses this
form.
Change-Id: I46575e3284faaa727e346b34bbc46ab248cf12b3
Signed-off-by: Shenghou Ma <minux@golang.org>
Reviewed-on: https://go-review.googlesource.com/1283
Reviewed-by: Andrew Gerrand <adg@golang.org>
