There is a cleaner, simpler way.
««« original CL description
cmd/5g, cmd/6g, cmd/8g: faster compilation
Replace linked list walk with memset.
This reduces CPU time taken by 'go install -a std' by ~10%.
Before:
real user sys
0m23.561s 0m16.625s 0m5.848s
0m23.766s 0m16.624s 0m5.846s
0m23.742s 0m16.621s 0m5.868s
after:
0m22.714s 0m14.858s 0m6.138s
0m22.644s 0m14.875s 0m6.120s
0m22.604s 0m14.854s 0m6.081s
R=golang-dev, r
CC=golang-dev
https://golang.org/cl/13084043
»»»
TBR=dvyukov
CC=golang-dev
https://golang.org/cl/13352049
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
args is useful for printing tracebacks.
frame is not necessary anymore, but we might some day
get back to functions where the frame size does not vary
by program counter, and if so we'll need it. Avoid needing
to introduce a new struct format later by keeping it now.
Fixes#5907.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/13632051
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
The various throwing > 0 finish a change started
in a previous CL, which sets throwing = -1 to mean
"don't show the internals". That gets set during the
"all goroutines are asleep - deadlock!" crash, and it
should also be set during any other expected crash
that does not indicate a problem within the runtime.
Most runtime.throw do indicate a problem within the
runtime, however, so we should be able to enumerate
the ones that should be silent. The goroutine sleeping
deadlock is the only one I can think of.
Update #5139
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/13662043
Otherwise, if panic starts running deferred functions,
the code that panicked appears to be calling those
functions directly, which is not the case and can be
confusing.
For example:
main.Two()
/Users/rsc/x.go:12 +0x2a
runtime.panic(0x20dc0, 0x2100cc010)
/Users/rsc/g/go/src/pkg/runtime/panic.c:248 +0x106
main.One()
/Users/rsc/x.go:8 +0x55
This makes clear(er) that main.Two is being called during
a panic, not as a direct call from main.One.
Fixes#5832.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/13302051
getaddrinfo is supposed to set errno when it returns
EAI_SYSTEM, but sometimes it does not.
Fixes#6232.
R=golang-dev, iant
CC=golang-dev
https://golang.org/cl/13532045
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
This CL adds minimal support of Happy Eyeballs-like TCP connection
setup to Dialer API. Happy Eyeballs and derivation techniques are
described in the following:
- Happy Eyeballs: Success with Dual-Stack Hosts
http://tools.ietf.org/html/rfc6555
- Analysing Dual Stack Behaviour and IPv6 Quality
http://www.potaroo.net/presentations/2012-04-17-dual-stack-quality.pdf
Usually, the techniques consist of three components below.
- DNS query racers, that run A and AAAA queries in parallel or series
- A short list of destination addresses
- TCP SYN racers, that run IPv4 and IPv6 transport in parallel or series
This CL implements only the latter two. The existing DNS query
component gathers together A and AAAA records in series, so we don't
touch it here. This CL just uses extended resolveInternetAddr and makes
it possible to run multiple Dial racers in parallel.
For example, when the given destination is a DNS name and the name has
multiple address family A and AAAA records, and it happens on the TCP
wildcard network "tcp" with DualStack=true like the following:
(&net.Dialer{DualStack: true}).Dial("tcp", "www.example.com:80")
The function will return a first established connection either TCP over
IPv4 or TCP over IPv6, and close the other connection internally.
Fixes#3610.
Fixes#5267.
Benchmark results on freebsd/amd64 virtual machine, tip vs. tip+12416043:
benchmark old ns/op new ns/op delta
BenchmarkTCP4OneShot 50696 52141 +2.85%
BenchmarkTCP4OneShotTimeout 65775 66426 +0.99%
BenchmarkTCP4Persistent 10986 10457 -4.82%
BenchmarkTCP4PersistentTimeout 11207 10445 -6.80%
BenchmarkTCP6OneShot 62009 63718 +2.76%
BenchmarkTCP6OneShotTimeout 78351 79138 +1.00%
BenchmarkTCP6Persistent 14695 14659 -0.24%
BenchmarkTCP6PersistentTimeout 15032 14646 -2.57%
BenchmarkTCP4ConcurrentReadWrite 7215 6217 -13.83%
BenchmarkTCP6ConcurrentReadWrite 7528 7493 -0.46%
benchmark old allocs new allocs delta
BenchmarkTCP4OneShot 36 36 0.00%
BenchmarkTCP4OneShotTimeout 36 36 0.00%
BenchmarkTCP4Persistent 0 0 n/a%
BenchmarkTCP4PersistentTimeout 0 0 n/a%
BenchmarkTCP6OneShot 37 37 0.00%
BenchmarkTCP6OneShotTimeout 37 37 0.00%
BenchmarkTCP6Persistent 0 0 n/a%
BenchmarkTCP6PersistentTimeout 0 0 n/a%
BenchmarkTCP4ConcurrentReadWrite 0 0 n/a%
BenchmarkTCP6ConcurrentReadWrite 0 0 n/a%
benchmark old bytes new bytes delta
BenchmarkTCP4OneShot 2500 2503 0.12%
BenchmarkTCP4OneShotTimeout 2508 2505 -0.12%
BenchmarkTCP4Persistent 0 0 n/a%
BenchmarkTCP4PersistentTimeout 0 0 n/a%
BenchmarkTCP6OneShot 2713 2707 -0.22%
BenchmarkTCP6OneShotTimeout 2722 2720 -0.07%
BenchmarkTCP6Persistent 0 0 n/a%
BenchmarkTCP6PersistentTimeout 0 0 n/a%
BenchmarkTCP4ConcurrentReadWrite 0 0 n/a%
BenchmarkTCP6ConcurrentReadWrite 0 0 n/a%
R=golang-dev, bradfitz, nightlyone, rsc
CC=golang-dev
https://golang.org/cl/12416043
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
This is not quite what that issue reports,
because this does not involve a DLL.
But I wanted to make sure this much was working.
Update #4339
R=golang-dev, minux.ma
CC=golang-dev
https://golang.org/cl/13653043
Add coverage for some uncovered bytes methods. The increase in actual coverage is disapointing small.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/13651044
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
Fixes cpu subtype check when using external linker which sets the CPU_SUBTYPE_LIB64 bit (1<<31).
Fixes#6197.
R=golang-dev, minux.ma, rsc
CC=golang-dev
https://golang.org/cl/13248046
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
It was lost when the generic "Notes" support went in.
Had to change the test setup, because it precluded even
being able test multi-line comments, much less multi-paragraph
comments.
Now 'godoc sync/atomic' works correctly again.
Fixes#6135.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/13427045
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
If using other gdb python scripts loaded before Go's gdb-runtime.py
and that have a different init prototype:
Traceback (most recent call last):
File "/usr/lib/go/src/pkg/runtime/runtime-gdb.py", line 446, in <module>
k()
TypeError: __init__() takes exactly 3 arguments (1 given)
The problem is that gdb keeps all python scripts in the same namespace,
so vars() contains them. To avoid that, load helpers one by one.
R=iant, rsc
CC=gobot, golang-dev
https://golang.org/cl/9752044
Various compilers complain about the macro expansion not
being used. I fixed a few yesterday. More today.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/13643044
Before CL 7065067 calling Next on an element returned either the
next/prev element or nil was returned. After the CL if an element
was not part of a list e.Next() and e.Prev() will panic. This CL
returns to the documented behavior, that Next/Prev returns the
next/prev list element or nil.
Fixes#6349.
R=golang-dev, gri
CC=golang-dev
https://golang.org/cl/13234051
Bug3486 tried to walk the entire file tree, but other tests might
be creating and removing files in that tree. In particular, package os
creates and removes files in the os directory, and issue 5863
reports failures due to seeing those files appear and then disappear.
Change the test to walk just the test tree, which should not be
changing.
Fixes#5863.
R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/13467045
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
