Asking about runtime/cgo when CgoEnabled=false now correctly
returns an error from build.Import (specifically, NoGoError), because
there are no buildable Go files in that directory.
The API tool was depending on it returning a package with no Go
files instead. Correct that assumption.
Fixes all.bash on local machines.
(Dashboard appears not to be running the api tool at all.)
Update #6124
TBR=golang-dev
CC=golang-dev
https://golang.org/cl/13385046
It was never going to last.
««« original CL description
cmd/api: break the builds
There is some question about whether the api tool is
running on Windows (see issue 6124), and now I'm
starting to question whether it runs on any of the builders,
since both darwin/amd64 and linux/amd64 are crashing for me
in the api tool due to a recent cgo-related change, and yet
the dashboard is happy.
If the dashboard is still happy after this CL, we have a problem.
Update #6124
TBR=golang-dev
CC=golang-dev
https://golang.org/cl/13632053
»»»
TBR=golang-dev
CC=golang-dev
https://golang.org/cl/13474045
There is some question about whether the api tool is
running on Windows (see issue 6124), and now I'm
starting to question whether it runs on any of the builders,
since both darwin/amd64 and linux/amd64 are crashing for me
in the api tool due to a recent cgo-related change, and yet
the dashboard is happy.
If the dashboard is still happy after this CL, we have a problem.
Update #6124
TBR=golang-dev
CC=golang-dev
https://golang.org/cl/13632053
The old test for "no Go files" was p.Name == "", meaning we never
saw a Go package statement. That test fails if there are cgo files
that we parsed (and recorded the package name) but then chose
not to use (because cgo is not available).
Test the actual file lists instead.
Fixes#6078.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/13661043
The units example is nice but is covered by the Lucent
license, which may be a concern for some people making a
commercial source code distribution of Go.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/13283045
This allows us to make two changes:
1. Force the argument type to be size_t, even on broken
systems that declare malloc to take a ulong.
2. Call runtime.throw if malloc fails.
(That is, the program crashes; it does not panic.)
Fixes#3403.
Fixes#5926.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/13413047
For example, if the pattern is m... there is
no need to look in directories not beginning with m.
Fixes#5214.
R=golang-dev, adg
CC=golang-dev
https://golang.org/cl/13253049
The scan starts at the directory we care about and works
backward to the GOPATH root. The error should say the
original directory name, not the name of the GOPATH root.
Fixes#6175.
R=golang-dev, minux.ma
CC=golang-dev
https://golang.org/cl/13366050
The entry for LEAL/LEAQ in these optabs was listed as having
two data bytes in the y array. In fact they had and expect no data
bytes. However, the general loop expects to be able to look at at
least one data byte, to make sure it is not 0x0f. So give them each
a single data byte set to 0 (not 0x0f).
Since the MOV instructions have the largest optab cases, this
requires growing the size of the data array.
Clang found this bug because the general o->op[z] == 0x0f
test was using z == 22, which was out of bounds.
In practice the next byte in memory was probably not 0x0f
so it wasn't truly broken. But might as well be clean.
Update #5764
R=ken2
CC=golang-dev
https://golang.org/cl/13241050
For example, if an x_test.go file contains a syntax error,
b.test fails with an error message. But it wasn't printing
the same FAIL line that a build failure later would print.
This makes all the test failures that happen (once we
decide to start running tests) consistently say FAIL.
Fixes#4701.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/13431044
A package main binary (that is, a command) being installed
does not mean we can skip the build of the package archive
during a test.
Fixes#3417.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/13462046
Remove test of whether SWIG shared library is older than
sources--should be covered by test of package file anyhow.
Fixes#5739.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/13352046
This will bring in the C++ standard library without requiring
any special #cgo LDFLAGS options.
When using gccgo, just add -lstdc++ to link line; this should
do no harm if it is not needed.
No tests, since we don't want to assume a C++ compiler.
Update #5629
R=golang-dev, minux.ma, rsc
CC=golang-dev
https://golang.org/cl/13394045
If you thought gcc -ansi -pedantic was pedantic, just wait
until you meet clang -fsanitize=undefined.
I think this addresses all the reported "errors", but we'll
need another run to be sure.
all.bash still passes.
Update #5764
Dave, can you please try again?
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/13334049
Cannot happen when using the go command, but help
people running commands by hand or with other tools.
Fixes#5888.
R=ken2
CC=golang-dev
https://golang.org/cl/13324048
* Sort imports by import path, then import name, then comment. Currently, gofmt sorts only by import path.
* If two imports have the same import path and import name, and one of them has no comment, remove the import with no comment. (See the discussion at issue 4414.)
Based on @rsc's https://golang.org/cl/7231070/Fixes#4414.
R=gri, rsc
CC=golang-dev
https://golang.org/cl/12837044
This message was helpful for pre-Go 1 users updating to Go 1.
That time is past. Now the message is confusing because it
depends on knowing what pre-Go 1 looked like.
Update #4697.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/13335051
cmd/cc: bv.c imports libc.h twice
When using the Plan 9 compiler, the invocation
#include <../ld/textflag.h>
works for the toolchain, but not for the MACH library.
Module cmd/cc/bv.c includes libc.h and "cc.h", which in
turn also includes libc.h. In the Plan 9 context, this
causes a number of duplicate definitions.
R=golang-dev, rsc, r
CC=golang-dev
https://golang.org/cl/13303047
This should have been part of revision 16731:cdedb129e020, but
I missed it. This fixes printing local variables when doing
an external link.
No test because we aren't doing any debug info testing yet.
Fixes#5719.
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/13464046
Also introduce BGET2/4, BPUT2/4 as they are widely used.
Slightly improve BGETC/BPUTC implementation.
This gives ~5% CPU time improvement on go install -a -p1 std.
Before:
real user sys
0m23.561s 0m16.625s 0m5.848s
0m23.766s 0m16.624s 0m5.846s
0m23.742s 0m16.621s 0m5.868s
after:
0m22.999s 0m15.841s 0m5.889s
0m22.845s 0m15.808s 0m5.850s
0m22.889s 0m15.832s 0m5.848s
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/12745047
