Paul Marks [Mon, 20 Jul 2015 23:04:25 +0000 (16:04 -0700)]
net: compute the Dialer deadline exactly once.
When dialing with a relative Timeout instead of an absolute Deadline,
the deadline function only makes sense if called before doing any
time-consuming work.
This change calls deadline exactly once, storing the result until the
Dial operation completes. The partialDeadline implementation is
reverted to the following patch set 3:
https://go-review.googlesource.com/#/c/8768/3..4/src/net/dial.go
Otherwise, when dialing a name with multiple IP addresses, or when DNS
is slow, the recomputed deadline causes the total Timeout to exceed that
requested by the user.
Fixes #11796
Change-Id: I5e1f0d545f9e86a4e0e2ac31a9bd108849cf0fdf
Reviewed-on: https://go-review.googlesource.com/12442
Run-TryBot: Paul Marks <pmarks@google.com>
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
os/exec: close read pipe if copy to io.Writer fails
Fixes #10400.
Change-Id: Ic486cb8af4c40660fd1a2e3d10986975acba3f19
Reviewed-on: https://go-review.googlesource.com/12537 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ian Lance Taylor [Tue, 21 Jul 2015 20:59:35 +0000 (13:59 -0700)]
cmd/go: for get -t and list, look up path in vendor directories
This is needed to handle vendor directories correctly. It was already
done for the regular imports when the package was loaded, but not for
the test-only imports.
It would be nice to do this while loading the package, but that breaks
the code that checks for direct references to vendor packages when
running go test. This change is relatively contained.
While we're at it, skip "C" test imports in go get.
Fixes #11628.
Fixes #11717.
Change-Id: I9cc308cf45683e3ff905320c2b5cb45db7716846
Reviewed-on: https://go-review.googlesource.com/12488
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
net/mail: enhanced Address.String and ParseAddress to match RFC 5322
Updated Address.String so it restores quoted local parts, which wasn't
done before.
When parsing `<" "@example.com>`, the formatted string returned
`< @example>`, which doens't match RFC 5322, since a space is not atext.
Another example is `<"bob@valid"@example.com>` which returned
`<bob@valid@example.com>`, which is completely invalid.
I also added support for quotes and backslashes in a quoted local part.
Besides formatting a parsed Address, the ParseAddress function also
needed more testing and finetuning for special cases.
Things like `<.john.doe@example.com>` and `<john..doe@example.com>`
e.a. were accepted, but are invalid.
I fixed those details and add tests for some other special cases.
Change-Id: I0897e8cf695434e77d14dcb1d96f21747edfe37c
Reviewed-on: https://go-review.googlesource.com/12523 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Some routines run without and m or g and cannot invoke the
race detector runtime. They must be opaque to the runtime.
That used to be true because they were written in C.
Now that they are written in Go, disable the race detector
annotations for those functions explicitly.
Add test.
Fixes #10874.
Change-Id: Ia8cc28d51e7051528f9f9594b75634e6bb66a785
Reviewed-on: https://go-review.googlesource.com/12534 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ian Lance Taylor [Wed, 22 Jul 2015 05:34:48 +0000 (22:34 -0700)]
runtime: if we don't handle a signal on a non-Go thread, raise it
In the past badsignal would crash the program. In
https://golang.org/cl/10757044 badsignal was changed to call sigsend,
to fix issue #3250. The effect of this was that when a non-Go thread
received a signal, and os/signal.Notify was not being used to check
for occurrences of the signal, the signal was ignored.
This changes the code so that if os/signal.Notify is not being used,
then the signal handler is reset to what it was, and the signal is
raised again. This lets non-Go threads handle the signal as they
wish. In particular, it means that a segmentation violation in a
non-Go thread will ordinarily crash the process, as it should.
Fixes #10139.
Update #11794.
Change-Id: I2109444aaada9d963ad03b1d071ec667760515e5
Reviewed-on: https://go-review.googlesource.com/12503 Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
runtime: fix comments referring to trace functions in runtime/pprof
ae1ea2a moved trace-related functions from runtime/pprof to
runtime/trace, but missed a doc comment and a code comment. Update
these to reflect the move.
Adam Langley [Wed, 22 Jul 2015 16:31:29 +0000 (09:31 -0700)]
crypto/elliptic: call IsOnCurve via the interface.
https://go-review.googlesource.com/#/c/2421/ contains an unfortunate
slip where IsOnCurve is called on the CurveParams rather than the curve.
This doesn't really matter, but it's a pain for people doing tricks with
crypto/elliptic and means that 1.5 would be a regression for them
without this change.
See https://groups.google.com/forum/#!topic/golang-dev/i8OPUTYctOk
JSON decoding currently fails for null values bound to any type
which does implement the JSON Unmarshaler interface without checking
for null values (such as time.Time).
It also fails for types implementing the TextUnmarshaler interface.
The expected behavior of the JSON decoding engine in such case is
to process null by keeping the value unchanged without producing
any error.
Make sure null values are handled by the decoding engine itself,
and never passed to the UnmarshalText or UnmarshalJSON methods.
dist test should not print (especially to stdout) during test
registration. This confuses other tools interacting with dist using
dist test --list, etc.
Change-Id: Ie4f82c13e49590c23a7a235d90ddbc4f5ed81e0b
Reviewed-on: https://go-review.googlesource.com/12487 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Alex Brainman [Mon, 13 Jul 2015 00:55:49 +0000 (10:55 +1000)]
syscall: warn not to use FormatMessage
Fixes #11147
Change-Id: Ib31160946a53f6f9b11daea211ff04d186b51b3f
Reviewed-on: https://go-review.googlesource.com/12067 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ian Lance Taylor [Mon, 20 Jul 2015 15:30:45 +0000 (08:30 -0700)]
cmd/go: build errors rather than strings in some tests
Speed up the test suite by building the errors package rather than the
strings package in some cases where the specific package we are
building doesn't matter. The errors package is smaller, and doesn't
have any assembler code.
Also make a couple of tests run in parallel.
Update #11779.
Change-Id: I62e47f8655f9d85bf93c70ae6e6121276d96aee0
Reviewed-on: https://go-review.googlesource.com/12365
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Ian Lance Taylor [Mon, 20 Jul 2015 01:20:06 +0000 (18:20 -0700)]
cmd/go: don't run TestInstalls in short mode
It changes GOROOT, so we shouldn't run it in short mode. Also, it's
fairly slow.
Update #11779.
Change-Id: I3d3344954cf9b2ac70070c878a67cb65ac8fd85c
Reviewed-on: https://go-review.googlesource.com/12364
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
Michael Hudson-Doyle [Tue, 14 Jul 2015 23:31:30 +0000 (11:31 +1200)]
cmd/compile: define func value symbols at declaration
This is mostly Russ's https://golang.org/cl/12145 but with some extra fixes to
account for the fact that function declarations without implementations now
break shared libraries, and including my test case.
Fixes #11480.
Change-Id: Iabdc2934a0378e5025e4e7affadb535eaef2c8f1
Reviewed-on: https://go-review.googlesource.com/12340 Reviewed-by: Ian Lance Taylor <iant@golang.org>
The runtime.GC documentation was rewritten in df2809f to make it clear
that it blocks until GC is complete, but the re-rewrite in ed9a4c9 and e28a679 lost this property when clarifying that it may also block the
entire program and not just the caller.
Try to arrive at wording that conveys both of these properties.
Silvan Jegen [Tue, 13 Jan 2015 20:41:23 +0000 (21:41 +0100)]
bufio: Remove unneeded error initialization
The default value for error is nil so there is no need to assign this
value here.
Change-Id: I4714ef7607996ccbf91b704390e1d1d39ee3847b
Reviewed-on: https://go-review.googlesource.com/12355 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Ian Lance Taylor [Thu, 16 Jul 2015 23:25:44 +0000 (16:25 -0700)]
cmd/go: ignore import of "C" when fetching dependencies
The change https://golang.org/cl/12192 changed the get code to use the
list of package imports, not the computed list of dependencies, as the
computed list could be out of date if the package changed when using
go get -u. Computing the dependency list would skip an import of "C",
but that would still be on the package import list. This changes the
code to skip "C" when walking the import list.
No test--the best test would be to add an import of "C" to
github.com/rsc/go-get-issue-9224-cmd for TestGoGetUpdate.
Fixes #11738.
Change-Id: Id89ddafeade2391d15688bfd142fafd67844a941
Reviewed-on: https://go-review.googlesource.com/12322
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Andrew Gerrand <adg@golang.org>
Dave Cheney [Fri, 17 Jul 2015 17:46:38 +0000 (10:46 -0700)]
os: add test to ensure Rename returns *LinkError
Updates #10061
CL 12353 updated the documentation for os.Rename to stipulate the function will
return errors of type *os.LinkError. This CL adds a test to ensure that the
implementations continue to obey this contract.
Change-Id: I41beb8c9d8356c737de251fdc6f652caab3ee636
Reviewed-on: https://go-review.googlesource.com/12329 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Rob Pike [Fri, 17 Jul 2015 21:37:51 +0000 (07:37 +1000)]
runtime: document that GC blocks the whole program
No code changes. Just make it clear that runtime.GC is not concurrent.
Change-Id: I00a99ebd26402817c665c9a128978cef19f037be
Reviewed-on: https://go-review.googlesource.com/12345 Reviewed-by: Dave Cheney <dave@cheney.net> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Paolo Martini [Fri, 17 Jul 2015 15:26:08 +0000 (17:26 +0200)]
doc: fix typo
The document `doc/go_spec.html` uses "preceeding" instead of the word
"preceding" in one place.
Fixed another occurrence in `src/go/types/typexpr.go`.
Change-Id: Ic67f62026b5c9d002c5c5632299f14ecac8b02ae
Reviewed-on: https://go-review.googlesource.com/12354 Reviewed-by: Ian Lance Taylor <iant@golang.org>
runtime: don't free large spans until heapBitsSweepSpan returns
This fixes a race between 1) sweeping and freeing an unmarked large
span and 2) reusing that span and allocating from it. This race arises
because mSpan_Sweep returns spans for large objects to the heap
*before* heapBitsSweepSpan clears the mark bit on the object in the
span.
Specifically, the following sequence of events can lead to an
incorrectly zeroed bitmap byte, which causes the garbage collector to
not trace any pointers in that object (the pointer bits for the first
four words are cleared, and the scan bits are also cleared, so it
looks like a no-scan object).
1) P0 calls mSpan_Sweep on a large span S0 with an unmarked object on it.
2) mSpan_Sweep calls heapBitsSweepSpan, which invokes the callback for
the one (unmarked) object on the span.
3) The callback calls mHeap_Free, which makes span S0 available for
allocation, but this is too early.
4) P1 grabs this S0 from the heap to use for allocation.
5) P1 allocates an object on this span and writes that object's type
bits to the bitmap.
6) P0 returns from the callback to heapBitsSweepSpan.
heapBitsSweepSpan clears the byte containing the mark, even though
this span is now owned by P1 and this byte contains important
bitmap information.
This fixes this problem by simply delaying the mHeap_Free until after
the heapBitsSweepSpan. I think the overall logic of mSpan_Sweep could
be simplified now, but this seems like the minimal change.
Fixes #11617.
Change-Id: I6b1382c7e7cc35f81984467c0772fe9848b7522a
Reviewed-on: https://go-review.googlesource.com/12320
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Rob Pike <r@golang.org>
Change-Id: Ia7cc1d52211b32a2eb2b3888d621b28d6932aca9
Reviewed-on: https://go-review.googlesource.com/12290 Reviewed-by: Ian Lance Taylor <iant@golang.org>
David Crawshaw [Thu, 16 Jul 2015 17:14:56 +0000 (13:14 -0400)]
crypto/x509: iOS build tag
The iOS simulator compiles with GOOS=darwin GOARCH=386, and x509
sets the inappropriate flag -mmacosx-version-min=10.6. Condition
its compilation on the absence of an "ios" build tag.
net/http: don't reuse conns after incomplete 100-continue requests
If we receive an HTTP request with "Expect: 100-continue" and the
Handler never read to EOF, the conn is in an unknown state.
Don't reuse that connection.
Andrew Gerrand [Wed, 15 Jul 2015 08:36:49 +0000 (18:36 +1000)]
cmd/go: fix parsing of Git SCP-like remotes
Now that we care about the protocol of Git remotes (for the -insecure
flag), we need to recognize and parse the SCP-like remote format.
Fixes golang/go#11457
Change-Id: Ia26132274fafb1cbfefe2475f7ac5f17ccd6da40
Reviewed-on: https://go-review.googlesource.com/12226 Reviewed-by: Ian Lance Taylor <iant@golang.org>
runtime: fix saved PC/SP after safe-point function in syscall
Running a safe-point function on syscall entry uses systemstack() and
hence clobbers g.sched.pc and g.sched.sp. Fix this by re-saving them
after the systemstack, just like in the other uses of systemstack in
reentersyscall.
runtime: run safe-point function before entering _Psyscall
Currently, we run a P's safe-point function immediately after entering
_Psyscall state. This is unsafe, since as soon as we put the P in
_Psyscall, we no longer control the P and another M may claim it.
We'll still run the safe-point function only once (because doing so
races on an atomic), but the P may no longer be at a safe-point when
we do so.
In particular, this means that the use of forEachP to dispose all P's
gcw caches is unsafe. A P may enter a syscall, run the safe-point
function, and dispose the P's gcw cache concurrently with another M
claiming the P and attempting to use its gcw cache. If this happens,
we may empty the gcw's workbuf after putting it on
work.{full,partial}, or add pointers to it after putting it in
work.empty. This will cause an assertion failure when we later pop the
workbuf from the list and its object count is inconsistent with the
list we got it from.
Fix this by running the safe-point function just before putting the P
in _Psyscall.
Related to #11640. This probably fixes this issue, but while I'm able
to show that we can enter a bad safe-point state as a result of this,
I can't reproduce that specific failure.
Ian Lance Taylor [Wed, 15 Jul 2015 05:17:41 +0000 (22:17 -0700)]
cmd/compile: recognize embedded field in inlined function
There was already special code to recognize "?" in hidden_structdcl,
which is used for inlined types and variables. This recognizes "?" in
structdcl as well, a case that arises when a struct type appears
within an inlined function body.
Fixes #10219.
Change-Id: Ic5257ae54f817e0d4a189c2294dcd633c9f2101a
Reviewed-on: https://go-review.googlesource.com/12241
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
cmd/compile: fix PtrTo(t) for unnamed t with embedded fields
Fixes #8427.
Change-Id: I826a3bc4519845ad30d6dbaf058fe7ed7bee8db0
Reviewed-on: https://go-review.googlesource.com/12233 Reviewed-by: Ian Lance Taylor <iant@golang.org>
- Make Log2 exact for powers of two.
- Fix error tolerance function to make tolerance
a function of the correct (expected) value.
Fixes #9066.
Change-Id: I0320a93ce4130deed1c7b7685627d51acb7bc56d
Reviewed-on: https://go-review.googlesource.com/12230 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: I3b85053262cac3c30358f8e03a5aca65dbc67623
Reviewed-on: https://go-review.googlesource.com/12231 Reviewed-by: Ian Lance Taylor <iant@golang.org>