This function has been copied at least 6 times throughout
go.tools. This implementation is superior since it does
all I/O through the virtualized go/build file system, and it
is highly parallel (and much faster).
We expose two flavours, simple (for existing tests) and
parallel (for high-performance tools such as gorename).
This CL creates the go/buildutil package, which is intended for
utilities related to go/build.
+ test.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/137430043
Documentation change only. The binary will not be installed
using the "go tool" mechanism.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/133710046
- for unused packages where base(package path) != package name
- for conflicts between imported packages or dot-imported objects
and local declarations
Per suggestions from adonovan, inspired by the gc error messages.
LGTM=adonovan
R=adonovan, bradfitz
CC=golang-codereviews
https://golang.org/cl/135550043
(godoc is excluded from this CL since it will continue to use
/src/pkg in its URL namespace, making the necessary cleanup
more subtle.)
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/141770043
... since it already caught a problem and was fixed in
hg rev 0b99c2137ccc.
I pushed this live already just so don't get a whole column of
fail that might hide other issues. Real users have USER set
anyway. (Perhaps we should set it for all our builders?)
LGTM=adg
R=golang-codereviews
CC=adg, dave, golang-codereviews, minux
https://golang.org/cl/137180043
Missed comment from previous code review.
Next up: execution tests so this won't happen again
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/134480043
Improve the generated code by using a const instead of a var for the names string.
This requires some refactoring to get neat const() and var() blocks.
Also change the generate map code go use a single sliced string, to reduce the
size of the compiled representation (only one string value).
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/135450044
Otherwise when running -386 and -amd64 on the same machine
with both copies of TDM-GCC installed (the installer wizard lets
you choose which one, and you can do both options in two
different install attemps), one previously got this error when
using the 64-bit gcc with a 386 build:
--- FAIL: TestStdcallAndCDeclCallbacks (0.12s)
panic: Failed to load C:\Users\WINDOW~1\AppData\Local\Temp\1\TestCDeclCallback960696761\test.dll: %1 is not a valid Win32 application. [recovered]
panic: Failed to load C:\Users\WINDOW~1\AppData\Local\Temp\1\TestCDeclCallback960696761\test.dll: %1 is not a valid Win32 application.
goroutine 81490 [running]:
runtime.panic(0x5b8c00, 0x1390d4e0)
c:/gobuilder/windows-386-gce-b24422c8828f/go/src/pkg/runtime/panic.c:130 +0xed fp=0x12d99f78 sp=0x12d99f24
testing.func·006()
c:/go/src/pkg/testing/testing.go:421 +0x147 fp=0x12d99fd0 sp=0x12d99f78
----- stack segment boundary -----
runtime.panic(0x5b8c00, 0x1390d4e0)
c:/gobuilder/windows-386-gce-b24422c8828f/go/src/pkg/runtime/panic.c:98 +0x17a fp=0x12155e98 sp=0x12155e44
syscall.MustLoadDLL(0x1390b7c0, 0x4a, 0x2)
c:/go/src/pkg/syscall/dll_windows.go:62 +0x6c fp=0x12155eb8 sp=0x12155e98
runtime_test.(*cbTest).run(0x12155f24, 0x1213cc00, 0x1390b7c0, 0x4a)
c:/gobuilder/windows-386-gce-b24422c8828f/go/src/pkg/runtime/syscall_windows_test.go:399 +0x36 fp=0x12155ef4 sp=0x12155eb8
runtime_test.TestStdcallAndCDeclCallbacks(0x1213cc00)
c:/gobuilder/windows-386-gce-b24422c8828f/go/src/pkg/runtime/syscall_windows_test.go:448 +0x28e fp=0x12155fac sp=0x12155ef4
TBR=cmang
R=cmang
CC=adg, golang-codereviews
https://golang.org/cl/141070043
Refactor a little to make testing easier.
Add golden tests and a check fo splitIntoRuns, which is the subtlest piece.
Still to come: execution tests.
Also fix a few issues in the generated code.
LGTM=gri
R=gri
CC=golang-codereviews, josharian
https://golang.org/cl/134450044
Creating a new disk is the major latency cost of creating a
new instance. If we reuse a previous disk image, the VM and
CoreOS boot much quicker and start building again.
So add a mode where we don't mark the disk as delete-on-death
when we create it, and we search for a suitably-named existing
one on creation and try to reuse it.
It's a cache, essentially. It's still stateless.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/135410043
Then make the coordinator and linux environment Makefiles have
an upload target. Amusingly, this actually worked: the Docker
images now tar + compress + upload over HTTP all in a stream,
without even knowing how large the resulting tar.gz will be until
it's done uploading.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/140200043
This tool creates String methods from constant definitions.
It's a time-saver designed to be used from go generate.
The methods generated are efficient, more so than one
is likely to create by hand.
Given
package date
type Day int
const (
Monday Day = iota
Tuesday
Wednesday
Thursday
Friday
Saturday
Sunday
)
the command
stringer -type Day
will create the file day_string.go containing
package date
import "fmt"
var (
_Day_indexes = []uint8{6, 13, 22, 30, 36, 44, 50}
_Day_names = "MondayTuesdayWednesdayThursdayFridaySaturdaySunday"
)
func (i Day) String() string {
if i < 0 || i >= Day(len(_Day_indexes)) {
return fmt.Sprintf("Day(%d)", i)
}
hi := _Day_indexes[i]
lo := uint8(0)
if i > 0 {
lo = _Day_indexes[i-1]
}
return _Day_names[lo:hi]
}
There are several strategies for the created method chosen according to
the structure of the sequence of constants.
Handles integer types only, both signed and unsigned. That's probably
all that is needed.
Tests to follow, but the test structure will be large so sending this out
separately. The code has been heavily hand-tested but there are
some bugs. Don't depend on this until the tests are installed.
LGTM=gri
R=gri, josharian
CC=golang-codereviews
https://golang.org/cl/136180043
Remove subversion & use newer version of the builder which
makes -verbose direct all.bash output to stdout/stderr.
LGTM=cmang
R=adg, cmang
CC=golang-codereviews
https://golang.org/cl/140910044
Recent changes in the runtime caused the interpreter to call 'getg',
and it should never have gotten that far.
Also, delete bodies of "runtime" functions, since they're too magical.
This makes missing intrinsics cause very obvious failures.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/135330043
It returns the value formerly returned by Pkg(), i.e. the imported package.
Pkg() now returns the package enclosing the import statement,
which is consistent with all other Objects.
Fixesgolang/go#8628.
LGTM=gri
R=gri
CC=golang-codereviews
https://golang.org/cl/136090043
They were from a time before we had the os/exec package, if
memory serves.
Also, make verbose also mean that the main build's stdout
and stderr go to the real stdout and stderr as well.
I'll want that for the Docker-based builder.
LGTM=adg
R=adg
CC=golang-codereviews
https://golang.org/cl/135000043
Also: Added Config.Strict flag to enable type checker tests
beyond the Go 1 specification.
Fixesgolang/go#8561.
LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/134050043
LookupFieldOrMethod now also decides whether a found
method is actually in the method set. Simplifies call
sites. Added corresponding API tests.
TODO (separate CL): Decide what the correct value for
the indirect result should be (as required for code
generation). For now, the result value for indirect
is unchanged from before if a field/method is found.
Fixesgolang/go#8584.
LGTM=adonovan
R=adonovan
CC=golang-codereviews
https://golang.org/cl/132260043
