Ian Lance Taylor [Tue, 12 Jan 2016 23:34:03 +0000 (15:34 -0800)]
runtime: minimize time between lockextra/unlockextra
This doesn't fix a bug, but may improve performance in programs that
have many concurrent calls from C to Go. The old code made several
system calls between lockextra and unlockextra. That could be happening
while another thread is spinning acquiring lockextra. This changes the
code to not make any system calls while holding the lock.
Austin Clements [Wed, 13 Jan 2016 20:14:26 +0000 (15:14 -0500)]
runtime: fix several issues in TestFutexsleep
TestFutexsleep is supposed to clean up before returning by waking up
the goroutines it started and left blocked in futex sleeps. However,
it currently fails at this in several ways:
1. Both the sleep and wakeup are done on the address of tt.mtx, but in
both cases tt is a *local copy* of the futexsleepTest created by a
loop, so the sleep and wakeup happen on completely different
addresses. Fix this by making them both use the address of the
global tt.mtx.
2. If the sleep happens after the wakeup (not likely, but not
impossible), it won't wake up. Fix this by using the futex protocol
properly: sleep if the mutex's value is 0, and set the mutex's
value to non-zero before doing the wakeup.
3. If TestFutexsleep runs more than once, channels and mutex values
left over from the first run will interfere with later runs. Fix
this by clearing the mutex value and creating a new channel for
each test and waiting for goroutines to finish before returning
(lest they send their completion to the channel for the next run).
As an added bonus, this test now actually tests that futex
sleep/wakeup work. Previously this test would have been satisfied if
futexsleep was an infinite loop and futexwakeup was a no-op.
Change-Id: I1cbc6871cc9dcb8f4601b3621913bec2b79b0fc3
Reviewed-on: https://go-review.googlesource.com/18617 Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Mikio Hara <mikioh.mikioh@gmail.com>
Austin Clements [Fri, 8 Jan 2016 21:25:29 +0000 (16:25 -0500)]
debug/dwarf: fix nil pointer dereference in cyclic type structures
Currently readType simultaneously constructs a type graph and resolves
the sizes of the types. However, these two operations are
fundamentally at odds: the order we parse a cyclic structure in may be
different than the order we need to resolve type sizes in. As a
result, it's possible that when readType attempts to resolve the size
of a typedef, it may dereference a nil Type field of another typedef
retrieved from the type cache that's only partially constructed.
To fix this, we delay resolving typedef sizes until the end of the
readType recursion, when the full type graph is constructed.
Russ Cox [Tue, 5 Jan 2016 14:27:40 +0000 (09:27 -0500)]
cmd/internal/obj: separate code layout from object writing
This will allow the compiler to crunch Prog lists down to code as each
function is compiled, instead of waiting until the end, which should
reduce the working set of the compiler. But not until Go 1.7.
This also makes it easier to write some machine code output tests
for the assembler, which is why it's being done now.
For #13822.
Change-Id: I0811123bc6e5717cebb8948f9cea18e1b9baf6f7
Reviewed-on: https://go-review.googlesource.com/18311 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Wed, 13 Jan 2016 05:46:28 +0000 (00:46 -0500)]
cmd/compile: recognize Syscall-like functions for liveness analysis
Consider this code:
func f(*int)
func g() {
p := new(int)
f(p)
}
where f is an assembly function.
In general liveness analysis assumes that during the call to f, p is dead
in this frame. If f has retained p, p will be found alive in f's frame and keep
the new(int) from being garbage collected. This is all correct and works.
We use the Go func declaration for f to give the assembly function
liveness information (the arguments are assumed live for the entire call).
Here syscall.Syscall is taking the place of f, but because its arguments
are uintptr, the liveness analysis and the garbage collector ignore them.
Since p is no longer live in h once the call starts, if the garbage collector
scans the stack while the system call is blocked, it will find no reference
to the new(int) and reclaim it. If the kernel is going to write to *p once
the call finishes, reclaiming the memory is a mistake.
We can't change the arguments or the liveness information for
syscall.Syscall itself, both for compatibility and because sometimes the
arguments really are integers, and the garbage collector will get quite upset
if it finds an integer where it expects a pointer. The problem is that
these arguments are fundamentally untyped.
The solution we have taken in the syscall package's wrappers in past
releases is to insert a call to a dummy function named "use", to make
it look like the argument is live during the call to syscall.Syscall:
Keeping p alive during the call means that if the garbage collector
scans the stack during the system call now, it will find the reference to p.
Unfortunately, this approach is not available to users outside syscall,
because 'use' is unexported, and people also have to realize they need
to use it and do so. There is much existing code using syscall.Syscall
without a 'use'-like function. That code will fail very occasionally in
mysterious ways (see #13372).
This CL fixes all that existing code by making the compiler do the right
thing automatically, without any code modifications. That is, it takes h1
above, which is incorrect code today, and makes it correct code.
Specifically, if the compiler sees a foreign func definition (one
without a body) that has uintptr arguments, it marks those arguments
as "unsafe uintptrs". If it later sees the function being called
with uintptr(unsafe.Pointer(x)) as an argument, it arranges to mark x
as having escaped, and it makes sure to hold x in a live temporary
variable until the call returns, so that the garbage collector cannot
reclaim whatever heap memory x points to.
For now I am leaving the explicit calls to use in package syscall,
but they can be removed early in a future cycle (likely Go 1.7).
The rule has no effect on escape analysis, only on liveness analysis.
Fixes #13372.
Change-Id: I2addb83f70d08db08c64d394f9d06ff0a063c500
Reviewed-on: https://go-review.googlesource.com/18584 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Wed, 13 Jan 2016 18:52:56 +0000 (10:52 -0800)]
go/importer: fix field/method package for binary importer
This is the equivalent of https://golang.org/cl/18549 for
the binary importer (which is usually not used because by
default the gc compiler produces the traditional textual
export format).
For #13898.
Change-Id: Idb6b515f2ee49e6d0362c71846994b0bd4dae8f7
Reviewed-on: https://go-review.googlesource.com/18598 Reviewed-by: Alan Donovan <adonovan@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
Robert Griesemer [Wed, 13 Jan 2016 18:41:37 +0000 (10:41 -0800)]
go/importer: revert incorrect change that slipped in prior CL
The package of anonymous fields is the package in which they were
declared, not the package of the anonymous field's type. Was correct
before and incorrectly changed with https://golang.org/cl/18549.
Change-Id: I9fd5bfbe9d0498c8733b6ca7b134a85defe16113
Reviewed-on: https://go-review.googlesource.com/18596 Reviewed-by: Alan Donovan <adonovan@google.com>
Russ Cox [Wed, 13 Jan 2016 14:59:16 +0000 (09:59 -0500)]
cmd/link: add LC_VERSION_MIN_MACOSX to linkmode=internal OS X binaries
This makes lldb willing to debug them.
The minimum version is hard-coded at OS X 10.7,
because that is the minimum that Go requires.
For more control over the version, users can
use linkmode=external and pass the relevant flags to the host linker.
Fixes #12941.
Change-Id: I20027be8aa034d07dd2a3326828f75170afe905f
Reviewed-on: https://go-review.googlesource.com/18588 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Wed, 13 Jan 2016 17:23:44 +0000 (12:23 -0500)]
runtime: allow for C pointers between arena_start and arena_used in cgo check
Fixes #13928.
Change-Id: Ia04c6bdef5ae6924d03982682ee195048f8f387f
Reviewed-on: https://go-review.googlesource.com/18611 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Wed, 13 Jan 2016 01:02:32 +0000 (17:02 -0800)]
go/importer: associate exported field and interface methods with correct package
In gc export data, exported struct field and interface method names appear
in unqualified form (i.e., w/o package name). The (gc)importer assumed that
unqualified exported names automatically belong to the package being imported.
This is not the case if the field or method belongs to a struct or interface
that was declared in another package and re-exported.
The issue becomes visible if a type T (say an interface with a method M)
is declared in a package A, indirectly re-exported by a package B (which
imports A), and then imported in C. If C imports both A and B, if A is
imported before B, T.M gets associated with the correct package A. If B
is imported before A, T.M appears to be exported by B (even though T itself
is correctly marked as coming from A). If T.M is imported again via the
import of A if gets dropped (as it should) because it was imported already.
The fix is to pass down the parent package when we parse imported types
so that the importer can use the correct package when creating fields
and methods.
Fixes #13898.
Change-Id: I7ec2ee2dda15859c582b65db221c3841899776e1
Reviewed-on: https://go-review.googlesource.com/18549 Reviewed-by: Alan Donovan <adonovan@google.com>
Brad Fitzpatrick [Wed, 13 Jan 2016 16:30:00 +0000 (16:30 +0000)]
net/http: fix Transport crash when abandoning dial which upgrades protos
When the Transport was creating an bound HTTP connection (protocol
unknown initially) and then ends up deciding it doesn't need it, a
goroutine sits around to clean up whatever the result was. That
goroutine made the false assumption that the result was always an
HTTP/1 connection or an error. It may also be an alternate protocol
in which case the *persistConn.conn net.Conn field is nil, and the
alt field is non-nil.
Keith Randall [Tue, 12 Jan 2016 20:42:28 +0000 (12:42 -0800)]
cmd/compile: stop using fucomi* ops for 387 builds
The fucomi* opcodes were only introduced for the Pentium Pro.
They do not exist for an MMX Pentium. Use the fucom* instructions
instead and move the condition codes from the fp flags register to
the integer flags register explicitly.
The use of fucomi* opcodes in ggen.go was introduced in 1.5 (CL 8738).
The bad ops were generated for 64-bit floating-point comparisons.
The use of fucomi* opcodes in gsubr.go dates back to at least 1.1.
The bad ops were generated for float{32,64} to uint64 conversions.
Brad Fitzpatrick [Tue, 12 Jan 2016 21:15:51 +0000 (21:15 +0000)]
crypto/tls: don't block in Conn.Close if Writes are in-flight
Conn.Close sends an encrypted "close notify" to signal secure EOF.
But writing that involves acquiring mutexes (handshake mutex + the
c.out mutex) and writing to the network. But if the reason we're
calling Conn.Close is because the network is already being
problematic, then Close might block, waiting for one of those mutexes.
Instead of blocking, and instead of introducing new API (at least for
now), distinguish between a normal Close (one that sends a secure EOF)
and a resource-releasing destructor-style Close based on whether there
are existing Write calls in-flight.
Because io.Writer and io.Closer aren't defined with respect to
concurrent usage, a Close with active Writes is already undefined, and
should only be used during teardown after failures (e.g. deadlines or
cancelations by HTTP users). A normal user will do a Write then
serially do a Close, and things are unchanged for that case.
This should fix the leaked goroutines and hung net/http.Transport
requests when there are network errors while making TLS requests.
David Chase [Mon, 4 Jan 2016 21:44:20 +0000 (16:44 -0500)]
cmd/compile: better modeling of escape across loop levels
Brief background on "why heap allocate". Things can be
forced to the heap for the following reasons:
1) address published, hence lifetime unknown.
2) size unknown/too large, cannot be stack allocated
3) multiplicity unknown/too large, cannot be stack allocated
4) reachable from heap (not necessarily published)
The bug here is a case of failing to enforce 4) when an
object Y was reachable from a heap allocation X forced
because of 3). It was found in the case of a closure
allocated within a loop (X) and assigned to a variable
outside the loop (multiplicity unknown) where the closure
also captured a map (Y) declared outside the loop (reachable
from heap). Note the variable declared outside the loop (Y)
is not published, has known size, and known multiplicity
(one). The only reason for heap allocation is that it was
reached from a heap allocated item (X), but because that was
not forced by publication, it has to be tracked by loop
level, but escape-loop level was not tracked and thus a bug
results.
The fix is that when a heap allocation is newly discovered,
use its looplevel as the minimum loop level for downstream
escape flooding.
Every attempt to generalize this bug to X-in-loop-
references-Y-outside loop succeeded, so the fix was aimed
to be general. Anywhere that loop level forces heap
allocation, the loop level is tracked. This is not yet
tested for all possible X and Y, but it is correctness-
conservative and because it caused only one trivial
regression in the escape tests, it is probably also
performance-conservative.
The new test checks the following:
1) in the map case, that if fn escapes, so does the map.
2) in the map case, if fn does not escape, neither does the map.
3) in the &x case, that if fn escapes, so does &x.
4) in the &x case, if fn does not escape, neither does &x.
net/http: support URLs without schemes in http.Redirect
Many browsers now support schemeless URLs in the Location headers
and also it is allowed in the draft HTTP/1.1 specification (see
http://stackoverflow.com/q/4831741#comment25926312_4831741), but
Go standard library lacks support for them.
This patch implements schemeless URLs support in http.Redirect().
Since url.Parse() correctly handles schemeless URLs, I've just added
an extra condition to verify URL's Host part in the absoulute/relative
check in the http.Redirect function.
Also I've moved oldpath variable initialization inside the block
of code where it is used.
Austin Clements [Mon, 11 Jan 2016 21:52:11 +0000 (16:52 -0500)]
runtime: remove out-of-date comment
It used to be the case that repeatedly getting one GC pointer and
enqueuing one GC pointer could cause contention on the work buffers as
each operation passed over the boundary of a work buffer. As of b6c0934, we use a two buffer cache that prevents this sort of
contention.
Michael Hudson-Doyle [Thu, 7 Jan 2016 23:57:02 +0000 (12:57 +1300)]
cmd/go: pass -no-pie along with -Wl,-r to gcc when supported on linux
Go fails to build on a system which has PIE enabled by default like this:
/usr/bin/ld: -r and -pie may not be used together
collect2: error: ld returned 1 exit status
The only system I know that has this property right now is Ubuntu Xenial
running on s390x, which is hardly the most accessible system, but it's planned
to enable this on amd64 soon too. The fix is to pass -no-pie along with -Wl,-r
to the compiler, but unfortunately that flag is very new as well. So this does
a test compile of a trivial file to see if the flag is supported.
Change-Id: I1345571142b7c3a96212e43297d19e84ec4a3d41
Reviewed-on: https://go-review.googlesource.com/18359 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Hudson-Doyle <michael.hudson@canonical.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Ian Lance Taylor [Mon, 11 Jan 2016 19:18:23 +0000 (11:18 -0800)]
runtime: fix ppc64le cgocallback code
Change-Id: I5a4a842cab2173357e8d3e349011c0c2b63be4f9
Reviewed-on: https://go-review.googlesource.com/18512 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Sat, 9 Jan 2016 01:56:50 +0000 (17:56 -0800)]
go/importer: use correct path for path->package map
In the presence of vendored packages, the path found in a package
declaration may not be the path at which the package imported from
srcDir was found. Use the correct package path.
Change-Id: I74496c3cdf82a5dbd6a5bd189bb3cd0ca103fd52
Reviewed-on: https://go-review.googlesource.com/18460 Reviewed-by: Alan Donovan <adonovan@google.com>
Ian Lance Taylor [Sat, 9 Jan 2016 00:56:02 +0000 (16:56 -0800)]
runtime: fix arm/arm64/ppc64/mips64 to dropm when necessary
Fixes #13881.
Change-Id: Idff77db381640184ddd2b65022133bb226168800
Reviewed-on: https://go-review.googlesource.com/18449 Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Rick Hudson [Wed, 6 Jan 2016 22:07:58 +0000 (17:07 -0500)]
runtime: eagerly share GC work buffers
Currently, due to an oversight, we only balance work buffers
in background and idle workers and not in assists. As a
result, in assist-heavy workloads, assists are likely to tie
up large work buffers in per-P caches increasing the
likelihood that the global list will be empty. This increases
the likelihood that other GC workers will exit and assists
will block, slowing down the system as a whole. Fix this by
eagerly balancing work buffers as soon as the assists notice
that the global buffers are empty. This makes it much more
likely that work will be immediately available to other
workers and assists.
This change reduces the garbage benchmark time by 39% and
fixes the regresssion seen at CL 15893 golang.org/cl/15893.
Garbage benchmark times before and after this CL.
Before GOPERF-METRIC:time=4427020
After GOPERF-METRIC:time=2721645
Adam Langley [Sun, 10 Jan 2016 02:31:35 +0000 (18:31 -0800)]
crypto/cipher: always zero dst buffer on GCM authentication failure.
The AESNI GCM code decrypts and authenticates concurrently and so
overwrites the destination buffer even in the case of an authentication
failure.
This change updates the documentation to make that clear and also
mimics that behaviour in the generic code so that different platforms
act identically.
Yao Zhang [Sun, 10 Jan 2016 03:22:58 +0000 (22:22 -0500)]
cmd/dist: restrict parallel tests to NumCPU on mips64x
mips64 builder and one machine of the mips64le builder has small amount
of memory. Since CL 18199, they have been running slowly, as more
processes were launched in running 'test' directory, and a lot of swap
were used. This CL brings all.bash from 5h back to 3h on Loongson 2E
with 512 MB memory.
Change-Id: I4a22e239a542a99ba5986753205d8cd1f4b3d3c6
Reviewed-on: https://go-review.googlesource.com/18483 Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Brad Fitzpatrick [Sat, 9 Jan 2016 23:34:56 +0000 (15:34 -0800)]
net/http: update bundled http2
Updates http2 to x/net git rev 0e6d34ef942 for https://golang.org/cl/18472
which means we'll get to delete a ton of grpc-go code and just use the
standard library's HTTP client instead.
Also, the comments in this CL aren't entirely accurate it turns out.
RFC 2616 says:
"The Trailer header field can be used to indicate which header fields
are included in a trailer (see section 14.40)."
And 14.40:
" An HTTP/1.1 message SHOULD include a Trailer header field in a
message using chunked transfer-coding with a non-empty trailer. Doing
so allows the recipient to know which header fields to expect in the
trailer.
If no Trailer header field is present, the trailer SHOULD NOT include
any header fields. See section 3.6.1 for restrictions on the use of
trailer fields in a "chunked" transfer-coding."
So it's really a SHOULD more than a MUST.
And gRPC (at least Google's server) doesn't predeclare "grpc-status"
ahead of time in a Trailer Header, so we'll be lenient. We were too
strict anyway. It's also not a concern for the Go client we have a
different place to populate the Trailers, and it won't confuse clients
which aren't looking for them. The ResponseWriter server side is more
complicated (and strict), though, since we don't want to widen the
ResponseWriter interface. So the Go server still requires that you
predeclare Trailers.
Ian Lance Taylor [Sat, 26 Dec 2015 17:51:59 +0000 (09:51 -0800)]
runtime: for c-archive/c-shared, install signal handlers synchronously
The previous behaviour of installing the signal handlers in a separate
thread meant that Go initialization raced with non-Go initialization if
the non-Go initialization also wanted to install signal handlers. Make
installing signal handlers synchronous so that the process-wide behavior
is predictable.
Update #9896.
Change-Id: Ice24299877ec46f8518b072a381932d273096a32
Reviewed-on: https://go-review.googlesource.com/18150
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
Austin Clements [Fri, 8 Jan 2016 19:32:52 +0000 (14:32 -0500)]
runtime/pprof: skip TestStackBarrierProfiling on FreeBSD, too
Sigh. Sleeps on FreeBSD also yield the rest of the time slice and
profiling signals are only delivered when a process completes a time
slice (worse, itimer time is only accounted to the process that
completes a time slice). It's less noticeable than the other BSDs
because the default tick rate is 1000Hz, but it's still failing
regularly.
Mikio Hara [Fri, 8 Jan 2016 18:45:06 +0000 (03:45 +0900)]
runtime/testdata: gofmt
Change-Id: I728d4c709c4122fe4b96e1350be73696ac6fb1f7
Reviewed-on: https://go-review.googlesource.com/18422 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Fri, 8 Jan 2016 17:38:41 +0000 (12:38 -0500)]
go/build: invert AllowVendor to IgnoreVendor
Looking for vendor directories is a better default.
Fixes #13772
Change-Id: Iabbaea71ccc67b72f14f1f412dc8ab70cb41996d
Reviewed-on: https://go-review.googlesource.com/18450 Reviewed-by: Robert Griesemer <gri@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Austin Clements <austin@google.com>
Ian Lance Taylor [Fri, 8 Jan 2016 15:36:35 +0000 (07:36 -0800)]
runtime: save callee-saved regs in darwin-amd64 library init
We're only getting away with it today by luck.
Change-Id: I24d1cceee4d20c5181ca64fceda152e875f6ad81
Reviewed-on: https://go-review.googlesource.com/18440
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
Joel Sing [Fri, 8 Jan 2016 12:22:12 +0000 (23:22 +1100)]
cmd/dist: fix cgoTestSO on FreeBSD amd64 with GOHOSTARCH=386
The cgoTestSO test currently fails when run on FreeBSD amd64 with
GOHOSTARCH=386. This is due to it failing to find the shared object.
On FreeBSD 64-bit architectures, the linker for 32-bit objects
looks for a separate environment variable. Export both LD_LIBRARY_PATH
and LD_32_LIBRARY_PATH on FreeBSD when GOHOSTARCH=386.
Paul Wankadia [Thu, 7 Jan 2016 07:55:18 +0000 (18:55 +1100)]
regexp/syntax: fix factoring of common prefixes in alternations
In the past, `a.*?c|a.*?b` was factored to `a.*?[bc]`. Thus, given
"abc" as its input string, the automaton would consume "ab" and
then stop (when unanchored) whereas it should consume all of "abc"
as per leftmost semantics.
Daniel Speichert [Tue, 29 Dec 2015 15:46:40 +0000 (16:46 +0100)]
net/textproto: accept multi-line error messages
Ads documentation for both formats of messages accepted by
ReadResponse(). Validity of message should not be altered by
the validation process. On message with unexpected code,
a properly formatted message was not fully read.
Russ Cox [Thu, 7 Jan 2016 15:19:55 +0000 (10:19 -0500)]
runtime: allow signal.Ignore of user-generated throwing signals
Today, signal.Ignore(syscall.SIGTRAP) does nothing
while signal.Notify(make(chan os.Signal), syscall.SIGTRAP)
correctly discards user-generated SIGTRAPs.
The same applies to any signal that we throw on.
Make signal.Ignore work for these signals.
Fixes #12906.
Change-Id: Iba244813051e0ce23fa32fbad3e3fa596a941094
Reviewed-on: https://go-review.googlesource.com/18348 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Russ Cox [Thu, 7 Jan 2016 04:00:08 +0000 (23:00 -0500)]
runtime: fix up OS X kernel bug sending user-generated SIGTRAP
OS X unconditionally sets si_code = TRAP_BRKPT when sending SIGTRAP,
even if it was generated by kill -TRAP and not a breakpoint.
Correct the si_code by looking to see if the PC is after a breakpoint.
For #12906.
Change-Id: I998c2499f7f12b338e607282a325b045f1f4f690
Reviewed-on: https://go-review.googlesource.com/18347 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Wed, 6 Jan 2016 19:32:17 +0000 (14:32 -0500)]
encoding/base64: fix streaming decode of padding-free base64
Fixes #13384.
Change-Id: Id9e827acddc8de139f93c5de0c6486bc4334c7d4
Reviewed-on: https://go-review.googlesource.com/18330 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Brad Fitzpatrick [Thu, 7 Jan 2016 20:25:09 +0000 (12:25 -0800)]
A+C: manual updates
Add Colin Cross (Google CLA)
Add Quentin Perez (Individual CLA)
Add Andy Balholm (Individual CLA)
Add Dirk Gadsden (Individual CLA)
Add Derek Che (Yahoo CLA)
And:
Add CL Sung (Individual CLA), but where gerrit is using personal email
address with CLA signed, but the git commit itself is using an
unverified htc.com address. The commit is:
https://github.com/golang/oauth2/commit/099e4f0
For github user https://github.com/clsung which says "Self-Employed"
and "clsung@gmail.com". Perhaps the self-employed part is new
since Sep 10, 2014.
Change-Id: Ic1130fb79d167259a9bb76e3be56b9c8ad6b95ca
Reviewed-on: https://go-review.googlesource.com/18369 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Brad Fitzpatrick [Fri, 8 Jan 2016 01:06:00 +0000 (01:06 +0000)]
net/http: fix too-strict validation of server header values
As Andy Balholm noted in #11207:
"RFC2616 §4.2 says that a header's field-content can consist of *TEXT,
and RFC2616 §2.2 says that TEXT is <any OCTET except CTLs, but
including LWS>, so that would mean that bytes greater than 128 are
allowed."
This is a partial rollback of the strictness from
https://golang.org/cl/11207 (added in the Go 1.6 dev cycle, only
released in Go 1.6beta1)
Ian Lance Taylor [Thu, 7 Jan 2016 23:22:39 +0000 (15:22 -0800)]
cmd/cgo, runtime: recognize unsafe.Pointer(&s[0]) in cgo pointer checks
It's fairly common to call cgo functions with conversions to
unsafe.Pointer or other C types. Apply the simpler checking of address
expressions when possible when the address expression occurs within a
type conversion.
Change-Id: I5187d4eb4d27a6542621c396cad9ee4b8647d1cd
Reviewed-on: https://go-review.googlesource.com/18391
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
Russ Cox [Thu, 7 Jan 2016 20:36:54 +0000 (15:36 -0500)]
time: restore old error text for day out of range
Go 1.5 and earlier said "day out of range".
As part of working on this code it morphed into "day of month out of range".
To avoid churn in the output restore the old text.
Brad Fitzpatrick [Thu, 7 Jan 2016 19:57:49 +0000 (11:57 -0800)]
net/http: add some tests around sending & receiving star requests
I thought there was still work to do in http2 for this, but I guess
not: the work for parsing them is in net/url (used by http2) and the
handling of OPTIONS * is already in net/http serverHandler, also used
by http2.
Matthew Dempsky [Thu, 7 Jan 2016 11:06:49 +0000 (03:06 -0800)]
cmd/compile: recognize !typedbool is typed
Adding the evconst(n) call for OANDAND and OOROR in
golang.org/cl/18262 was originally just to parallel the above iscmp
branch, but upon further inspection it seemed odd that removing it
caused test/fixedbugs/issue6671.go's
var b mybool
// ...
b = bool(true) && true // ERROR "cannot use"
to start failing (i.e., by not emitting the expected "cannot use"
error).
The problem is that evconst(n)'s settrue and setfalse paths always
reset n.Type to idealbool, even for logical operators where n.Type
should preserve the operand type. Adding the evconst(n) call for
OANDAND/OOROR inadvertantly worked around this by turning the later
evconst(n) call at line 2167 into a noop, so the "n.Type = t"
assignment at line 739 would preserve the operand type.
However, that means evconst(n) was still clobbering n.Type for ONOT,
so declarations like: