Russ Cox [Wed, 29 Nov 2017 20:22:13 +0000 (15:22 -0500)]
reflect: audit and explain safety of all unsafe.Pointer additions
It's not safe to do p+x with unsafe if that would point past the
end of the object. (Valid in C, not safe in Go.)
Pass a "whySafe" reason (compiled away) to explain at each
call site why it's safe.
Hana Kim [Thu, 30 Nov 2017 23:51:04 +0000 (18:51 -0500)]
cmd/trace: exclude threads in syscall on behalf of runtime
The number of threads in syscall presented by execution tracer's
trace view includes not only the threads calling system calls on behalf
of user created goroutines, but also those running on behalf of system
goroutines.
When the number of such system goroutines was small, the graph was
useful when examining where a program was saturating the CPU.
But as more and more system goroutines are invloved the graph became
less useful for the purpose - for example, after golang.org/cl/34784,
the timer goroutines dominate in the graph with large P
because the runtime creates per-P timer goroutines.
This change excludes the threads in syscall on behalf of runtime (system
goroutines) from the visualization. Alternatively, I could visualize the
count of such threads in a separate counter but in the same graph.
Given that many other debug endpoints (e.g. /debug/pprof/goroutine) hide
the system goroutines, including them in the same graph can confuse users.
Update #22574
Change-Id: If758cd6b9ed0596fde9a471e846b93246580b9d5
Reviewed-on: https://go-review.googlesource.com/81315 Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Brad Fitzpatrick [Fri, 1 Dec 2017 19:26:33 +0000 (19:26 +0000)]
runtime: skip gdb tests earlier before blocking goroutines in a t.Parallel
Minor.
Makes reading failing runtime test stacktraces easier (by having fewer
goroutines to read) on machines where these gdb tests wouldn't have
ever run anyway.
Change-Id: I3fab0667e017f20ef3bf96a8cc4cfcc614d25b5c
Reviewed-on: https://go-review.googlesource.com/81575 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Austin Clements [Thu, 30 Nov 2017 20:47:04 +0000 (15:47 -0500)]
runtime: improve sigsend documentation
I think of "sending" a signal as calling kill, but sigsend is involved
in handling a signal and, specifically delivering it to the internal
signal queue. The term "delivery" is already used in
signalWaitUntilIdle, so this CL also uses it in the documentation for
sigsend.
Change-Id: I86e171f247f525ece884a680bace616fa9a3c7bd
Reviewed-on: https://go-review.googlesource.com/81235 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Austin Clements [Fri, 1 Dec 2017 03:09:35 +0000 (22:09 -0500)]
runtime: restore the Go-allocated signal stack in unminit
Currently, when we minit on a thread that already has an alternate
signal stack (e.g., because the M was an extram being used for a cgo
callback, or to handle a signal on a C thread, or because the
platform's libc always allocates a signal stack like on Android), we
simply drop the Go-allocated gsignal stack on the floor.
This is a problem for Ms on the extram list because those Ms may later
be reused for a different thread that may not have its own alternate
signal stack. On tip, this manifests as a crash in sigaltstack because
we clear the gsignal stack bounds in unminit and later try to use
those cleared bounds when we re-minit that M. On 1.9 and earlier, we
didn't clear the bounds, so this manifests as running more than one
signal handler on the same signal stack, which could lead to arbitrary
memory corruption.
This CL fixes this problem by saving the Go-allocated gsignal stack in
a new field in the m struct when overwriting it with a system-provided
signal stack, and then restoring the original gsignal stack in
unminit.
This CL is designed to be easy to back-port to 1.9. It won't quite
cherry-pick cleanly, but it should be sufficient to simply ignore the
change in mexit (which didn't exist in 1.9).
Now that we always have a place to stash the original signal stack in
the m struct, there are some simplifications we can make to the signal
stack handling. We'll do those in a later CL.
Fixes #22930.
Change-Id: I55c5a6dd9d97532f131146afdef0b216e1433054
Reviewed-on: https://go-review.googlesource.com/81476
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Fri, 1 Dec 2017 16:26:09 +0000 (11:26 -0500)]
cmd/go: apply same per-package flags to test and xtest builds
If package strings has a particular set of gcflags, then the strings_test
pseudo-package built as part of the test binary should inherit the same flags.
Fixes #22831.
Change-Id: I0e896b6c0f1063454300b7323f577feffbd6650b
Reviewed-on: https://go-review.googlesource.com/81496
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Russ Cox [Fri, 1 Dec 2017 15:29:10 +0000 (10:29 -0500)]
cmd/go: fix -outputdir -coverprofile interaction
The CL introducing merged handling of cover profiles
did not correctly account for the fact that the file name argument
to -coverprofile is required to be interpreted relative to
the -outputdir argument.
Fixes #22804.
Change-Id: I804774013c12187313b8fd2044302978bdbb6697
Reviewed-on: https://go-review.googlesource.com/81455
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Than McIntosh [Fri, 1 Dec 2017 14:39:59 +0000 (09:39 -0500)]
cmd/compile: fix DWARF type symbol buglet
The code that generates the list of DWARF variables for a function
(params and autos) will emit a "no-location" entry in the DWARF for a
user var that appears in the original pre-optimization version of the
function but is no longer around when optimization is complete. The
intent is that if a GDB user types "print foo" (where foo has been
optimized out), the response will be "<optimized out>" as opposed to
"there is no such variable 'foo'). This change fixes said code to
include vars on the autom list for the function, to insure that the
type symbol for the variable makes it to the linker.
Fixes #22941.
Change-Id: Id29f1f39d68fbb798602dfd6728603040624fc41
Reviewed-on: https://go-review.googlesource.com/81415
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com>
Russ Cox [Wed, 29 Nov 2017 19:44:43 +0000 (14:44 -0500)]
reflect: fix interface to interface conversion in Call
Call is meant to mirror the language semantics, which allow:
var r io.ReadWriter
f := func(io.Reader){}
f(r)
even though the conversion from io.ReadWriter to io.Reader is
being applied to a nil interface. This is different from an explicit
conversion:
_ = r.(io.Reader)
f(r.(io.Reader))
Both of those lines panic, but the implicit conversion does not.
By using E2I, which is the implementation of the explicit conversion,
the reflect.Call equivalent of f(r) was inadvertently panicking.
Avoid the panic.
Fixes #22143.
Change-Id: I6b2f5b808e0cd3b89ae8bc75881e307bf1c25558
Reviewed-on: https://go-review.googlesource.com/80736
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
David Chase [Thu, 30 Nov 2017 20:11:34 +0000 (15:11 -0500)]
cmd/compile: use src.NoXPos for entry-block constants
The ssa backend is aggressive about placing constants and
certain other values in the Entry block. It's implausible
that the original line numbers for these constants makes
any sort of sense when it appears to a user stepping in a
debugger, and they're also not that useful in dumps since
entry-block instructions tend to be constants (i.e.,
unlikely to be the cause of a crash).
Therefore, use src.NoXPos for any values that are explicitly
inserted into a function's entry block.
Passes all tests, including ssa/debug_test.go with both
gdb and a fairly recent dlv. Hand-verified that it solves
the reported problem; constructed a test that reproduced
a problem, and fixed it.
Modified test harness to allow injection of slightly more
interesting inputs.
Fixes #22558.
Change-Id: I4476927067846bc4366da7793d2375c111694c55
Reviewed-on: https://go-review.googlesource.com/81215
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
Brad Fitzpatrick [Fri, 1 Dec 2017 03:25:02 +0000 (03:25 +0000)]
os: ignore Chtimes test failure on NetBSD if fs mounted noatime
Fixes #19293
Change-Id: I35f2f786e2e3972eda21ba5a948433bfcd621269
Reviewed-on: https://go-review.googlesource.com/81355 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Matthew Dempsky [Wed, 29 Nov 2017 20:26:59 +0000 (12:26 -0800)]
cmd/compile: fix GOEXPERIMENT checks
GOEXPERIMENT is only set during make.bash, so checking the environment
variable isn't effectual. Instead, check the values exposed by objabi.
These experiments look potentially safe, but it seems too late in the
release cycle to try to assuage that. The one exception is frame
pointer experiment, which is trivially safe: it just amounts to
incrementing some stack offsets by PtrSize.
Russ Cox [Wed, 29 Nov 2017 21:31:47 +0000 (16:31 -0500)]
testing: remove claim that b.Run is safe for concurrent use
It's not safe (it crashes), and it's also useless: if you run
multiple benchmarks in parallel you will not get reliable
timing results from any of them.
Fixes #18603.
Change-Id: I00e5a72f7c98151543cf7d5573c38383276e391a
Reviewed-on: https://go-review.googlesource.com/80841 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ian Lance Taylor [Thu, 23 Nov 2017 03:12:12 +0000 (19:12 -0800)]
runtime: don't block signals that will kill the program
Otherwise we may delay the delivery of these signals for an arbitrary
length of time. We are already careful to not block signals that the
program has asked to see.
Also make sure that we don't miss a signal delivery if a thread
decides to stop for a while while executing the signal handler.
Also clean up the TestAtomicStop output a little bit.
Fixes #21433
Change-Id: Ic0c1a4eaf7eba80d1abc1e9537570bf4687c2434
Reviewed-on: https://go-review.googlesource.com/79581
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
Hiroshi Ioka [Thu, 23 Nov 2017 01:37:05 +0000 (10:37 +0900)]
debug/gosym: update docs for changes in Go 1.3
Change-Id: I850d961e0444f8d34284e994aee183afba35eaa7
Reviewed-on: https://go-review.googlesource.com/79597 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ilya Tocar [Wed, 29 Nov 2017 19:20:08 +0000 (13:20 -0600)]
crypto/elliptic: reduce allocations on amd64
This is inspired by
https://blog.cloudflare.com/go-dont-collect-my-garbage/
This CL adds allocation tracking and parallelizes p256-related benchmarks.
Amount of allocations can be significantly reduced by marking amd64 asm
functions as noescape. This exposes a bug in p256MovCond:
PANDN with memory argument will fault if memory is not aligned, so they
are replaced with MOVDQU (which is ok with unaligned memory) and
register version of PANDN.
Results on 88-thread machine (2x 22 cores) below:
crypto/elliptic:
name old time/op new time/op delta
BaseMultP256-88 1.50µs ±11% 1.19µs ± 5% -20.20% (p=0.000 n=10+10)
ScalarMultP256-88 5.47µs ± 5% 3.63µs ±10% -33.66% (p=0.000 n=9+10)
name old alloc/op new alloc/op delta
BaseMultP256-88 800B ± 0% 288B ± 0% -64.00% (p=0.000 n=10+10)
ScalarMultP256-88 2.59kB ± 0% 0.26kB ± 0% -90.12% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
BaseMultP256-88 13.0 ± 0% 6.0 ± 0% -53.85% (p=0.000 n=10+10)
ScalarMultP256-88 16.0 ± 0% 5.0 ± 0% -68.75% (p=0.000 n=10+10)
Ilya Tocar [Wed, 29 Nov 2017 18:15:31 +0000 (12:15 -0600)]
math: remove asm version of Dim
Dim performance has regressed by 14% vs 1.9 on amd64.
Current pure go version of Dim is faster and,
what is even more important for performance, is inlinable, so
instead of tweaking asm implementation, just remove it.
I had to update BenchmarkDim, because it was simply reloading
constant(answer) in a loop.
Perf data below:
name old time/op new time/op delta
Dim-6 6.79ns ± 0% 1.60ns ± 1% -76.39% (p=0.000 n=7+10)
If I modify benchmark to be the same as in this CL results are even better:
name old time/op new time/op delta
Dim-6 10.2ns ± 0% 1.6ns ± 1% -84.27% (p=0.000 n=8+10)
Alberto Donizetti [Tue, 21 Nov 2017 13:16:04 +0000 (14:16 +0100)]
math/big: protect against aliasing in nat.divLarge
In nat.divLarge (having signature (z nat).divLarge(u, uIn, v nat)),
we check whether z aliases uIn or v, but aliasing is currently not
checked for the u parameter.
Unfortunately, z and u aliasing each other can in some cases cause
errors in the computation.
The q return parameter (which will hold the result's quotient), is
unconditionally initialized as
q = z.make(m + 1)
When cap(z) ≥ m+1, z.make() will reuse z's backing array, causing q
and z to share the same backing array. If then z aliases u, setting q
during the quotient computation will then corrupt u, which at that
point already holds computation state.
To fix this, we add an alias(z, u) check at the beginning of the
function, taking care of aliasing the same way we already do for uIn
and v.
Fixes #22830
Change-Id: I3ab81120d5af6db7772a062bb1dfc011de91f7ad
Reviewed-on: https://go-review.googlesource.com/78995
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Hana (Hyang-Ah) Kim [Thu, 2 Nov 2017 23:17:39 +0000 (19:17 -0400)]
cmd/trace: compute pprof-style output per goroutine type
The trace command computes IO, Schedule, Block, and Syscall profiles
by following the unblocking links in the execution trace and summing
up the duration. This change offers variations of those profiles
that include only selected goroutine types. The id parameter takes the
goroutine type - i.e. pc of the goroutine.
The output is available from the /goroutine view. So, users can see
where the goroutines of interest typically block.
Also, these profiles are available for download so users can use
pprof or other tools to interpret the output. This change adds links
for download of global profile in the main page.
Brad Fitzpatrick [Thu, 30 Nov 2017 02:26:51 +0000 (02:26 +0000)]
build: add alternate output format for bootstrap.bash, as used by builders
I've been doing these tweaks by hand. I was going to write a tool in
Go for it, but it's not much additional shell here.
Fixes #22912
Updates #9797 (already closed)
Change-Id: Ia15bd9b6876e6f6a76aa9ca86b10f113095e96a3
Reviewed-on: https://go-review.googlesource.com/80895 Reviewed-by: Ian Lance Taylor <iant@golang.org>
GOMIPS is a GOARCH=mips{,le} specific option, for a choice between
hard-float and soft-float. Valid values are 'hardfloat' (default) and
'softfloat'. It is passed to the assembler as
'GOMIPS_{hardfloat,softfloat}'.
Note: GOMIPS will later also be used for a choice of MIPS instruction
set (mips32/mips32r2).
Than McIntosh [Fri, 6 Oct 2017 15:32:28 +0000 (11:32 -0400)]
compiler,linker: support for DWARF inlined instances
Compiler and linker changes to support DWARF inlined instances,
see https://go.googlesource.com/proposal/+/HEAD/design/22080-dwarf-inlining.md
for design details.
This functionality is gated via the cmd/compile option -gendwarfinl=N,
where N={0,1,2}, where a value of 0 disables dwarf inline generation,
a value of 1 turns on dwarf generation without tracking of formal/local
vars from inlined routines, and a value of 2 enables inlines with
variable tracking.
Updates #22080
Change-Id: I69309b3b815d9fed04aebddc0b8d33d0dbbfad6e
Reviewed-on: https://go-review.googlesource.com/75550
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com>
Cherry Zhang [Wed, 29 Nov 2017 20:55:40 +0000 (15:55 -0500)]
cmd/compile: fix loop depth of range expression in escape analysis
ORANGE node's Right node is the expression it is ranging over,
which is evaluated before the loop. In the escape analysis,
we should walk this node without loop depth incremented.
Brad Fitzpatrick [Wed, 29 Nov 2017 21:15:31 +0000 (21:15 +0000)]
bytes: mention strings.Builder in Buffer.String docs
Fixes #22778
Change-Id: I37f7a59c15828aa720fe787fff42fb3ef17729c7
Reviewed-on: https://go-review.googlesource.com/80815 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Wed, 29 Nov 2017 01:17:33 +0000 (17:17 -0800)]
go/types: report error when recognizing issue #18395.
The fix (CL 79575) for #18395 is too risky at this stage of the Go 1.10
release process.
Since issue #18395 is easily recognized (but not easily fixed), report
an error instead of silently continuing. This avoids inscrutable follow
on errors.
Also, make sure all empty interfaces are "completed", and adjust
printing code to report incomplete interfaces.
For #18395.
Change-Id: I7fa5f97ff31ac9775c9a6d318fce9f526b0350cd
Reviewed-on: https://go-review.googlesource.com/80455 Reviewed-by: Alan Donovan <adonovan@google.com>
Cherry Zhang [Wed, 29 Nov 2017 20:58:43 +0000 (15:58 -0500)]
cmd/internal/objfile: make lookupFunc an alias type
In the x/arch repo, CL 45098 introduced SymLookup type, replacing
the unnamed function type for lookup functions. This affects the
signature of x86asm.GoSyntax. In particular, it cannot convert
one named type, namely lookupFunc, to the other without an
explicit cast. Make lookupFunc unnamed to fix.
Leigh McCulloch [Sat, 4 Nov 2017 20:54:30 +0000 (20:54 +0000)]
doc: move single change workflow note in contribution guide
The note about the single change workflow is included in the
git-codereview installation instructions, but it has nothing to do with
installing git-codereview. This note is more relevant for when a change
is actually being made.
Change-Id: Iccb90f3b7da87fab863fa4808438cd69a21a2fce
Reviewed-on: https://go-review.googlesource.com/76317 Reviewed-by: Steve Francia <spf@golang.org>
Joe Tsai [Thu, 16 Nov 2017 18:15:34 +0000 (10:15 -0800)]
archive/tar: use placeholder name for global PAX records
Several usages of tar (reasonably) just use the Header.FileInfo
to determine the type of the header. However, the os.FileMode type
is not expressive enough to represent "files" that are not files
at all, but some form of metadata.
Thus, Header{Typeflag: TypeXGlobalHeader}.FileInfo().Mode().IsRegular()
reports true, even though the expected result may have been false.
To reduce (not eliminate) the possibility of failure for such usages,
use the placeholder filename from the global PAX headers.
Thus, in the event the user did not handle special "meta" headers
specifically, they will just be written to disk as a regular file.
As an example use case, the "git archive --format=tgz" command produces
an archive where the first "file" is a global PAX header with the
name "global_pax_header". For users that do not explicitly check
the Header.Typeflag field to ignore such headers, they may end up
extracting a file named "global_pax_header". While it is a bogus file,
it at least does not stop the extraction process.
Joe Tsai [Wed, 15 Nov 2017 20:38:26 +0000 (12:38 -0800)]
archive/zip: preserve old FileHeader.ModTime behavior
In order to avoid a regression where the date of the ModTime method
changed behavior, simply preserve the old behavior of determining
the date based on the legacy fields.
This ensures that anyone relying on ModTime before Go1.10 will have
the exact same behavior as before.
New users should use FileHeader.Modified instead.
We keep the UTC coersion logic in SetModTime since some users
manually compute timezone offsets in order to have precise control
over the MS-DOS time field.
FreeBSD/386 and NetBSD/386 diverged between Go 1.4 and Go 1.5 when
Russ sent https://golang.org/cl/135830043 (git rev 25f6b02ab0db8e)
to change the calling convention of the C compilers to match Go.
But netbsd wasn't updated.
Tested on a NetBSD/386 VM, since the builders aren't back up yet (due
to this bug)
David Chase [Mon, 27 Nov 2017 23:06:17 +0000 (18:06 -0500)]
cmd/compile: adjust lineno during import to get Pos right
Binary import sometimes constructs nodes using functions
that use the global lineno for the Position. This causes
spurious numbers to appear in the assembly and the
debugging output.
Fix (targeted, because late in the cycle): save and restore
lineno around bimport calls known to use lineno-sensitive
functions.
Updates #22600.
(Comment: "This is a weird line to step through")
Change-Id: I9c4094670380609fe4b6696443fb02579521c596
Reviewed-on: https://go-review.googlesource.com/80115
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Change-Id: I9129130aafbfc7d0d7e9b674b6fc6cb31b7381be
Reviewed-on: https://go-review.googlesource.com/64910 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Brad Fitzpatrick [Mon, 27 Nov 2017 21:45:58 +0000 (21:45 +0000)]
net/http: document streaming nature of Response.Body
Fixes #22873
Change-Id: Ib2b7ee42a23b84db21cdfa693b62d5e6fbfdb54e
Reviewed-on: https://go-review.googlesource.com/80075 Reviewed-by: Tom Bergan <tombergan@google.com>
Brad Fitzpatrick [Mon, 27 Nov 2017 22:48:11 +0000 (22:48 +0000)]
net/http: panic on invalid WriteHeader status code
Panic if an http Handler does:
rw.WriteHeader(0)
... or other invalid values. (for a forgiving range of valid)
I previously made it kinda work in https://golang.org/cl/19130 but
there's no good way to fake it in HTTP/2, and we want HTTP/1 and
HTTP/2 behavior to be the same, regardless of what programs do.
Currently HTTP/2 omitted the :status header altogether, which was a
protocol violation. In fixing that, I found CL 19130 added a test
about bogus WriteHeader values with the comment:
// This might change at some point, but not yet in Go 1.6.
This now changes. Time to be strict.
Updates golang/go#228800
Change-Id: I20eb6c0e514a31f4bba305ac4c24266f39b95fd5
Reviewed-on: https://go-review.googlesource.com/80077 Reviewed-by: Tom Bergan <tombergan@google.com>
Tom Bergan [Mon, 27 Nov 2017 19:25:14 +0000 (11:25 -0800)]
net/textproto: reject all headers with a leading space
Previously, golang.org/cl/75350 updated ReadMIMEHeader to ignore the
first header line when it begins with a leading space, as in the
following example:
GET / HTTP/1.1
Host: foo.com
Accept-Encoding: gzip
However, golang.org/cl/75350 changed ReadMIMEHeader's behavior for the
following example: before the CL it returned an error, but after the
CL it ignored the first line.
GET / HTTP/1.1
Host foo.com
Accept-Encoding: gzip
This change updates ReadMIMEHeader to always fail when the first header
line starts with a space. During the discussion for golang.org/cl/75350,
we realized we had three competing needs:
1. HTTP clients should accept malformed response headers when possible
(ignoring the malformed lines).
2. HTTP servers should reject all malformed request headers.
3. The net/textproto package is used by multiple protocols (most notably,
HTTP and SMTP) which have slightly different parsing semantics. This
complicates changes to net/textproto.
We weren't sure how to best fix net/textproto without an API change, but
it is too late for API changes in Go 1.10. We decided to ignore initial
lines that begin with spaces, thinking that would have the least impact on
existing users -- malformed headers would continue to parse, but the
initial lines would be ignored. Instead, golang.org/cl/75350 actually
changed ReadMIMEHeader to succeed in cases where it previously failed
(as in the above example).
Reconsidering the above two examples, there does not seem to be a good
argument to silently ignore ` Host: foo.com` but fail on ` Host foo.com`.
Hence, this change fails for *all* headers where the initial line begins
with a space.
Updates #22464
Change-Id: I68d3d190489c350b0bc1549735bf6593fe11a94c
Reviewed-on: https://go-review.googlesource.com/80055
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Robert Griesemer [Tue, 21 Nov 2017 05:54:41 +0000 (21:54 -0800)]
go/types: add debugging code to detect use of incomplete interfaces
The comment for phase 2 of checker.interfaceType (typexpr.go:517)
requires that embedded interfaces be complete for correctness of
the algorithm.
Yet, the very next comment (typexpr.go:530) states that underlying
embedded interfaces may in fact be incomplete.
This is in fact the case and the underlying bug in issue #18395.
This change makes sure that new interface types are marked complete
when finished (per the implicit definition in Interface.Complete,
type.go:302). It also adds a check, enabled in debug mode only, to
detect the use of incomplete embedded interfaces during construction
of a new interface. In debug mode, this check fails for the testcase
in the issue (and several others).
This change has no noticeable impact with debug mode disabled.
For #18395.
Change-Id: Ibb81e47257651282fb3755a80a36ab5d392e636d
Reviewed-on: https://go-review.googlesource.com/78955 Reviewed-by: Alan Donovan <adonovan@google.com>
Brian Kessler [Fri, 23 Jun 2017 08:50:14 +0000 (01:50 -0700)]
math/cmplx: use signed zero to correct branch cuts
Branch cuts for the elementary complex functions along real or imaginary axes
should be resolved in floating point calculations by one-sided continuity with
signed zero as described in:
"Branch Cuts for Complex Elementary Functions or Much Ado About Nothing's Sign Bit"
W. Kahan
Available at: https://people.freebsd.org/~das/kahan86branch.pdf
And as described in the C99 standard which is claimed as the original cephes source.
Sqrt did not return the correct branch when imag(x) == 0. The branch is now
determined by sign(imag(x)). This incorrect branch choice was affecting the behavior
of the Trigonometric/Hyperbolic functions that use Sqrt in intermediate calculations.
Asin, Asinh and Atan had spurious domain checks, whereas the functions should be valid
over the whole complex plane with appropriate branch cuts.
Austin Clements [Fri, 24 Nov 2017 15:12:44 +0000 (10:12 -0500)]
runtime: fix final stack split in exitsyscall
exitsyscall should be recursively nosplit, but we don't have a way to
annotate that right now (see #21314). There's exactly one remaining
place where this is violated right now: exitsyscall -> casgstatus ->
print. The other prints in casgstatus are wrapped in systemstack
calls. This fixes the remaining print.
Updates #21431 (in theory could fix it, but that would just indicate
that we have a different G status-related crash and we've *never* seen
that failure on the dashboard.)
Emmanuel Odeke [Thu, 23 Nov 2017 22:31:28 +0000 (15:31 -0700)]
runtime: tweak doc for Goexit
Use singular form of panic and remove the unnecessary
'however', when comparing Goexit's behavior to 'a panic'
as well as what happens for deferred recovers with Goexit.
Change-Id: I3116df3336fa135198f6a39cf93dbb88a0e2f46e
Reviewed-on: https://go-review.googlesource.com/79755 Reviewed-by: Rob Pike <r@golang.org>
Tobias Klauser [Thu, 23 Nov 2017 10:21:06 +0000 (11:21 +0100)]
syscall: remove dragonfly/386 from mkall.sh
dragonfly/386 isn't a valid GOOS/GOARCH pair and there are no generated
files for this pair in syscall.
Change-Id: Ibea2103c2f5e139139d850df3aac9b5a9c4ac9ab
Reviewed-on: https://go-review.googlesource.com/79675 Reviewed-by: Ian Lance Taylor <iant@golang.org>
David du Colombier [Thu, 23 Nov 2017 11:46:18 +0000 (12:46 +0100)]
net: skip TestLookupLongTXT on Plan 9
CL 79555 added TestLookupLongTXT. However, this test is
failing on Plan 9, because the DNS resolver (ndb/dns)
only returns a single TXT record.
Updates #22857.
Change-Id: I33cdc63a3d3de4d1c7f2684934316c44992fb9e2
Reviewed-on: https://go-review.googlesource.com/79695
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Austin Clements [Thu, 23 Nov 2017 02:58:57 +0000 (21:58 -0500)]
runtime: document sigtrampgo better
Add an explanation of why sigtrampgo is nosplit.
Updates #21314.
Change-Id: I3f5909d2b2c180f9fa74d53df13e501826fd4316
Reviewed-on: https://go-review.googlesource.com/79615 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Tom Lanyon [Tue, 7 Nov 2017 05:16:24 +0000 (16:16 +1100)]
os/exec: update docs for cmd.Std{out,err} and cmd.Wait to clarify how copying is done
Fixes #22610.
Change-Id: I172fe1d1941a8a2750af7ee75f7af7e81a702c40
Reviewed-on: https://go-review.googlesource.com/76320 Reviewed-by: Ian Lance Taylor <iant@golang.org>