Joe Tsai [Thu, 17 Dec 2015 07:10:14 +0000 (23:10 -0800)]
archive/tar: document how Reader.Read handles header-only files
Commit dd5e14a7511465d20c6e95bf54c9b8f999abbbf6 ensured that no data
could be read for header-only files regardless of what the Header.Size
said. We should document this fact in Reader.Read.
Dan Peterson [Thu, 19 Nov 2015 19:24:42 +0000 (15:24 -0400)]
net: prefer error for original name on lookups
With certain names and search domain configurations the
returned error would be one encountered while querying a
generated name instead of the original name. This caused
confusion when a manual check of the same name produced
different results.
Now prefer errors encountered for the original name.
Also makes the low-level DNS connection plumbing swappable
in tests enabling tighter control over responses without
relying on the network.
Russ Cox [Thu, 17 Dec 2015 03:52:00 +0000 (22:52 -0500)]
cmd/go: use tags when evaluating file system wildcards like ./...
Thanks to Albert Hafvenström for the diagnosis.
Fixes #11246.
Change-Id: I2b9e670c0ecf6aa01e5bf4d7a402619e93cc4f4a
Reviewed-on: https://go-review.googlesource.com/17942 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Thu, 17 Dec 2015 03:40:15 +0000 (22:40 -0500)]
cmd/go: disable use of -linkmode=external in tests when CGO_ENABLED=0
If cgo is turned off, there may not be an external linker available.
Fixes #13450.
Change-Id: Idbf3f3f57b4bb3908b67264f96d276acc952102a
Reviewed-on: https://go-review.googlesource.com/17941 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Mon, 14 Dec 2015 16:04:03 +0000 (11:04 -0500)]
cmd/go: add -args to 'go test' to resolve -v ambiguity
The new flag -args stops flag processing, leaving the rest of the command line
to be passed to the underlying test binary verbatim. Thus, both of these pass
a literal -v -n on the test binary command line, without putting the go command
into verbose mode or disabling execution of commands:
go test . -args -v -n
go test -args -v -n
Also try to make the documentation a bit clearer.
Fixes #7221.
Fixes #12177.
Change-Id: Ief9e830a6fbb9475d96011716a86e2524a35eceb
Reviewed-on: https://go-review.googlesource.com/17775 Reviewed-by: Rob Pike <r@golang.org>
Change-Id: Ibe9c5f48e3e4cbbbde2f5c8c516b2987ebba55ae
Reviewed-on: https://go-review.googlesource.com/17776 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Minux Ma <minux@golang.org>
Brad Fitzpatrick [Thu, 17 Dec 2015 00:31:56 +0000 (00:31 +0000)]
net/http: update bundled copy of http2, enable TestTrailersServerToClient tests
This CL updates the bundled copy of x/net/http2 to include
https://golang.org/cl/17930 and enables the previously-skipped tests
TestTrailersServerToClient_h2 and TestTrailersServerToClient_Flush_h2.
It also updates the docs on http.Response.Trailer to describe how to
use it. No change in rules. Just documenting the old unwritten rules.
(there were tests locking in the behavior, and misc docs and examples
scattered about, but not on http.Response.Trailer itself)
Adam Langley [Wed, 16 Dec 2015 00:07:47 +0000 (19:07 -0500)]
crypto/rsa: check CRT result.
This change adds a check after computing an RSA signature that the
signature is correct. This prevents an error in the CRT computation from
leaking the private key. See references in the linked bug.
benchmark old ns/op new ns/op delta
BenchmarkRSA2048Sign-3 57133056225215 +8.96%
Alex Brainman [Wed, 16 Dec 2015 23:03:13 +0000 (10:03 +1100)]
net: make windows (*netFD).connect work like its unix version
CL 17821 used syscall.CancelIoEx to cancel outstanding connect
call, but did not check for syscall.CancelIoEx return value.
Also I am worried about introducing race here. We should use
proper tools available for us instead. For example, we could
use fd.setWriteDeadline just like unix version does. Do that.
Russ Cox [Mon, 14 Dec 2015 20:55:44 +0000 (15:55 -0500)]
cmd/compile: fix magic multiply smashing AX
Fixes #12411.
Change-Id: I2202a754c7750e3b2119e3744362c98ca0d2433e
Reviewed-on: https://go-review.googlesource.com/17818 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Mon, 14 Dec 2015 18:42:13 +0000 (13:42 -0500)]
cmd/compile: diagnose invalid switch interface{} case earlier
Fixes #11737.
Change-Id: Id231b502ac5a44035dc3a02515b43bf665cb1e87
Reviewed-on: https://go-review.googlesource.com/17816 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Mon, 14 Dec 2015 19:07:21 +0000 (14:07 -0500)]
cmd/compile: fix export type conversion loss in inlined func body
Fixes #12677.
Change-Id: I72012f55615fcf5f4a16c054706c9bcd82e49ccd
Reviewed-on: https://go-review.googlesource.com/17817 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Fri, 11 Dec 2015 07:49:16 +0000 (02:49 -0500)]
runtime: remove incorrect TODO added in CL 16035
I've already turned away one attempt to remove this field.
As the comment above the struct says, many tools know the layout.
The field cannot simply be removed.
It was one thing to remove the fields name, but the TODO should
not have been added.
Change-Id: If40eacf0eb35835082055e129e2b88333a0731b9
Reviewed-on: https://go-review.googlesource.com/17741 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Fri, 11 Dec 2015 03:34:17 +0000 (22:34 -0500)]
go/build: support vendor directories in Import
This fix, plus a one-line change to golang.org/x/tools/go/loader,
is sufficient to let that loader package process source code
using vendored packages. For example,
GOPATH="" ssadump net/http # uses vendored http2
used to fail, not able to find net/http's import of the vendored
copy of golang.org/x/net/http2/hpack.
This CL plus the fix to loader (CL 17727) suffices to get ssadump working,
as well as - I expect - most other source code processing built
on golang.org/x/tools/go/loader.
Fixes #12278.
Change-Id: I83715e757419171159f67d49bb453636afdd91f0
Reviewed-on: https://go-review.googlesource.com/17726 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Austin Clements [Mon, 14 Dec 2015 23:04:40 +0000 (18:04 -0500)]
runtime: accept NumGC==0 in TestMemStats
TestMemStats currently requires that NumGC != 0, but GC may
legitimately not have run (for example, if this test runs first, or
GOGC is set high, etc). Accept NumGC == 0 and instead sanity check
NumGC by making sure that all pause times after NumGC are 0.
Robert Griesemer [Wed, 16 Dec 2015 18:11:26 +0000 (10:11 -0800)]
cmd/compile: re-vendor math/big so we use latest version in compiler
This simply copies the current version of math/big into the
compiler directory. The change was created automatically by
running cmd/compile/internal/big/vendor.bash. No other manual
changes.
Brad Fitzpatrick [Wed, 16 Dec 2015 16:49:16 +0000 (16:49 +0000)]
net/http: fix Transport race returning bodyless responses and reusing conns
The Transport had a delicate protocol between its readLoop goroutine
and the goroutine calling RoundTrip. The basic concern is that the
caller's RoundTrip goroutine wants to wait for either a
connection-level error (the conn dying) or the response. But sometimes
both happen: there's a valid response (without a body), but the conn
is also going away. Both goroutines' logic dealing with this had grown
large and complicated with hard-to-follow comments over the years.
Simplify and document. Pull some bits into functions and do all
bodyless stuff in one place (it's special enough), rather than having
a bunch of conditionals scattered everywhere. One test is no longer
even applicable since the race it tested is no longer possible (the
code doesn't exist).
The bug that this fixes is that when the Transport reads a bodyless
response from a server, it was returning that response before
returning the persistent connection to the idle pool. As a result,
~1/1000 of serial requests would end up creating a new connection
rather than re-using the just-used connection due to goroutine
scheduling chance. Instead, this now adds bodyless responses'
connections back to the idle pool first, then sends the response to
the RoundTrip goroutine, but making sure that the RoundTrip goroutine
is outside of its select on the connection dying.
There's a new buffered channel involved now, which is a minor
complication, but it's much more self-contained and well-documented
than the previous complexity. (The alternative of making the
responseAndError channel itself unbuffered is too invasive and risky
at this point; it would require a number of changes to avoid
deadlocked goroutines in error cases)
In any case, flakes look to be gone now. We'll see if trybots agree.
Russ Cox [Mon, 14 Dec 2015 18:24:27 +0000 (13:24 -0500)]
cmd/compile: fix -race nit
Fixes #13264.
Change-Id: I74b941164610921a03814733fea08631f18b6178
Reviewed-on: https://go-review.googlesource.com/17815 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ian Lance Taylor [Tue, 15 Dec 2015 23:46:48 +0000 (15:46 -0800)]
runtime: change SIGEMT on linux/mips64 to throw
This matches SIGEMT on other systems that use it (SIGEMT is not used
for most linux systems).
Change-Id: If394c06c9ed1cb3ea2564385a8edfbed8b5566d1
Reviewed-on: https://go-review.googlesource.com/17874
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Minux Ma <minux@golang.org>
Brad Fitzpatrick [Mon, 14 Dec 2015 22:21:48 +0000 (22:21 +0000)]
net: add Dialer.Cancel to cancel pending dials
Dialer.Cancel is a new optional <-chan struct{} channel whose closure
indicates that the dial should be canceled. It is compatible with the
x/net/context and http.Request.Cancel types.
Tested by hand with:
package main
import (
"log"
"net"
"time"
)
func main() {
log.Printf("start.")
var d net.Dialer
cancel := make(chan struct{})
time.AfterFunc(2*time.Second, func() {
log.Printf("timeout firing")
close(cancel)
})
d.Cancel = cancel
c, err := d.Dial("tcp", "192.168.0.1:22")
if err != nil {
log.Print(err)
return
}
log.Fatalf("unexpected connect: %v", c)
}
Brad Fitzpatrick [Tue, 1 Dec 2015 19:07:41 +0000 (19:07 +0000)]
net/http: rework CloseNotifier implementation, clarify expectations in docs
CloseNotifier wasn't well specified previously. This CL simplifies its
implementation, clarifies the public documentation on CloseNotifier,
clarifies internal documentation on conn, and fixes two CloseNotifier
bugs in the process.
The main change, though, is tightening the rules and expectations for using
CloseNotifier:
* the caller must consume the Request.Body first (old rule, unwritten)
* the received value is the "true" value (old rule, unwritten)
* no promises for channel sends after Handler returns (old rule, unwritten)
* a subsequent pipelined request fires the CloseNotifier (new behavior;
previously it never fired and thus effectively deadlocked as in #13165)
* advise that it should only be used without HTTP/1.1 pipelining (use HTTP/2
or non-idempotent browsers). Not that browsers actually use pipelining.
The main implementation change is that each Handler now gets its own
CloseNotifier channel value, rather than sharing one between the whole
conn. This means Handlers can't affect subsequent requests. This is
how HTTP/2's Server works too. The old docs never clarified a behavior
either way. The other side effect of each request getting its own
CloseNotifier channel is that one handler can't "poison" the
underlying conn preventing subsequent requests on the same connection
from using CloseNotifier (this is #9763).
In the old implementation, once any request on a connection used
ClosedNotifier, the conn's underlying bufio.Reader source was switched
from the TCPConn to the read side of the pipe being fed by a
never-ending copy. Since it was impossible to abort that never-ending
copy, we could never get back to a fresh state where it was possible
to return the underlying TCPConn to callers of Hijack. Now, instead of
a never-ending Copy, the background goroutine doing a Read from the
TCPConn (or *tls.Conn) only reads a single byte. That single byte
can be in the request body, a socket timeout error, io.EOF error, or
the first byte of the second body. In any case, the new *connReader
type stitches sync and async reads together like an io.MultiReader. To
clarify the flow of Read data and combat the complexity of too many
wrapper Reader types, the *connReader absorbs the io.LimitReader
previously used for bounding request header reads. The
liveSwitchReader type is removed. (an unused switchWriter type is also
removed)
Many fields on *conn are also documented more fully.
Austin Clements [Mon, 14 Dec 2015 22:25:28 +0000 (17:25 -0500)]
runtime: only trigger forced GC if GC is not running
Currently, sysmon triggers a forced GC solely based on
memstats.last_gc. However, memstats.last_gc isn't updated until mark
termination, so once sysmon starts triggering forced GC, it will keep
triggering them until GC finishes. The first of these actually starts
a GC; the remainder up to the last print "GC forced", but gcStart
returns immediately because gcphase != _GCoff; then the last may start
another GC if the previous GC finishes (and sets last_gc) between
sysmon triggering it and gcStart checking the GC phase.
Fix this by expanding the condition for starting a forced GC to also
require that no GC is currently running. This, combined with the way
forcegchelper blocks until the GC cycle is started, ensures sysmon
only starts one GC when the time exceeds the forced GC threshold.
Austin Clements [Mon, 23 Nov 2015 20:13:16 +0000 (15:13 -0500)]
runtime: simplify sigprof traceback interlocking
The addition of stack barrier locking to copystack subsumes the
partial fix from commit bbd1a1c for SIGPROF during copystack. With the
stack barrier locking, this commit simplifies the rule in sigprof to:
the user stack can be traced only if sigprof can acquire the stack
barrier lock.
Matthew Dempsky [Mon, 14 Dec 2015 20:37:26 +0000 (12:37 -0800)]
cmd/compile: change dead code into assert
After fixing #13587, I noticed that the "OAS2FUNC in disguise" block
looked like it probably needed write barriers too. However, testing
revealed the multi-value "return f()" case was already being handled
correctly.
It turns out this block is dead code due to "return f()" already being
transformed into "t1, t2, ..., tN := f(); return t1, t2, ..., tN" by
orderstmt when f is a multi-valued function.
Updates #13587.
Change-Id: Icde46dccc55beda2ea5fd5fcafc9aae26cec1552
Reviewed-on: https://go-review.googlesource.com/17759
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Austin Clements [Mon, 14 Dec 2015 20:38:12 +0000 (15:38 -0500)]
runtime: update triggerRatio in setGCPercent
Currently, runtime/debug.SetGCPercent does not adjust the controller
trigger ratio. As a result, runtime reductions of GOGC don't take full
effect until after one more concurrent cycle has happened, which
adjusts the trigger ratio to account for the new gcpercent.
Fix this by lowering the trigger ratio if necessary in setGCPercent.
Austin Clements [Mon, 14 Dec 2015 20:19:07 +0000 (15:19 -0500)]
runtime: print gctrace before releasing worldsema
Currently we drop worldsema and then print the gctrace. We did this so
that if stderr is a pipe or a blocked terminal, blocking on printing
the gctrace would not block another GC from starting. However, this is
a bit of a fool's errand because a blocked runtime print will block
the whole M/P, so after GOMAXPROCS GC cycles, the whole system will
freeze. Furthermore, now this is much less of an issue because
allocation will block indefinitely if it can't start a GC (whereas it
used to be that allocation could run away). Finally, this allows
another GC cycle to start while the previous cycle is printing the
gctrace, which leads to races on reading various statistics to print
them and the next GC cycle overwriting those statistics.
Fix this by moving the release of worldsema after the gctrace print.
Austin Clements [Mon, 14 Dec 2015 20:07:40 +0000 (15:07 -0500)]
runtime: reset sweep stats before starting the world
Currently we reset the sweep stats just after gcMarkTermination starts
the world and releases worldsema. However, background sweeping can
start the moment we start the world and, in fact, pause sweeping can
start the moment we release worldsema (because another GC cycle can
start up), so these need to be cleared before starting the world.
Austin Clements [Fri, 11 Dec 2015 22:49:14 +0000 (17:49 -0500)]
runtime: fix (sometimes major) underestimation of heap_live
Currently, we update memstats.heap_live from mcache.local_cachealloc
whenever we lock the heap (e.g., to obtain a fresh span or to release
an unused span). However, under the right circumstances,
local_cachealloc can accumulate allocations up to the size of
the *entire heap* without flushing them to heap_live. Specifically,
since span allocations from an mcentral don't lock the heap, if a
large number of pages are held in an mcentral and the application
continues to use and free objects of that size class (e.g., the
BinaryTree17 benchmark), local_cachealloc won't be flushed until the
mcentral runs out of spans.
This is a problem because, unlike many of the memory statistics that
are purely informative, heap_live is used to determine when the
garbage collector should start and how hard it should work.
This commit eliminates local_cachealloc, instead atomically updating
heap_live directly. To control contention, we do this only when
obtaining a span from an mcentral. Furthermore, we make heap_live
conservative: allocating a span assumes that all free slots in that
span will be used and accounts for these when the span is
allocated, *before* the objects themselves are. This is important
because 1) this triggers the GC earlier than necessary rather than
potentially too late and 2) this leads to a conservative GC rate
rather than a GC rate that is potentially too low.
Alternatively, we could have flushed local_cachealloc when it passed
some threshold, but this would require determining a threshold and
would cause heap_live to underestimate the true value rather than
overestimate.
Austin Clements [Fri, 11 Dec 2015 17:33:34 +0000 (12:33 -0500)]
runtime: deduct correct sweep credit
deductSweepCredit expects the size in bytes of the span being
allocated, but mCentral_CacheSpan passes the size of a single object
in the span. As a result, we don't sweep enough on that call and when
mCentral_CacheSpan later calls reimburseSweepCredit, it's very likely
to underflow mheap_.spanBytesAlloc, which causes the next call to
deductSweepCredit to think it owes a huge number of pages and finish
off the whole sweep.
In addition to causing the occasional allocation that triggers the
full sweep to be potentially extremely expensive relative to other
allocations, this can indirectly slow down many other allocations.
deductSweepCredit uses sweepone to sweep spans, which returns
fully-unused spans to the heap, where these spans are freed and
coalesced with neighboring free spans. On the other hand, when
mCentral_CacheSpan sweeps a span, it does so with the intent to
immediately reuse that span and, as a result, will not return the span
to the heap even if it is fully unused. This saves on the cost of
locking the heap, finding a span, and initializing that span. For
example, before this change, with GOMAXPROCS=1 (or the background
sweeper disabled) BinaryTree17 returned roughly 220K spans to the heap
and allocated new spans from the heap roughly 232K times. After this
change, it returns 1.3K spans to the heap and allocates new spans from
the heap 39K times. (With background sweeping these numbers are
effectively unchanged because the background sweeper sweeps almost all
of the spans with sweepone; however, parallel sweeping saves more than
the cost of allocating spans from the heap.)
Robert Griesemer [Thu, 3 Dec 2015 01:41:39 +0000 (17:41 -0800)]
go/constant: switch to floating-point representation when fractions become too large
Use two internal representations for Float values (similar to what is done
for Int values). Transparently switch to a big.Float representation when
big.Rat values become unwieldy. This is almost never needed for real-world
programs but it is trivial to create test cases that cannot be handled with
rational arithmetic alone.
As a consequence, the go/constant API semantics changes slightly: Until now,
a value could always be represented in its "smallest" form (e.g., float values
that happened to be integers would be represented as integers). Now, constant
Kind depends on how the value was created, rather than its actual value. (The
reason why we cannot automatically "normalize" values to their smallest form
anymore is because floating-point numbers are not exact in general; and thus
normalization is often not possible in the first place, or would throw away
precision when it is not desired.) This has repercussions as to how constant
Values are used go/types and required corresponding adjustments.
Details of the changes:
go/constant package:
- use big.Rat and big.Float values to represent floating-point values
(internal change)
- changed semantic of Value.Kind accordingly
- String now returns a short, human-readable form of a value
(this leads to better error messages in go/types)
- added ToInt, ToFloat, and ToComplex conversion functions
- added ExactString to obtain an exact string form of a value
go/types:
- adjusted and simplified implementation of representableConst
- adjusted various places where Value.Kind was expected to be "smallest"
by calling the respective ToInt/Float/Complex conversion functions
- enabled 5 disabled tests in stdlib_test.go that now work
api checker:
- print all constant values in a short human-readable form (floats are
printed in floating-point form), but also print an exact form if it
is different from the short form
- adjusted test golden file and go.1.1.text reference file
Fixes #11327.
Change-Id: I492b704aae5b0238e5b7cee13e18ffce61193587
Reviewed-on: https://go-review.googlesource.com/17360 Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Austin Clements [Mon, 14 Dec 2015 19:30:25 +0000 (14:30 -0500)]
runtime: recycle large stack spans
To prevent races with the garbage collector, stack spans cannot be
reused as heap spans during a GC. We deal with this by caching stack
spans during GC and releasing them at the end of mark termination.
However, while our cache lets us reuse small stack spans, currently
large stack spans are *not* reused. This can cause significant memory
growth in programs that allocate large stacks rapidly, but grow the
heap slowly (such as in issue #13552).
Fix this by adding logic to reuse large stack spans for other stacks.
Fixes #11466.
Fixes #13552. Without this change, the program in this issue creeps to
over 1GB of memory over the course of a few hours. With this change,
it stays rock solid at around 30MB.
Change-Id: If8b2d85464aa80c96230a1990715e39aa803904f
Reviewed-on: https://go-review.googlesource.com/17814 Reviewed-by: Keith Randall <khr@golang.org>
Brad Fitzpatrick [Mon, 14 Dec 2015 01:04:07 +0000 (01:04 +0000)]
net/http: fix race in TimeoutHandler
New implementation of TimeoutHandler: buffer everything to memory.
All or nothing: either the handler finishes completely within the
timeout (in which case the wrapper writes it all), or it misses the
timeout and none of it gets written, in which case handler wrapper can
reliably print the error response without fear that some of the
wrapped Handler's code already wrote to the output.
Now the goroutine running the wrapped Handler has its own write buffer
and Header copy.
At present, the series of File{Conn,Listener,PacketConn} APIs are the
only way to configure platform-specific socket options such as
SO_REUSE{ADDR,PORT}, TCP_FASTOPEN. This change adds missing test cases
that test read and write operations on connections created by File APIs
and removes redundant parameter tests which are already tested in
server_test.go.
Also adds comment on full stack test cases for IPConn.
Fixes #10730.
Change-Id: I67abb083781b602e876f72a6775a593c0f363c38
Reviewed-on: https://go-review.googlesource.com/17476 Reviewed-by: Ian Lance Taylor <iant@golang.org>
David Chase [Wed, 9 Dec 2015 16:45:36 +0000 (11:45 -0500)]
math/rand: improve uniformity of rand.Float64,Float32
Replaced code that substituted 0 for rounded-up 1 with
code to try again. This has minimal effect on the existing
stream of random numbers, but restores uniformity.
Dmitry Vyukov [Tue, 8 Dec 2015 14:11:27 +0000 (15:11 +0100)]
runtime: remove unnecessary wakeups of worker threads
Currently we wake up new worker threads whenever we pass
through the scheduler with nmspinning==0. This leads to
lots of unnecessary thread wake ups.
Instead let only spinning threads wake up new spinning threads.
For the following program:
package main
import "runtime"
func main() {
for i := 0; i < 1e7; i++ {
runtime.Gosched()
}
}
Before:
$ time ./test
real 0m4.278s
user 0m7.634s
sys 0m1.423s
Russ Cox [Fri, 11 Dec 2015 03:28:15 +0000 (03:28 +0000)]
Revert "fmt: check newline in the end of input"
This change can break real code. There are other newline-related bugs in this code, and fixing them will also break real code. If we're going to break real code, let's fix all the bugs together and just break things once.
Russ Cox [Fri, 4 Dec 2015 17:43:25 +0000 (12:43 -0500)]
net/url: reject space in host; do not escape < > " in host
Host names in URLs must not use %-escaping for ASCII bytes, per RFC 3986.
url.Parse has historically allowed spaces and < > " in the URL host.
In Go 1.5, URL's String method started escaping those,
but then Parse would rejects the escaped form.
This CL is an attempt at some consistency between Parse and String
as far as the accepted host characters and the encoding of host characters,
so that if Parse succeeds, then Parse -> String -> Parse also succeeds.
Allowing space seems like a mistake, so reject that in Parse.
(Similarly, reject \t, \x01, and so on, all of which were being allowed.)
Allowing < > " doesn't seem awful, so continue to do that,
and go back to the Go 1.4 behavior of not escaping them in String.
Russ Cox [Sat, 5 Dec 2015 06:15:26 +0000 (01:15 -0500)]
net: do not unlink unix socket in UnixListener created from fd
Fixes #11826.
Change-Id: Id220dd558ca8d8d78c01975087122d27757deea0
Reviewed-on: https://go-review.googlesource.com/17458 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Rahul Chaudhry [Thu, 10 Dec 2015 23:06:42 +0000 (15:06 -0800)]
runtime: fix GODEBUG=schedtrace=X delay handling.
debug.schedtrace is an int32. Convert it to int64 before
multiplying with constant 1000000. Otherwise, schedtrace
values more than 2147 result in int32 overflow causing
incorrect delays between traces.
Change-Id: I064e8d7b432c1e892a705ee1f31a2e8cdd2c3ea3
Reviewed-on: https://go-review.googlesource.com/17712 Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Russ Cox [Mon, 7 Dec 2015 14:52:31 +0000 (09:52 -0500)]
math/big: fix misuse of Unicode
ˆ (U+02C6) is a circumflex accent, not an exponentiation operator.
In the rest of the source code for this package, exponentation is
written as **, so do the same here.
Change-Id: I107b85be242ab79d152eb8a6fcf3ca2b197d7658
Reviewed-on: https://go-review.googlesource.com/17671 Reviewed-by: Robert Griesemer <gri@golang.org>
Keith Randall [Thu, 3 Dec 2015 21:20:58 +0000 (13:20 -0800)]
cmd/compile: captureless closures are constants
In particular, we can initialize globals with them at link time instead
of generating code for them in an init() function. Less code, less
startup cost.
But the real reason for this change is binary size. This change reduces
the binary size of hello world by ~4%.
The culprit is fmt.ssFree, a global variable which is a sync.Pool of
scratch scan states. It is initalized with a captureless closure as the
pool's New action. That action in turn references all the scanf code.
If you never call any of the fmt.Scanf* routines, ssFree is never used.
But before this change, ssFree is still referenced by fmt's init
function. That keeps ssFree and all the code it references in the
binary. With this change, ssFree is initialized at link time. As a
result, fmt.init never mentions ssFree. If you don't call fmt.Scanf*,
ssFree is unreferenced and it and the scanf code are not included.
This change is an easy fix for what is generally a much harder problem,
the unnecessary initializing of unused globals (and retention of code
that they reference). Ideally we should have separate init code for
each global and only include that code if the corresponding global is
live. (We'd need to make sure that the initializing code has no side
effects, except on the global being initialized.) That is a much harder
change.
Brad Fitzpatrick [Thu, 10 Dec 2015 18:24:03 +0000 (10:24 -0800)]
net/http: make NewRequest with empty method mean GET
Until recently, we always permitted an empty string to NewRequest.
Keep that property, since it broke tests within in Google when trying
out Go 1.6, and probably would've broken others too.
Rob Pike [Wed, 9 Dec 2015 22:39:26 +0000 (14:39 -0800)]
cmd/doc: search the tree in breadth-first order
This is a simple change to the command that should resolve problems like finding
vendored packages before their non-vendored siblings. By searching in breadth-first
order, we find the matching package lowest in the hierarchy, which is more likely
to be correct than the deeper one, such as a vendored package, that will be found
in a depth-first scan.
This may be sufficient to resolve the issue, and has the merit that it is very easy
to explain. I will leave the issue open for now in case my intuition is wrong.
Mikio Hara [Fri, 4 Dec 2015 10:06:01 +0000 (19:06 +0900)]
net, internal/syscall/windows: fix interface and address identification on windows
The current implementation including Go 1.5 through 1.5.2 misuses
Windows API and mishandles the returned values from GetAdapterAddresses
on Windows. This change fixes various issues related to network facility
information by readjusting interface and interface address parsers.
Also fixes fragile screen scraping test cases in net_windows_test.go.
Additional information for reviewers:
It seems like almost all the issues above have the same root cause and
it is misunderstanding of Windows API. If my interpretation of the
information on MSDN is correctly, current implementation contains the
following bugs:
- SIO_GET_INTERFACE_LIST should not be used for IPv6. The behavior of
SIO_GET_INTERFACE_LIST is different on kernels and probably it doesn't
work correctly for IPv6 on old kernels such as Windows XP w/ SP2.
Unfortunately MSDN doesn't describe the detail of
SIO_GET_INTERFACE_LIST, but information on the net suggests so.
- Fetching IP_ADAPTER_ADDRESSES structures with fixed size area may not
work when using IPv6. IPv6 generates ton of interface addresses for
various addressing scopes. We need to adjust the area appropriately.
- PhysicalAddress field of IP_ADAPTER_ADDRESSES structure may have extra
space. We cannot ignore PhysicalAddressLength field of
IP_ADAPTER_ADDRESS structure.
- Flags field of IP_ADAPTER_ADDRESSES structure doesn't represent any of
administratively and operatinal statuses. It just represents settings
for windows network adapter.
- MTU field of IP_ADAPTER_ADDRESSES structure may have a uint32(-1) on
64-bit platform. We need to convert the value to interger
appropriately.
- IfType field of IP_ADAPTER_ADDRESSES structure is not a bit field.
Bitwire operation for the field is completely wrong.
- OperStatus field of IP_ADAPTER_ADDRESSES structure is not a bit field.
Bitwire operation for the field is completely wrong.
- IPv6IfIndex field of IP_ADAPTER_ADDRESSES structure is just a
substitute for IfIndex field. We cannot prefer IPv6IfIndex to IfIndex.
- Windows XP, 2003 server and below don't set OnLinkPrefixLength field
of IP_ADAPTER_UNICAST_ADDRESS structure. We cannot rely on the field
on old kernels. We can use FirstPrefix field of IP_ADAPTER_ADDRESSES
structure and IP_ADAPTER_PREFIX structure instead.
- Length field of IP_ADAPTER_{UNICAST,ANYCAST,MULTICAST}_ADDRESS
sturecures doesn't represent an address prefix length. It just
represents a socket address length.
Change-Id: Icabdaf7bd1d41360a981d2dad0b830b02b584528
Reviewed-on: https://go-review.googlesource.com/17412 Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Brad Fitzpatrick [Wed, 9 Dec 2015 22:02:46 +0000 (22:02 +0000)]
net/http: run more tests in http2 mode
Failing ones are marked skipped.
Fixes #13543 (was just a test issue)
Updates #13555 (to be fixed later)
Updates #13556 (to be fixed later)
Updates #13557 (to be fixed later)
Fixes bug in golang.org/cl/17428 (http1 now uses HTTP status 431, not 413)