In general, these functions cannot behave correctly when given a
hostname, because a hostname may represent multiple IP addresses, and
first(isIPv4) chooses at most one.
Updates #9334
Change-Id: Icfb629f84af4d976476385a3071270253c0000b1
Reviewed-on: https://go-review.googlesource.com/31931
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Looking at the kernel sources, I don't see how this is possible.
But obviously it is. Just try again.
Fixes#17161.
Change-Id: Iea7d53f7cf75944792d2f75a0d07129831c7bcdb
Reviewed-on: https://go-review.googlesource.com/31823
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The old code leaves garbages in a temporary directory because it
cannot remove the current working directory on windows.
The new code changes the directory before calling os.Remove.
Furthermore, the old code assumes that ioutil.TempDir (os.TempDir)
doesn't return a relative path nor an UNC path.
If it isn't the case, the new code calls t.Fatal earlier for preventing
ambiguous errors.
Finally, the old code reassigns the variable which is used by the defer
function. It could cause unexpected results, so avoid that.
Change-Id: I5fc3902059ecaf18dc1341ecc4979d1206034cd7
Reviewed-on: https://go-review.googlesource.com/31790
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Updates #15345
Change-Id: I447d133512e99a9900928a910e161a85db6e8b75
Reviewed-on: https://go-review.googlesource.com/31792
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
It appears to be a vestigial holding ground for bugs.
But we have an issue tracker, and #1909 is there and open.
Change-Id: I912ff222a24c51fab483be0c67dad534f5a84488
Reviewed-on: https://go-review.googlesource.com/31859
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
CL 31468 added TestLookupNonLDH, which was failing on Plan 9,
because LookupHost was expecting to return errNoSuchHost
on DNS resolution failure, while Plan 9 returned the
"dns failure" string.
In the Plan 9 implementation of lookupHost, we now return
errNoSuchHost instead of the "dns failure" string, so
the behavior is more consistant with other operating systems.
Fixes#17568.
Change-Id: If64f580dc0626a4a4f19e5511ba2ca5daff5f789
Reviewed-on: https://go-review.googlesource.com/31873
Run-TryBot: David du Colombier <0intro@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
VerifyPeerCertificate returns an error if the peer should not be
trusted. It will be called after the initial handshake and before
any other verification checks on the cert or chain are performed.
This provides the callee an opportunity to augment the certificate
verification.
If VerifyPeerCertificate is not nil and returns an error,
then the handshake will fail.
Fixes#16363
Change-Id: I6a22f199f0e81b6f5d5f37c54d85ab878216bb22
Reviewed-on: https://go-review.googlesource.com/26654
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This prevents the traceback code from seeing a half-updated
stack frame when a profiling signal comes during the execution
of function prologue. Also fixes mips64x part of #17381.
Change-Id: Iec9683427e546e3648b2e8b1dde956d13f6eb938
Reviewed-on: https://go-review.googlesource.com/31721
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Since CL 30614, TestCloseError is failing on Plan 9,
because File.Write now checks f.fd == badFd before
calling syscall.Write.
The f.fd == badFd check returns os.ErrClosed, while
syscall.Write returned a syscall.ErrorString error.
TestCloseError was failing because it expected a
syscall.ErrorString error.
We add a case in parseCloseError to handle the
os.ErrClosed case.
Fixes#17569.
Change-Id: I6b4d956d18ed6d3c2ac5211ffd50a4888f7521e1
Reviewed-on: https://go-review.googlesource.com/31872
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Adds a rule to generate ANDN for AND x ^y.
Fixes#17567
Change-Id: I3b978058d5663f32c42b1af19bb207eac5622615
Reviewed-on: https://go-review.googlesource.com/31769
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
The Gotype field is only used for ATYPE instructions. Instead of
specially storing the Go type symbol in From.Gotype, just store it in
To.Sym like any other 2-argument instruction would.
Modest reduction in allocations:
name old alloc/op new alloc/op delta
Template 42.0MB ± 0% 41.8MB ± 0% -0.40% (p=0.000 n=9+10)
Unicode 34.3MB ± 0% 34.1MB ± 0% -0.48% (p=0.000 n=9+10)
GoTypes 122MB ± 0% 122MB ± 0% -0.14% (p=0.000 n=9+10)
Compiler 518MB ± 0% 518MB ± 0% -0.04% (p=0.000 n=9+10)
Passes toolstash -cmp.
Change-Id: I0e603266b5d7d4e405106a26369e22773a0d3a91
Reviewed-on: https://go-review.googlesource.com/31850
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
\\?\c:\ is a "root directory" that is not subject to further matching,
but the ? makes it look like a pattern, which was causing an
infinite recursion. Make sure the code understands the ? is not a pattern.
Fixes#15879.
Change-Id: I3a4310bbc398bcae764b9f8859c875317345e757
Reviewed-on: https://go-review.googlesource.com/31460
Reviewed-by: Quentin Smith <quentin@golang.org>
RFC 3986 §3.3 disallows relative URL paths in which the first segment
contains a colon, presumably to avoid confusion with scheme:foo syntax,
which is exactly what happened in #16822.
Fixes#16822.
Change-Id: Ie4449e1dd21c5e56e3b126e086c3a0b05da7ff24
Reviewed-on: https://go-review.googlesource.com/31582
Reviewed-by: Quentin Smith <quentin@golang.org>
Fixed by CL 31092 already, but that change is a few steps away
from the problem observed here, so add an explicit test.
Fixes#17019.
Change-Id: If4ece1418e6596b1976961347889ce12c5969637
Reviewed-on: https://go-review.googlesource.com/31466
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
All prior versions of Go have allowed redefining empty templates
to become non-empty. Unfortunately, that has never consistently
taken effect in html/template after the first execution:
// define and execute
t := template.New("root")
t.Parse(`{{define "T"}}{{end}}<a href="{{template "T"}}">`)
t.Execute(w, nil) // <a href="">
// redefine
t.Parse(`{{define "T"}}my.url{{end}}`) // succeeds, but ignored
t.Execute(w, nil) // <a href="">
When Go 1.6 added {{block...}} to text/template, that loosened the
redefinition rules to allow redefinition at any time. The loosening was
undone a bit in html/template, although inconsistently:
// define and execute
t := template.New("root")
t.Parse(`{{define "T"}}body{{end}}`)
t.Lookup("T").Execute(ioutil.Discard, nil)
// attempt to redefine
t.Parse(`{{define "T"}}body{{end}}`) // rejected in all Go versions
t.Lookup("T").Parse("body") // OK as of Go 1.6, likely unintentionally
Like in the empty->non-empty case, whether future execution takes
notice of a redefinition basically can't be explained without going into
the details of the template escape analysis.
Address both the original inconsistencies in whether a redefinition
would have any effect and the new inconsistencies about whether a
redefinition is allowed by adopting a new rule: no parsing or modifying
any templates after the first execution of any template in the same set.
Template analysis begins at first execution, and once template analysis
has begun, we simply don't have the right logic to update the analysis
for incremental modifications (and never have).
If this new rule breaks existing uses of templates that we decide need
to be supported, we can try to invalidate all escape analysis for the
entire set after any modifications. But let's wait on that until we know
we need to and why.
Also fix documentation of text/template redefinition policy
(redefinition is always OK).
Fixes#15761.
Change-Id: I7d58d7c08a7d9df2440ee0d651a5b2ecaff3006c
Reviewed-on: https://go-review.googlesource.com/31464
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
The Go resolver reports invalid domain name for '!!!.local',
but that is allowed by multicast DNS. In general we can't predict
what future relaxations might come along, and libc resolvers
do not distinguish 'no such host' from 'invalid name', so stop
making that distinction here too. Always use 'no such host'.
Fixes#12421.
Change-Id: I8f22604767ec9e270434e483da52b337833bad71
Reviewed-on: https://go-review.googlesource.com/31468
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This is the documented (and now implemented) behavior.
Fixes#16841.
Change-Id: Ic75adc5ba18303ed9578e04284f32933f905d6a3
Reviewed-on: https://go-review.googlesource.com/31577
Reviewed-by: Quentin Smith <quentin@golang.org>
If a directory in GOPATH is unreadable, we should keep looking for other
packages. Otherwise we can give the misleading error "no buildable Go
source files".
Fixes#16240
Change-Id: I38e1037f56ec463d3c141f0508fb74211cb90f13
Reviewed-on: https://go-review.googlesource.com/31713
Run-TryBot: Quentin Smith <quentin@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
What matters during go get -u is not whether there is an import comment
but whether we resolved the path by an HTML <meta> tag.
Fixes#16471.
Change-Id: I6b194a3f73a7962a0170b4d5cf51cfed74e02c00
Reviewed-on: https://go-review.googlesource.com/31658
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
Maybe the go generate is generating the imports,
or maybe there's some other good reason the code
is incomplete.
The help text already says:
Note that go generate does not parse the file, so lines that look
like directives in comments or multiline strings will be treated
as directives.
We'll still reject Go source files that don't begin with a package statement
or have a syntax error in the import block, but those are I think more
defensible rejections.
Fixes#16307.
Change-Id: I4f8496c02fdff993f038adfed2df4db7f067dc06
Reviewed-on: https://go-review.googlesource.com/31659
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
It's always been like this, so document it.
Fixes#14351.
Change-Id: Ic6a7c44881bac0209fa6863a487fabec5ec0214e
Reviewed-on: https://go-review.googlesource.com/31663
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
Avoid crash in the specific case reported in #15201 but also
print more useful error message, avoiding slice panic.
Fixes#15201.
Fixes#16167.
Fixes#16566.
Change-Id: I66499621e9678a05bc9b12b0da77906cd7027bdd
Reviewed-on: https://go-review.googlesource.com/31665
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Quentin Smith <quentin@golang.org>
After resizing the scan buffer, we can immediately read into the
newly-resized buffer since we know there is now space.
Fixes#15712.
Change-Id: I56fcfaeb67045ee753a012c37883aa7c81b6e877
Reviewed-on: https://go-review.googlesource.com/31715
Run-TryBot: Quentin Smith <quentin@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Makes windows same as others.
Change-Id: Ib4651e06d0bd37473ac345d36c91f39aa8f5e662
Reviewed-on: https://go-review.googlesource.com/31791
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Currently mspan.isFree technically returns whether the object was not
allocated *during this cycle*. Fix it so it actually returns whether
or not the object is allocated so the method is more generally useful
(especially for debugging).
It has one caller, which is carefully written to be insensitive to
this distinction, but this lets us simplify this caller.
Change-Id: I9d79cf784a56015e434961733093c1d8d03fc091
Reviewed-on: https://go-review.googlesource.com/30145
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rick Hudson <rlh@golang.org>
morestack writes the context pointer to gobuf.ctxt, but since
morestack is written in assembly (and has to be very careful with
state), it does *not* invoke the requisite write barrier for this
write. Instead, we patch this up later, in newstack, where we invoke
an explicit write barrier for ctxt.
This already requires some subtle reasoning, and it's going to get a
lot hairier with the hybrid barrier.
Fix this by simplifying the whole mechanism. Instead of writing
gobuf.ctxt in morestack, just pass the value of the context register
to newstack and let it write it to gobuf.ctxt. This is a normal Go
pointer write, so it gets the normal Go write barrier. No subtle
reasoning required.
Updates #17503.
Change-Id: Ia6bf8459bfefc6828f53682ade32c02412e4db63
Reviewed-on: https://go-review.googlesource.com/31550
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
