This CL makes NewRequest set Body nil for known-zero bodies, and makes
the http1 Transport not peek-Read a byte to determine whether there's
a body.
Background:
Many fields of the Request struct have different meanings for whether
they're outgoing (via the Transport) or incoming (via the Server).
For outgoing requests, ContentLength and Body are documented as:
// Body is the request's body.
//
// For client requests a nil body means the request has no
// body, such as a GET request. The HTTP Client's Transport
// is responsible for calling the Close method.
Body io.ReadCloser
// ContentLength records the length of the associated content.
// The value -1 indicates that the length is unknown.
// Values >= 0 indicate that the given number of bytes may
// be read from Body.
// For client requests, a value of 0 with a non-nil Body is
// also treated as unknown.
ContentLength int64
Because of the ambiguity of what ContentLength==0 means, the http1 and
http2 Transports previously Read the first byte of a non-nil Body when
the ContentLength was 0 to determine whether there was an actual body
(with a non-zero length) and ContentLength just wasn't populated, or
it was actually empty.
That byte-sniff has been problematic and gross (see #17480, #17071)
and was removed for http2 in a previous commit.
That means, however, that users doing:
req, _ := http.NewRequest("POST", url, strings.NewReader(""))
... would not send a Content-Length header in their http2 request,
because the size of the reader (even though it was known, being one of
the three common recognized types from NewRequest) was zero, and so
the HTTP Transport thought it was simply unset.
To signal explicitly-zero vs unset-zero, this CL changes NewRequest to
signal explicitly-zero by setting the Body to nil, instead of the
strings.NewReader("") or other zero-byte reader.
This CL also removes the byte sniff from the http1 Transport, like
https://golang.org/cl/31326 did for http2.
Updates #17480
Updates #17071
Change-Id: I329f02f124659bf7d8bc01e2c9951ebdd236b52a
Reviewed-on: https://go-review.googlesource.com/31445
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This was supposed to be in CL 31354
but was dropped due to a Git usage error.
For #16573.
Change-Id: I3d99087c8efc8cbc016c55e8365d0005f79d1b2f
Reviewed-on: https://go-review.googlesource.com/31461
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Make two important points clearer:
- Giving a template definition containing
nothing but spaces has no effect.
- Giving a template definition containing
non-spaces can only be done once per template.
Fixes#16912.
Fixes#16913.
Fixes#17360.
Change-Id: Ie3971b83ab148b7c8bb800fe4a21579566378e3e
Reviewed-on: https://go-review.googlesource.com/31459
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
Implements Float.Scan which satisfies fmt.Scanner interface.
Also enforces docs' interface implementation claims with compile time
type assertions, that is:
+ Float always implements fmt.Formatter and fmt.Scanner
+ Int always implements fmt.Formatter and fmt.Scanner
+ Rat always implements fmt.Formatter
which will ensure that the API claims are strictly matched.
Also note that Float.Scan doesn't handle ±Inf.
Fixes#17391
Change-Id: I3d3dfbe7f602066975c7a7794fe25b4c645440ce
Reviewed-on: https://go-review.googlesource.com/30723
Reviewed-by: Robert Griesemer <gri@golang.org>
For example, testing the current directory:
$ go test -run XXX
testing: warning: no tests to run
PASS
ok testing 0.013s
$
And in a summary:
$ go test -run XXX testing
ok testing 0.013s [no tests to run]
$
These make it easy to spot when the -run regexp hasn't matched anything
or there are no tests. Previously the message was printed in the "current directory"
case when there were no tests at all, but not for no matches, and either way
was not surfaced in the directory list summary form.
Fixes#15211.
Change-Id: I1c82a423d6bd429fb991c9ca964c9d26c96fd3c5
Reviewed-on: https://go-review.googlesource.com/22341
Reviewed-by: Marcel van Lohuizen <mpvl@golang.org>
Current implementation of syscall.Readlink mistakenly calculates
the end offset of the PrintName field.
Also, there are some cases that the PrintName field is empty.
Instead, the CL uses SubstituteName with correct calculation.
Fixes#15978Fixes#16145
Change-Id: If3257137141129ac1c552d003726d5b9c08bb754
Reviewed-on: https://go-review.googlesource.com/31118
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Unix rejects this when new is a non-empty directory.
Other systems reject this when new is a directory, empty or not.
Make Unix reject empty directory too.
Fixes#14527.
Change-Id: Ice24b8065264c91c22cba24aa73e142386c29c87
Reviewed-on: https://go-review.googlesource.com/31358
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A 16bit binary exponent permits a constant range covering roughly the range
from 7e-9865 to 7e9863 which is more than enough for any practical and
hypothetical constant arithmetic.
Furthermore, until recently cmd/compile could not handle very large exponents
correctly anyway; i.e., the chance that any real programs (but for tests that
explore corner cases) are affected are close to zero.
Finally, restricting the minimum supported range significantly reduces the
implementation complexity in an area that hardly matters in reality for new
or alternative spec-compliant implementations that don't or cannot rely on
pre-existing arbitratry precision arithmetic packages that support a 32bit
exponent range.
This is technically a language change but for the reasons mentioned above
this is unlikely to affect any real programs, and certainly not programs
compiled with the gc or gccgo compilers as they currently support up to
32bit exponents.
Fixes#13572.
Change-Id: I970f919c57fc82c0175844364cf48ea335f17d39
Reviewed-on: https://go-review.googlesource.com/17711
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reuse the same mechanisms for handling universal builtins like len to
handle unsafe.Sizeof, etc. Allows us to drop package unsafe's export
data, and simplifies some code.
Updates #17508.
Change-Id: I620e0617c24e57e8a2d7cccd0e2de34608779656
Reviewed-on: https://go-review.googlesource.com/31433
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Add special case for Gamma(+∞) which speeds it up:
benchmark old ns/op new ns/op delta
BenchmarkGamma-4 14.5 7.44 -48.69%
The documentation for math.Gamma already specifies it as a special
case:
Gamma(+Inf) = +Inf
The original C code that has been used as the reference implementation
(as mentioned in the comments in gamma.go) also treats Gamma(+∞) as a
special case:
if( x == INFINITY )
return(x);
Change-Id: Idac36e19192b440475aec0796faa2d2c7f8abe0b
Reviewed-on: https://go-review.googlesource.com/31370
Reviewed-by: Robert Griesemer <gri@golang.org>
The way to send an explicitly-zero Content-Length is to set a nil Body.
Fix this test to do that, rather than relying on type sniffing.
Updates #17480
Updates #17071
Change-Id: I6a38e20f17013c88ec4ea69d73c507e4ed886947
Reviewed-on: https://go-review.googlesource.com/31434
TryBot-Result: Gobot Gobot <gobot@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Chris Broadfoot <cbro@golang.org>
"go env" previously only printed a subset of the documented environment
variables; now it includes everything, such as GO386 and CGO_*.
This also fixes the CGO_CFLAGS environment variable to always have the
same default. According to iant@ and confirmed by testing, cgo can now
understand the default value of CGO_CFLAGS.
Fixes#17191.
Change-Id: Icf75055446dd250b6256ef1139e9ce848f4a9d3b
Reviewed-on: https://go-review.googlesource.com/31330
TryBot-Result: Gobot Gobot <gobot@golang.org>
Run-TryBot: Quentin Smith <quentin@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
instrumentnode() accidentally copies parent's already-instrumented nodes
into child's Ninit block. This generates repeated code in race-instrumentation.
This case surfaces only when it duplicates inline-labels, because of
compile time error. In other cases, it silently generates incorrect
instrumented code. This change prevents it from doing so.
Fixes#17449.
Change-Id: Icddf2198990442166307e176b7e20aa0cf6c171c
Reviewed-on: https://go-review.googlesource.com/31317
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Interface methods can't have function bodies, so there's no need to
process their parameter lists as variable declarations. The only
possible reason would be to check for duplicate parameter names and/or
invalid types, but we do that anyway, and have regression tests for it
(test/funcdup.go).
Change-Id: Iedb15335467caa5d872dbab829bf32ab8cf6204d
Reviewed-on: https://go-review.googlesource.com/31430
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This change omits the stack check on ppc64 and s390x when the size of
a stack frame is less than obj.StackSmall. This is an optimization
x86 already performs.
The effect on s390x isn't huge because we were already omitting the
stack check when the frame size was 0 (it shaves about 1K from the
size of bin/go). On ppc64 however this change reduces the size of the
.text section in bin/go by 33K (1%).
Updates #13379 (for ppc64).
Change-Id: I6af0eb987646bea47fcaf0a812db3496bab0f680
Reviewed-on: https://go-review.googlesource.com/31357
Reviewed-by: David Chase <drchase@google.com>
This issue has been fixed in CL 31390.
Fixes#11476.
Change-Id: I6658bda2e494d3239d62c49d0bd5d34a36b744d0
Reviewed-on: https://go-review.googlesource.com/31394
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Previously, in acceptPlan9 we set netFD.ctl to the listener's
/net/tcp/*/listen file instead of the accepted connection's
/net/tcp/*/ctl file.
In netFD.Read, we write "close" to netFD.ctl to close the
connection and wake up the readers. However, in the
case of an accepted connection, we got the error
"write /net/tcp/*/listen: inappropriate use of fd"
because the /net/tcp/*/listen doesn't handle the "close" message.
In this case, the connection wasn't closed and the readers
weren't awake.
We modified the netFD structure so that netFD.ctl represents
the accepted connection and netFD.listen represents the
listener.
Change-Id: Ie38c7dbaeaf77fe9ff7da293f09e86d1a01b3e1e
Reviewed-on: https://go-review.googlesource.com/31390
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
- Like ",any" for elements, add ",any,attr" for attributes to allow
a mop-up field that gets any otherwise unmapped attributes.
- Map attributes to fields of type slice by extending the slice,
just like for elements.
- Allow storing an attribute into an xml.Attr directly, to provide
a way to record the name.
Combined, these three independent features allow
AllAttrs []Attr `xml:",any,attr"`
to collect all attributes not otherwise spoken for in a particular struct.
Tests based on CL 16292 by Charles Weill.
Fixes#3633.
Change-Id: I2d75817f17ca8752d7df188080a407836af92611
Reviewed-on: https://go-review.googlesource.com/30946
Reviewed-by: Quentin Smith <quentin@golang.org>
Previously, we used to write the "hangup" message to
the TCP connection control file to be able to close
a connection, while waking up the readers.
The "hangup" message closes the TCP connection with a
RST message. This is a problem when closing a connection
consecutively to a write, because the reader may not have
time to acknowledge the message before the connection is
closed, resulting in loss of data.
We use a "close" message, newly implemented in the Plan 9
kernel to be able to close a TCP connection gracefully with a FIN.
Updates #15464.
Change-Id: I2050cc72fdf7a350bc6c9128bae7d14af11e599c
Reviewed-on: https://go-review.googlesource.com/31271
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The comments added for Go 1.7 are very close.
Make explicit that they only apply if the timer is
not known to have expired already.
Fixes#14038.
Change-Id: I6a38be7b2015e1571fc477e18444a8cee38aab29
Reviewed-on: https://go-review.googlesource.com/31350
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
cmd.StdinPipe returns an io.WriteCloser.
It's reasonable to expect the caller not to call Write and Close simultaneously,
but there is an implicit Close in cmd.Wait that's not obvious.
We already synchronize the implicit Close in cmd.Wait against
any explicit Close from the caller. Also synchronize that implicit
Close against any explicit Write from the caller.
Fixes#9307.
Change-Id: I8561e9369d6e5ac88dfbca1175549f6dfa04b8ac
Reviewed-on: https://go-review.googlesource.com/31148
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In the zero Time, the (not user visible) nil *Location indicates UTC.
In the result of t.UTC() and other ways to create times in specific
zones, UTC is indicated by a non-nil *Location, specifically &utcLoc.
This creates a representation ambiguity exposed by comparison with ==
or reflect.DeepEqual or the like.
Change time.Time representation to use only nil, never &utcLoc,
to represent UTC. This eliminates the ambiguity.
Fixes#15716.
Change-Id: I7dcc2c20ce6b073e1daae323d3e49d17d1d52802
Reviewed-on: https://go-review.googlesource.com/31144
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This change documents that the InterfaceAddrs function is less usable on
multi-homed IP nodes because of the lack of network interface
identification information.
Also updates documentation on exposed network interface API.
Fixes#14518.
Change-Id: I5e86606f8019ab475eb5d385bd797b052cba395d
Reviewed-on: https://go-review.googlesource.com/31371
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Creates a ColumnType structure that can be extended in to future.
Allow drivers to implement what makes sense for the database.
Fixes#16652
Change-Id: Ieb1fd64eac1460107b1d3474eba5201fa300a4ec
Reviewed-on: https://go-review.googlesource.com/29961
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Check for and call the special printing and format methods such as String
at printing depth 0 when printing the concrete value of a reflect.Value.
Fixes: #16015
Change-Id: I23bd2927255b60924e5558321e98dd4a95e11c4c
Reviewed-on: https://go-review.googlesource.com/30753
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Martin Möhrmann <martisch@uos.de>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This CL changes how the http1 Server reads from the client.
The goal of this change is to make the Request.Context given to Server
Handlers become done when the TCP connection dies (has seen any read
or write error). I didn't finish that for Go 1.7 when Context was
added to http package.
We can't notice the peer disconnect unless we're blocked in a Read
call, though, and previously we were only doing read calls as needed,
when reading the body or the next request. One exception to that was
the old pre-context CloseNotifier mechanism.
The implementation of CloseNotifier has always been tricky. The past
few releases have contained the complexity and moved the
reading-from-TCP-conn logic into the "connReader" type. This CL
extends connReader to make sure that it's always blocked in a Read
call, at least once the request body has been fully consumed.
In the process, this deletes all the old CloseNotify code and unifies
it with the context cancelation code. The two notification mechanisms
are nearly identical, except the CloseNotify path always notifies on
the arrival of pipelined HTTP/1 requests. We might want to change that
in a subsequent commit. I left a TODO for that. For now there's no
change in behavior except that the context now cancels as it was
supposed to.
As a bonus that fell out for free, a Handler can now use CloseNotifier
and Hijack together in the same request now.
Fixes#15224 (make http1 Server always in a Read, like http2)
Fixes#15927 (cancel context when underlying connection closes)
Updates #9763 (CloseNotifier + Hijack)
Change-Id: I972cf6ecbab7f1230efe8cc971e89f8e6e56196b
Reviewed-on: https://go-review.googlesource.com/31173
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change enables the ChaCha20-Poly1305 cipher suites by default. This
changes the default ClientHello and thus requires updating all the
tests.
Change-Id: I6683a2647caaff4a11f9e932babb6f07912cad94
Reviewed-on: https://go-review.googlesource.com/30958
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
GetConfigForClient allows the tls.Config to be updated on a per-client
basis.
Fixes#16066.
Fixes#15707.
Fixes#15699.
Change-Id: I2c675a443d557f969441226729f98502b38901ea
Reviewed-on: https://go-review.googlesource.com/30790
Run-TryBot: Adam Langley <agl@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It's the same as %#x not %x.
Just a documentation change; tests already cover it.
Fixes#17322
Change-Id: Ia9db229f781f9042ac5c0bb824e3d7a26fb74ec5
Reviewed-on: https://go-review.googlesource.com/31254
Reviewed-by: Russ Cox <rsc@golang.org>
In addition to the DecimalConversion benchmark, that exercises the
String method of the internal decimal type on a range of small shifts,
add a few benchmarks for the big.Float String method. They can be used
to obtain more realistic data on the real-world performance of
big.Float printing.
Change-Id: I7ada324e7603cb1ce7492ccaf3382db0096223ba
Reviewed-on: https://go-review.googlesource.com/31275
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
