Document that *os.File is subject to resource limits
for concurrent operations. We aren't documenting
a specific number of concurrent operations because that
number is OS/system dependent. This limit comes from:
internal/poll/fd_mutex.go
where we use 20 bits to count locks.
Fixes#32544
Change-Id: I7d305d4aaba5b2dbc6f1ab8c447117fde5e31a66
Reviewed-on: https://go-review.googlesource.com/c/go/+/181841
Reviewed-by: Rob Pike <r@golang.org>
This reverts CL 176098.
Reason for revert: added complexity, but did not completely fix the
underlying problem. A complete solution would not be worth the
complexity, and as a partial solution this is probably not worth the
complexity either.
Updates #31859
Change-Id: Ifd34c292fd1b811c60afe3c339e5edd3f37190c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/186817
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Caleb Spare <cespare@gmail.com>
Currently, GODEBUG=sbrk=1 mode aligns allocations by their type's
alignment. You would think this would be the right thing to do, but
because 64-bit fields are only 4-byte aligned right now (see #599),
this can cause a 64-bit field of an allocated object to be 4-byte
aligned, but not 8-byte aligned. If there is an atomic access to that
unaligned 64-bit field, it will crash.
This doesn't happen in normal allocation mode because the
size-segregated allocation and the current size classes will cause any
types larger than 8 bytes to be 8 byte aligned.
We fix this by making sbrk=1 mode use alignment based on the type's
size rather than its declared alignment. This matches how the tiny
allocator aligns allocations.
This was tested with
GOARCH=386 GODEBUG=sbrk=1 go test sync/atomic
This crashes with an unaligned access before this change, and passes
with this change.
This should be reverted when/if we fix#599.
Fixes#33159.
Change-Id: Ifc52c72c6b99c5d370476685271baa43ad907565
Reviewed-on: https://go-review.googlesource.com/c/go/+/186919
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
'go test' uses the Root field to determine the set of files that
invalidate test results, and there is no other sensible meaning of
“root” for code within a module.
Fixes#29111
Change-Id: Icf1be90a26d22665613e42cb968087b63c36e74c
Reviewed-on: https://go-review.googlesource.com/c/go/+/154100
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The go command invokes each tool with -V=full to discover its version
to compute a tool id. For release versions (that don't include the
word "devel"), the go command only used the third word in
the output (e.g., "go1.13"), ignoring any toolchain experiments that
followed. With this change, the go command will use whole version line
in the tool id for release versions.
Also, when -V=full is set and there are non-default experiments,
experiments are no longer printed twice.
Fixes#33091
Change-Id: I19b96f939c7e2fbc5d8befe3659156ee4b58daef
Reviewed-on: https://go-review.googlesource.com/c/go/+/186200
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
In Go1.12 and below, the logic in ReverseProxy.ServeHTTP would always
allocate request.Header even if it were not present in the incoming request.
CL 174324 added http.Request.Clone and re-factors ReverseProxy.ServeHTTP
to use the new Clone method. However, the new Clone logic is not equivalent
to the former logic. We preserve former semantics by explicitly allocating
the Header map if nil.
Fixes#33142
Change-Id: I356f94a915dd9779584ce3fe31e56e5474b9ad37
Reviewed-on: https://go-review.googlesource.com/c/go/+/186437
Run-TryBot: Joe Tsai <thebrokentoaster@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Changes "was loaded as" to "was required as". This is slightly more
precise, since it hints at a requirement edge in the module version
graph.
Updates #28489
Change-Id: I636268c33f1ea9858c214fe275f271538186ed6d
Reviewed-on: https://go-review.googlesource.com/c/go/+/186377
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
With gccgo, if we generate getg inlined, the backend may cache
the address of the TLS variable, which will become invalid after
a thread switch.
Currently there is no known bug for this. But if we didn't
implement this carefully, we may get subtle bugs. This CL adds a
test that will fail loudly if this is wrong. (See also
https://go.googlesource.com/gofrontend/+/refs/heads/master/libgo/runtime/proc.c#333
and an incorrect attempt CL 185337.)
Note: at least on Linux/AMD64, even with an incorrect
implementation, this only fails if the test is compiled with
-fPIC, which is not the default setting for gccgo test suite. So
some manual work is needed. Maybe we could extend the test suite
to run the runtime test with more settings (e.g. PIC and static).
Change-Id: I459a3b4c31f09b9785c0eca19b7756f80e8ef54c
Reviewed-on: https://go-review.googlesource.com/c/go/+/186357
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Do not allow a pseudo-version derived from a canonical tag to refer to
the same revision as the tag itself. It's unnecessary (because
canonical tags already have a total ordering) and confusing (the
pseudo-version appears to come after the tag, but actually refers to
the exact same revision).
Updates #32879
Updates #27173
Change-Id: I02befedbe89c8819bdd93e470783ce63fc813193
Reviewed-on: https://go-review.googlesource.com/c/go/+/184720
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
This error occurs when a module is loaded with one name (for example,
github.com/golang/lint) but declares a different path in its go.mod
(golang.org/x/lint). The current text "unexpected module path" is
confusing. It doesn't explain why the path was unexpected, and it's
not clear what was expected.
With this change, the error text includes the module and version
containing the go.mod file with the error, the declared module path,
and the loaded module path. The paths are vertically aligned so
differences are visually obvious. As with other module version errors,
the shortest chain of requirements is printed.
This change supercedes CL 158477.
Fixes#28489
Change-Id: Ieb07d00bcae182376d7be6aad111c84fbf784354
Reviewed-on: https://go-review.googlesource.com/c/go/+/185985
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
These functions are compiler generated, and as such are only available
in the internal ABI. Doing this avoids generating an alias symbol.
Doing that avoids confusion between unmangled and mangled type symbols.
Fixes#30768
Change-Id: I197a5ba6403aac11989ffa951dbe35bd0506de91
Reviewed-on: https://go-review.googlesource.com/c/go/+/186077
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
If the module path declared in the go.mod file does not match the path
we are trying to resolve, a build using that module is doomed to fail.
Since we know that the module path does not match in the underlying
repo, we also know that the requested module does not exist at the
requested version.
Therefore, we should reject that version in Stat with a “not exist”
error — sooner rather than later — so that modload.Query will continue
to check other candidate paths (for example, with a major-version
suffix added or removed).
Fixes#33099
Change-Id: I43c980f78ed75fa6ace90f237cc3aad46c22d83a
Reviewed-on: https://go-review.googlesource.com/c/go/+/186237
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Session resumption is not a reliable TLS behavior: the server can decide
to reject a session ticket for a number of reasons, or no reason at all.
This makes this non-hermetic test extremely brittle.
It's currently broken on the builders for both TLS 1.2 and TLS 1.3, and
I could reproduce the issue for TLS 1.3 only. As I was debugging it, it
started passing entirely on my machine.
In practice, it doesn't get us any coverage as resumption is already
tested with the recorded exchange tests, and TestVerifyHostname still
provides a smoke test checking that we can in fact talk TLS.
Fixes#32978
Change-Id: I63505e22ff7704f25ad700d46e4ff14850ba5d3c
Reviewed-on: https://go-review.googlesource.com/c/go/+/186239
Run-TryBot: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This is a more minimial fix for the immediate symptom of 32917 and
30590, but does not improve 'list -e' behavior or error
messages resulting from other package loading issues.
Fixes#32917Fixes#30590
Change-Id: I6088d14d864410159ebf228d9392d186322fd2a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/185417
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The go test result must not be cached when each of known variables to go
command change.
To do this, add all known variables to test metadata.
Fixes#32285
Change-Id: I90be6a72f46c42d965aec4fed534c0623244cd3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/179040
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Add "upgrade" and "patch" to 'go help modules' section 'Module queries'.
Also explicitly call out the fact that @v2 will select the latest
version starting with v2, not the branch named v2, since this is a
common source of confusion.
Fixes#33010
Change-Id: I2fe27543b81a160fb6f6b8e8444a7a35f3661433
Reviewed-on: https://go-review.googlesource.com/c/go/+/185979
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
We already skipped rewriting the call if there were fewer args than
parameters. But we can also get a cgo crash if there are more args,
if at least one of the extra args uses a name qualified with "C.".
Skip the rewrite, since the build will fail later anyhow.
Fixes#33061
Change-Id: I62ff3518b775b502ad10c2bacf9102db4c9a531c
Reviewed-on: https://go-review.googlesource.com/c/go/+/185797
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
This test sometimes times out when the machine is busy.
The reason behind is still a bit blurry. But it seems to comes from
the fact that on AIX, once a listen is performed a socket, every
connection will be accepted even before an accept is made (which only
occurs when a machine is busy). On Linux, a socket is created as a
"passive socket" which seems to wait for the accept before allowing
incoming connections.
Updates #29685
Change-Id: I41b053b7d5f5b4420b72d6a217be72e41220d769
Reviewed-on: https://go-review.googlesource.com/c/go/+/185717
Run-TryBot: Clément Chigot <clement.chigot@atos.net>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Update NewReplacer documentation to specify that in the case of
multiple matches at the same position, the matching old/new
pair that appears first in NewReplacer arguments takes precedence.
Fixes#32699
Change-Id: I9d0616d28e5cd8c9bfa301be201f2b0ebf361dff
Reviewed-on: https://go-review.googlesource.com/c/go/+/185099
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
This adds comments explaining why it's important that some panics are
allowed in the runtime (even though this isn't ideal).
Change-Id: I04c6fc4f792f3793f951619ccaea6bfef2f1763c
Reviewed-on: https://go-review.googlesource.com/c/go/+/181737
Reviewed-by: Keith Randall <khr@golang.org>
According to the documentation "When passing a pointer to a field in a
struct, the Go memory in question is the memory occupied by the field,
not the entire struct.". checkAddr states that this should also work
with type conversions, which is implemented in isType. However,
ast.StarExpr must be enclosed in ast.ParenExpr according to the go spec
(see example below), which is not considered in the checks.
Example:
// struct Si { int i; int *p; }; void f(struct I *x) {}
import "C"
type S {
p *int
i C.struct_Si
}
func main() {
v := &S{new(int)}
C.f((*C.struct_I)(&v.i)) // <- panic
}
This example will cause cgo to emit a cgoCheck that checks the whole
struct S instead of just S.i causing the panic "cgo argument has Go
pointer to Go pointer".
This patch fixes this situation by adding support for ast.ParenExpr to
isType and adds a test, that fails without the fix.
Fixes#32970.
Change-Id: I15ea28c98f839e9fa708859ed107a2e5f1483133
Reviewed-on: https://go-review.googlesource.com/c/go/+/185098
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For OLSH/ORSH, the right node is not a uintptr-typed. However,
unsafeValue still be called recursively for it, causing the
compiler crashes.
To fixing, the right node only needs to be evaluated
for side-effects, so just discard its value.
Fixes#32959
Change-Id: I34d5aa0823a0545f6dad1ec34774235ecf11addc
Reviewed-on: https://go-review.googlesource.com/c/go/+/185039
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This reverts commit https://golang.org/cl/161177/.
Reason for revert: this led to non-contiguous comments spaced
by an empty line to be grouped into a single CommentGroup
Fixes#32944
Updates #10858
Change-Id: I5e16663b308c3b560496da8e66c33befdf9ed9dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/185040
Reviewed-by: Robert Griesemer <gri@golang.org>
There were at least three races in the implementation of the pool of
idle HTTP connections before this CL.
The first race is that HTTP/2 connections can be shared for many
requests, but each requesting goroutine would take the connection out
of the pool and then immediately return it before using it; this
created unnecessary, tiny little race windows during which another
goroutine might dial a second connection instead of reusing the first.
This CL changes the idle pool to just leave the HTTP/2 connection in
the pool permanently (until there is reason to close it), instead of
doing the take-it-out-put-it-back dance race.
The second race is that “is there an idle connection?” and
“register to wait for an idle connection” were implemented as two
separate steps, in different critical sections. So a client could end
up registered to wait for an idle connection and be waiting or perhaps
dialing, not having noticed the idle connection sitting in the pool
that arrived between the two steps.
The third race is that t.getIdleConnCh assumes that the inability to
send on the channel means the client doesn't need the result, when it
could mean that the client has not yet entered the select.
That is, the main dial does:
idleConnCh := t.getIdleConnCh(cm)
select {
case v := <-dialc:
...
case pc := <-idleConnCh
...
...
}
But then tryPutIdleConn does:
waitingDialer := t.idleConnCh[key] // what getIdleConnCh(cm) returned
select {
case waitingDialer <- pconn:
// We're done ...
return nil
default:
if waitingDialer != nil {
// They had populated this, but their dial won
// first, so we can clean up this map entry.
delete(t.idleConnCh, key)
}
}
If the client has returned from getIdleConnCh but not yet reached the
select, tryPutIdleConn will be unable to do the send, incorrectly
conclude that the client does not care anymore, and put the connection
in the idle pool instead, again leaving the client dialing unnecessarily
while a connection sits in the idle pool.
(It's also odd that the success case does not clean up the map entry,
and also that the map has room for only a single waiting goroutine for
a given host.)
None of these races mattered too much before Go 1.11: at most they
meant that connections were not reused quite as promptly as possible,
or a few more than necessary would be created. But Go 1.11 added
Transport.MaxConnsPerHost, which limited the number of connections
created for a given host. The default is 0 (unlimited), but if a user
did explicitly impose a low limit (2 is common), all these misplaced
conns could easily add up to the entire limit, causing a deadlock.
This was causing intermittent timeouts in TestTransportMaxConnsPerHost.
The addition of the MaxConnsPerHost support added its own races.
For example, here t.incHostConnCount could increment the count
and return a channel ready for receiving, and then the client would
not receive from it nor ever issue the decrement, because the select
need not evaluate these two cases in order:
select {
case <-t.incHostConnCount(cmKey):
// count below conn per host limit; proceed
case pc := <-t.getIdleConnCh(cm):
if trace != nil && trace.GotConn != nil {
trace.GotConn(httptrace.GotConnInfo{Conn: pc.conn, Reused: pc.isReused()})
}
return pc, nil
...
}
Obviously, unmatched increments are another way to get to a deadlock.
TestTransportMaxConnsPerHost deadlocked approximately 100% of
the time with a small random sleep added between incHostConnCount
and the select:
ch := t.incHostConnCount(cmKey):
time.Sleep(time.Duration(rand.Intn(10))*time.Millisecond)
select {
case <-ch
// count below conn per host limit; proceed
case pc := <-t.getIdleConnCh(cm):
...
}
The limit also did not properly apply to HTTP/2, because of the
decrement being attached to the underlying net.Conn.Close
and net/http not having access to the underlying HTTP/2 conn.
The alternate decrements for HTTP/2 may also have introduced
spurious decrements (discussion in #29889). Perhaps those
spurious decrements or other races caused the other intermittent
non-deadlock failures in TestTransportMaxConnsPerHost,
in which the HTTP/2 phase created too many connections (#31982).
This CL replaces the buggy, racy code with new code that is hopefully
neither buggy nor racy.
Fixes#29889.
Fixes#31982.
Fixes#32336.
Change-Id: I0dfac3a6fe8a6cdf5f0853722781fe2ec071ac97
Reviewed-on: https://go-review.googlesource.com/c/go/+/184262
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
It wasn't obeyed in the case where the MarshalJSON method uses a pointer
receiver, and the encoder grabs the address of a value to find that
method. addrMarshalerEncoder is the function that does this work, but it
ignored opts.escapeHTML.
Here's the before and after of the added test case, which was failing
before the fix. Now the two cases are correct and consistent.
{"NonPtr":"<str>","Ptr":"\u003cstr\u003e"}
{"NonPtr":"<str>","Ptr":"<str>"}
Fixes#32896.
Change-Id: Idc53077ece074973558bd3bb5ad036380db0d02c
Reviewed-on: https://go-review.googlesource.com/c/go/+/184757
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Caleb Spare <cespare@gmail.com>
cgo produces dynamic imports for Go binaries by scanning the dynamic
imports table of a binary produced by the system C compiler and
linker. Currently, since it uses elf.File.ImportedSymbols, it only
reads global symbols. Unfortunately, recent versions of lld emit weak
symbol imports for several pthread symbols, which means the cgo tool
doesn't emit dynamic imports for them, which ultimately causes linking
of cgo binaries to fail.
Fix this by using elf.File.DynamicSymbols instead and filtering down
to both global and weak symbols.
Fixes#31912.
Change-Id: If346a7eca6733e3bfa2cccf74a9cda02a3e81d38
Reviewed-on: https://go-review.googlesource.com/c/go/+/184100
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently, File.ImportedSymbols is the only API that exposes the GNU
symbol version information for dynamic symbols. Unfortunately, it also
filters to specific types of symbols, and only returns symbol names.
The cgo tool is going to need symbol version information for more
symbols. In order to support this and make the API more orthogonal,
this CL adds version information to the Symbol type and updates
File.DynamicSymbols to fill this in. This has the downside of
increasing the size of Symbol, but seems to be the most natural API
for exposing this. I also explored 1) adding a method to get the
version information for the i'th dynamic symbol, but we don't use
symbol indexes anywhere else in the API, and it's not clear if this
index would be 0-based or 1-based, and 2) adding a
DynamicSymbolVersions method that returns a slice of version
information that parallels the DynamicSymbols slice, but that's less
efficient to implement and harder to use.
For #31912.
Change-Id: I69052ac3894f7af2aa9561f7085275130e0cf717
Reviewed-on: https://go-review.googlesource.com/c/go/+/184099
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Running the example code when not having permissions
to bind to port 80 will cause the program to hang after
printing the error message.
Change-Id: I2433ba2629b362fc8f1731e40cab5eea72ec354f
GitHub-Last-Rev: 0bb3dc08b6
GitHub-Pull-Request: golang/go#32947
Reviewed-on: https://go-review.googlesource.com/c/go/+/185157
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This should have been part of CL 184440.
Updates #32846
Change-Id: I78a1326f4a67b3b526859bd15cb9653b4a8551a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/184920
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
'go get path@latest' may now downgrade a module required at a
pre-release or pseudo-version newer than the latest released
version. This restores the 1.12 behavior and the ability to easily
roll back from a temporary development version.
'go get path@upgrade' is like @latest but will not downgrade.
If no version suffix is specified ('go get path'), @upgrade is
implied.
Fixes#32846
Change-Id: Ibec0628292ab1c484716a5add0950d7a7ee45f47
Reviewed-on: https://go-review.googlesource.com/c/go/+/184440
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The documentation just said "alphanumeric", but underscores and dots
are also accepted.
Fixes#32886
Change-Id: I1ba872a220d5c5bf64f1d851ddba9eb3b1afb89a
Reviewed-on: https://go-review.googlesource.com/c/go/+/184917
Reviewed-by: Bryan C. Mills <bcmills@google.com>
I accidentally fetched an invalid version of rsc.io/quote from
proxy.golang.org, which the proxy then cached and now includes in
https://proxy.golang.org/rsc.io/quote/@v/list.
That causes 'go get rsc.io/quote` to resolve to a different version
depending on whether the proxy is used.
Adjust the test to fetch an explicit version instead, since the choice
of 'latest' is mostly irrelevant to the checksum database logic that
the test is intended to verify.
Updates #32805Fixes#32900
Change-Id: I075b1f62e8c71545d0fb2dd4bd77ba525fc2a36d
Reviewed-on: https://go-review.googlesource.com/c/go/+/184719
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Taking over CL 162240, the original CL hasn't been making progress.
I just took the parts that fix the immediate issue. I left the
signatslice changes out, I don't think they are necessary.
Fixes#30202
Change-Id: I5b347605f0841dd925d5a73150b8bf269fa82464
Reviewed-on: https://go-review.googlesource.com/c/go/+/183852
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
It's not correct to use atomic.CompareAndSwap to implement Once.Do,
and we don't, but why we don't is a question that has come up
twice on golang-dev in the past few months.
Add a comment to help others with the same question.
Change-Id: Ia89ec9715cc5442c6e7f13e57a49c6cfe664d32c
Reviewed-on: https://go-review.googlesource.com/c/go/+/184261
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ingo Oeser <nightlyone@googlemail.com>
The implementation of semaphores, and therefore notes, used on Darwin
is not async-signal-safe. The runtime has one case where a note needs
to be woken up from a signal handler: the call to notewakeup in sigsend.
That notewakeup call is only called on a single note, and it doesn't
need the full functionality of notes: nothing ever does a timed wait on it.
So change that one note to use a different implementation on Darwin,
based on a pipe. This lets the wakeup code use the write call, which is
async-signal-safe.
Fixes#31264
Change-Id: If705072d7a961dd908ea9d639c8d12b222c64806
Reviewed-on: https://go-review.googlesource.com/c/go/+/184169
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The localPipe implementation assumes that every successful net.Dial
results in exactly one successful listener.Accept. I don't believe this
is guaranteed by essentially any operating system. For this test, we're
seeing flakes on dragonfly (#29583).
But see also #19519, flakes due to the same assumption on FreeBSD
and macOS in package net's own tests.
This CL rewrites localPipe to try a few times to get a matching pair
of connections on the dial and accept side.
Fixes#29583.
Change-Id: Idb045b18c404eae457f091df20456c5ae879a291
Reviewed-on: https://go-review.googlesource.com/c/go/+/184157
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TestVariousDeadlines starts a client and server.
The client dials the server, sets a timeout on the connection,
reads from it, gets a timeout error, closes the connection.
The server writes an infinite stream of a's to each connection
it accepts.
The test was trying to run these in lockstep:
run a client dial+read+timeout+close,
wait for server to accept+write+error out on write to closed connection,
repeat.
On FreeBSD 11.2 and less frequently on macOS we see
the test timeout waiting for the server to do its half of
the lockstep dance.
I believe the problem is that the client can do its step
of the dance with such a short timeout that the read,
timeout, and close happens before the server ever returns
from the accept(2) system call. For the purposes of testing
the client-side read timeout, this is fine. But I suspect
that under some circumstances, the "TCP-accepted"
connection does not translate into a "socket-layer-accepted"
connection that triggers a return from accept(2).
That is, the Go server never sees the connection at all.
And the test sits there waiting for it to acknowledge
being done with a connection it never started with.
Fix the problem by not trying to lockstep with the server.
This definitely fixes the flake, since the specific line that
was calling t.Fatal is now deleted.
This exposes a different flake, seen on a trybot run for an
early version of this CL, in which the client's io.Copy does
not stop within the time allotted. The problem now is that
there is no guarantee that a read beyond the deadline with
available data returns an error instead of the available data,
yet the test assumes this guarantee, and in fact the opposite
is usually true - we don't bother checking the deadline unless
the read needs to block. That is, deadlines don't cut off a
flood of available data, yet this test thinks they do.
This CL therefore also changes the server not to send an
infinite flood of data - don't send any data at all - so that
the read deadline is guaranteed to be exercised.
Fixes#19519.
Change-Id: I58057c3ed94ac2aebab140ea597f317abae6e65e
Reviewed-on: https://go-review.googlesource.com/c/go/+/184137
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
CL 42652 changed the profile handler for mips/mipsle to
avoid recording a profile when in atomic functions, for fear
of interrupting the 32-bit simulation of a 64-bit atomic with
a lock. The profile logger itself uses 64-bit atomics and might
deadlock (#20146).
The change was to accumulate a count of dropped profile events
and then send the count when the next ordinary event was sent:
if prof.hz != 0 {
+ if (GOARCH == "mips" || GOARCH == "mipsle") && lostAtomic64Count > 0 {
+ cpuprof.addLostAtomic64(lostAtomic64Count)
+ lostAtomic64Count = 0
+ }
cpuprof.add(gp, stk[:n])
}
CL 117057 extended this behavior to include GOARCH == "arm".
Unfortunately, the inserted cpuprof.addLostAtomic64 differs from
the original cpuprof.add in that it neglects to acquire the lock
protecting the profile buffer.
This has caused a steady stream of flakes on the arm builders
for the past 12 months, ever since CL 117057 landed.
This CL moves the lostAtomic count into the profile buffer and
then lets the existing addExtra calls take care of it, instead of
duplicating the locking logic.
Fixes#24991.
Change-Id: Ia386c40034fcf46b31f080ce18f2420df4bb8004
Reviewed-on: https://go-review.googlesource.com/c/go/+/184164
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The current cmd/doc implementation uses go/build.Import in a few
places to check whether a package is findable and importable.
go/build has limited support for finding packages in modules,
but to do so, build.Import requires knowing the source directory
to use when performing the lookup (so it can find the go.mod file).
Otherwise, it only looks inside the GOPATH workspace.
Start passing the current working directory to build.Import calls,
so that it can correctly look for packages in modules when in cmd/doc
is executed in module mode.
Before this change, cmd/doc in module mode could mistakenly find and
use a package in the GOPATH workspace, instead of the current module.
Since the result of os.Getwd is needed in even more places, assign it
to a local variable in parseArgs now.
Fixes#28992
Updates #26504
Change-Id: I7571618e18420d2d3b3890cc69ade2d97b1962bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/183991
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The scanner was changed to accept the new Go number literal syntax
of which separators are a part. Making them opt-in is inconsistent
with the rest of the changes. For comparison, the strconv package
also accepts the new number literals including separators with the
various conversion routines, if no explicit number base is given.
Updates #28493.
Change-Id: Ifaae2225a9565364610813658bfe692901dd3ccd
Reviewed-on: https://go-review.googlesource.com/c/go/+/184080
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
go/build.Context.Import loads package information using 'go list' when
in module mode. It does this when GO111MODULE is not "off", there is a
go.mod file in any parent directory, and neither the path nor the
source directory are in GOROOT. Import no longer checks whether the
source directory is in GOPATH if GO111MODULE=auto or unset.
Also fixed subdirectory checks that did not handle relative source
directory paths. mod_gobuild_import should have failed when we changed
the meaning of GO111MODULE=auto but didn't because of this.
Fixes#32799
Change-Id: Ic5210b7e00cb58f91ea9455b67b49d5aed4eec63
Reviewed-on: https://go-review.googlesource.com/c/go/+/184098
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Put the sumdb cache in the usual pkg/mod/cache/download dir, rather
than the new pkg/mod/download/cache dir which I presume was a typo.
Change-Id: Id162f24db30f509353178ca0c8cc7a4dabc927e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/183318
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
In TestPoolDequeue it's surprisingly common for the queue to stay
nearly empty the whole time and for a racing PopTail to happen in the
window between the producer doing a PushHead and doing a PopHead. In
short mode, there are only 100 PopTail attempts. On linux/amd64, it's
not uncommon for this to fail 50% of the time. On linux/arm64, it's
not uncommon for this to fail 100% of the time, causing the test to
fail.
This CL fixes this by only checking for a successful PopTail in long
mode. Long mode makes 200,000 PopTail attempts, and has never been
observed to fail.
Fixes#31422.
Change-Id: If464d55eb94fcb0b8d78fbc441d35be9f056a290
Reviewed-on: https://go-review.googlesource.com/c/go/+/183981
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TestPoolDequeue creates P-1 consumer goroutines and 1 producer
goroutine. Currently, if a consumer goroutine pops the last value from
the dequeue, it sets a flag that stops all consumers, but the producer
also periodically pops from the dequeue and doesn't set this flag.
Hence, if the producer were to pop the last element, the consumers
will continue to run and the test won't terminate. This CL fixes this
by also setting the termination flag in the producer.
I believe it's impossible for this to happen right now because the
producer only pops after pushing an element for which j%10==0 and the
last element is either 999 or 1999999, which means it should never try
to pop after pushing the last element. However, we shouldn't depend on
this reasoning.
Change-Id: Icd2bc8d7cb9a79ebfcec99e367c8a2ba76e027d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/183980
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TestPoolDequeue in long mode does a little more than 1<<21 pushes.
This was originally because the head and tail indexes were 21 bits and
the intent was to test wrap-around behavior. However, in the final
version they were both 32 bits, so the test no longer tested
wrap-around.
It would take too long to reach 32-bit wrap around in a test, so
instead we initialize the poolDequeue with indexes that are already
nearly at their limit. This keeps the knowledge of the maximum index
in one place, and lets us test wrap-around even in short mode.
Change-Id: Ib9b8d85b6d9b5be235849c2b32e81c809e806579
Reviewed-on: https://go-review.googlesource.com/c/go/+/183979
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The @latest proxy endpoint is optional. If a proxy returns a 404 for
it, and returns an @v/list with no matching versions, then we should
allow module lookup to try other module paths. However, if the proxy
returns some other error (say, a 403 or 505), then the result of the
lookup is ambiguous, and we should report the actual error rather than
"no matching versions for query".
(This fix was prompted by discussion with Dmitri on CL 183619.)
Updates #32715
Updates #26334
Change-Id: I6d510a5ac24d48d9bc5037c3c747ac50695c663f
Reviewed-on: https://go-review.googlesource.com/c/go/+/183845
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The test currently usses llvm.org, which seems to be very flaky today.
Change-Id: I3d01476d53f94d9170dbb087e3f3cf99581cdb4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/183847
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Currently we use R16 and R17 for ARM64's Duff's devices.
According to ARM64 ABI, R16 and R17 can be used by the (external)
linker as scratch registers in trampolines. So don't use these
registers to pass information across functions.
It seems unlikely that calling Duff's devices would need a
trampoline in normal cases. But it could happen if the call
target is out of the 128 MB direct jump limit.
The choice of R20 and R21 is kind of arbitrary. The register
allocator allocates from low-numbered registers. High numbered
registers are chosen so it is unlikely to hold a live value and
forces a spill.
Fixes#32773.
Change-Id: Id22d555b5afeadd4efcf62797d1580d641c39218
Reviewed-on: https://go-review.googlesource.com/c/go/+/183842
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
When 'go install' is run without arguments in a directory containing a
main package, it deletes an executable file with the same name as the
package (presumably created by 'go build' previously).
'go get' in module mode executes the same code after updating and
downloading modules. However, the special case was misfiring because
we passed an empty list of patterns to InstallPackages.
Fixes#32766
Change-Id: I19aca64ee1fb5a216777dd7d559e8e6a45b3e90c
Reviewed-on: https://go-review.googlesource.com/c/go/+/183846
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Don't attempt to dereference basep if it's nil, just pass it to
getdirentries_freebsd12 as is.
Ported from x/sys/unix CL 183223
Change-Id: Id1c4e0eb6ff36dd39524da8194fed9a5957bce61
Reviewed-on: https://go-review.googlesource.com/c/go/+/183797
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It would be nice to have a test, but it requires running
this under the race detector which is a bit complicated
to set up; yet the fix is trivial. Verified manually that
it doesn't trip the race detector.
Fixes#32154.
Change-Id: I20bd746a07945c802f0476a1d8b1dfd83c87dae8
Reviewed-on: https://go-review.googlesource.com/c/go/+/183849
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It ends up making two similar types, [N]uint8 of both
alg and noalg varieties. Comparsions between the two then
don't come out equal when they should.
In particular, the type *[N]uint8 has an Elem pointer which
must point to one of the above two types; it can't point to both.
Thus allocating a *[N]uint8 and dereferencing it might be a
different type than a [N]uint8.
The fix is easy. Making a small test for this is really hard. It
requires that both a argless defer and the test be imported by a
common parent package. This is why a main binary doesn't see this
issue, but a test does (as Agniva noticed), because there's a wrapper
package that imports both the test and the defer.
Types like [N]uint8 don't really need to be marked noalg anyway,
as the generated code (if any) will be shared among all
vanilla memory types of the same size.
Fixes#32595
Change-Id: If7b77fa6ed56cd4495601c3f90170682d853b82f
Reviewed-on: https://go-review.googlesource.com/c/go/+/182357
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When mod init with given module path, validate that module path is a
valid import path.
Note that module.CheckImportPath is used, because module.CheckPath
verifies that module path is something that "go get" can fetch, which is
strictly stronger condition than "a valid module path".
Updates #28389Fixes#32644
Change-Id: Ia60f218dd7d79186f87be723c28a96d6cb63017e
Reviewed-on: https://go-review.googlesource.com/c/go/+/182560
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The /list files in the module cache include pseudo-versions, but the
documentation for (*modfetch).Repo.Versions explicitly states that
they are not included in the output of that method.
Fixes#32715
Change-Id: Ieba1500b91f52b5fa689e70e16dbe3ad40de20f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/183402
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
CL 181881 added structured error types for direct fetches.
Use those same structured errors to format proxy errors consistently.
Also ensure that an empty @v/list is treated as equivalent to the module
not existing at all.
Updates #27173
Updates #32715
Change-Id: I203fd8259bc4f28b3389745f1a1fde936b0fa24d
Reviewed-on: https://go-review.googlesource.com/c/go/+/183619
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
In sigtramp of sys_darwin_arm.s, the callee-save register R4 is
saved to the stack, but later R2 is also saved to the save position.
That CL fixes the unexpected lost of the value in R4.
fixes#32744
Change-Id: Ifaeb99f11e4abf0c79bec9da67e0db97c358010c
Reviewed-on: https://go-review.googlesource.com/c/go/+/183517
Run-TryBot: Ben Shi <powerman1st@163.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ensure that during rewriting of expressions that take the address of
an array, that we properly recognize *ast.IndexExpr as an operation
to create a pointer variable and thus assign the proper addressOf
and deference operators as "&" and "*" respectively.
This fixes a regression from CL 142884.
Fixed#32579
Change-Id: I3cb78becff4f8035d66fc5536e5b52857eacaa3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/183458
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The first call of ar must not show its output in order to avoid useless
error messages about D flag.
Change-Id: I3a2f5144b3bb271705000b67cd46cd02e98aca77
Reviewed-on: https://go-review.googlesource.com/c/go/+/182077
Run-TryBot: Clément Chigot <clement.chigot@atos.net>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
If we have found a repository at the requested version but it does not
contain a go.mod file in an appropriate subdirectory, then the module
with the given path does not exist at that version. Therefore, we
should report it with an error equivalent to os.ErrNotExist so that
modload.Query will continue to check other possible module paths.
Updates #27173
Change-Id: Ica73f4bb97f58e611a7f7d38183ee52fef5ee69a
Reviewed-on: https://go-review.googlesource.com/c/go/+/183618
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Previously, most operations involving pseudo-versions allowed any
arbitrary combination of version string and date, and would resolve to
the underlying revision (typically a Git commit hash) as long as that
revision existed.
There are a number of problems with that approach:
• The pseudo-version participates in minimal version selection. If its
version prefix is inaccurate, the pseudo-version may appear to have
higher precedence that the releases that follow it, effectively
“pinning” the module to that commit. For release tags, module
authors are the ones who make the decision about release tagging;
they should also have control over the pseudo-version precedence
within their module.
• The commit date within the pseudo-version provides a total order
among pseudo-versions. If it is not accurate, the pseudo-version
will sort into the wrong place relative to other commits with the
same version prefix.
To address those problems, this change restricts the pseudo-versions
that the 'go' command accepts, rendering some previously
accepted-but-not-canonical versions invalid. A pseudo-version is now
valid only if all of:
1. The tag from which the pseudo-version derives points to the named
revision or one of its ancestors as reported by the underlying VCS
tool, or the pseudo-version is not derived from any tag (that is,
has a "vX.0.0-" prefix before the date string and uses the lowest
major version appropriate to the module path).
2. The date string within the pseudo-version matches the UTC timestamp
of the revision as reported by the underlying VCS tool.
3. The short name of the revision within the pseudo-version (such as a
Git hash prefix) is the same as the short name reported by the
underlying cmd/go/internal/modfetch/codehost.Repo. Specifically, if
the short name is a SHA-1 prefix, it must use the same number of
hex digits (12) as codehost.ShortenSHA1.
4. The pseudo-version includes a '+incompatible' suffix only if it is
needed for the corresponding major version, and only if the
underlying module does not have a go.mod file.
We believe that all releases of the 'go' tool have generated
pseudo-versions that meet these constraints. However, a few
pseudo-versions edited by hand or generated by third-party tools do
not. If we discover invalid-but-benign pseudo-versions in widely-used
existing dependencies, we may choose to add a whitelist for those
specific path/version combinations.
―
To work around invalid dependencies in leaf modules, users may add a
'replace' directive from the invalid version to its valid equivalent.
Note that the go command's go.mod parser automatically resolves commit
hashes found in 'replace' directives to the appropriate
pseudo-versions, so in most cases one can write something like:
replace github.com/docker/docker v1.14.0-0.20190319215453-e7b5f7dbe98c => github.com/docker/docker e7b5f7dbe98c
and then run any 'go' command (such as 'go list' or 'go mod tidy') to
resolve it to an appropriate pseudo-version. Note that the invalid
version will still be used in minimal version selection, so this use
of 'replace' directives is an incomplete workaround.
―
One of the common use cases for higher-than-tagged pseudo-versions is
for projects that do parallel development on release branches. For
example, if a project cuts a 'v1.2' release branch at v1.2.0, they may
want future commits on the main branch to show up as pre-releases for
v1.3.0 rather than for v1.2.1 — especially if v1.2.1 is already tagged
on the release branch. (On the other hand, a backport of a patch to
the v1.2 branch should not show up as a pre-release for v1.3.0.)
To address this use-case, module authors can make use of our existing
support for pseudo-versions derived from pre-release tags: if the
author adds an explicit pre-release tag (such as 'v1.3.0-devel') to
the first commit after the branch, then the pseudo-versions for that
commit and its descendents will be derived from that tag and will sort
appropriately in version selection.
―
Updates #27171Fixes#29262Fixes#27173Fixes#32662Fixes#32695
Change-Id: I0d50a538b6fdb0d3080aca9c9c3df1040da1b329
Reviewed-on: https://go-review.googlesource.com/c/go/+/181881
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The old code only normalized decimal integer imaginary number
literals. But with the generalized imaginary number syntax,
the number value may be decimal, binary, octal, or hexadecimal,
integer or floating-point.
The new code only looks at the number pattern. Only for decimal
integer imaginary literals do we need to strip leading zeroes.
The remaining normalization code simply ignore the 'i' suffix.
As a result, the new code is both simpler and shorter.
Fixes#32718.
Change-Id: If43fc962a48ed62002e65d5c81fddbb9bd283984
Reviewed-on: https://go-review.googlesource.com/c/go/+/183378
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Tweak the previous fix for issue 32673 (in CL 182958) to work around
problems with c-shared build mode that crop up on some of the builders
(10.11, 10.12). We now consistently set vmaddr and vmsize to zero
for the DWARF segment regardless of build mode.
Updates #32673
Change-Id: Id1fc213590ad00c28352925e2d754d760e022b5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/183237
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Change-Id: I4a5c7573e13dd85531ee9f4dd2a0d1981bf8cdfa
Reviewed-on: https://go-review.googlesource.com/c/go/+/51412
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This reverts https://golang.org/cl/182258.
The new code caused unpredictable crashes that are not understood. The old code was occasionally flaky but still better than this approach.
Fixes#32655
Updates #31264
Change-Id: I2e9d27d6052e84bf75106d8b844549ba4f571695
Reviewed-on: https://go-review.googlesource.com/c/go/+/182880
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
If reading 0 bytes, don't return the error from the underlying
io.Reader if there is still data buffered.
Fixes#32693
Change-Id: I12a97bd6003c638c15d41028942f27edf88340e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/182997
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The RFC recommends checking the X25519 output to ensure it's not the
zero value, to guard against peers trying to remove contributory
behavior.
In TLS there should be enough transcript involvement to mitigate any
attack, and the RSA key exchange would suffer from the same issues by
design, so not proposing a backport.
See #31846
Change-Id: I8e657f8ee8aa72c3f8ca3b124555202638c53f5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/183039
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
Removed cross-dependencies between handshake_server_test.go and
handshake_client_test.go; moved all initialization to TestMain; replaced
SSLKEYLOGFILE environment variable with -keylog flag.
Change-Id: Ida6712daa44e01a2c00658e8a1896087ee88bcb0
Reviewed-on: https://go-review.googlesource.com/c/go/+/183057
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Adam Langley <agl@golang.org>
A missing operand to mergePoint caused lower to place values
in the wrong blocks.
Includes test, belt+suspenders to do both ssa check and verify
the output (was is how the bug was originally observed).
The fixed bug here is very likely present in Go versions
1.9-1.12 on amd64 and s390x
Fixes#32680.
Change-Id: I63e702c4c40602cb795ef71b1691eb704d38ccc7
Reviewed-on: https://go-review.googlesource.com/c/go/+/183059
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This was caused by CL 167748, which removed a special case for command
line arguments starting with "cmd/". This CL restores the behavior
from go1.12.
Fixes#32674
Change-Id: I72180d11fb0261ef0af9632e512bd9c03481b6c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/183058
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Signing with RSA-PSS can uncover faulty crypto.Signer implementations,
and it can fail for (broken) small keys. We'll have to take that
breakage eventually, but it would be nice for it to be opt-out at first.
TLS 1.3 requires RSA-PSS and is opt-out in Go 1.13. Instead of making a
TLS 1.3 opt-out influence a TLS 1.2 behavior, let's wait to add RSA-PSS
to TLS 1.2 until TLS 1.3 is on without opt-out.
Note that since the Client Hello is sent before a protocol version is
selected, we have to advertise RSA-PSS there to support TLS 1.3.
That means that we still support RSA-PSS on the client in TLS 1.2 for
verifying server certificates, which is fine, as all issues arise on the
signing side. We have to be careful not to pick (or consider available)
RSA-PSS on the client for client certificates, though.
We'd expect tests to change only in TLS 1.2:
* the server won't pick PSS to sign the key exchange
(Server-TLSv12-* w/ RSA, TestHandshakeServerRSAPSS);
* the server won't advertise PSS in CertificateRequest
(Server-TLSv12-ClientAuthRequested*, TestClientAuth);
* and the client won't pick PSS for its CertificateVerify
(Client-TLSv12-ClientCert-RSA-*, TestHandshakeClientCertRSAPSS,
Client-TLSv12-Renegotiate* because "R" requests a client cert).
Client-TLSv13-ClientCert-RSA-RSAPSS was updated because of a fix in the test.
This effectively reverts 8834353072.
Testing was made more complex by the undocumented semantics of OpenSSL's
-[client_]sigalgs (see openssl/openssl#9172).
Updates #32425
Change-Id: Iaddeb2df1f5c75cd090cc8321df2ac8e8e7db349
Reviewed-on: https://go-review.googlesource.com/c/go/+/182339
Reviewed-by: Adam Langley <agl@golang.org>
For later versions of MacOS, the dynamic loader is more picky about
enforcing restrictions on __DWARF MachO load commands/segments,
triggering aborts of the form
dyld: malformed mach-o image: segment __DWARF has vmsize < filesize
for Go programs that use cgo on Darwin. The error is being triggered
because the Go linker is setting "vmsize" in the DWARF segment entry
to zero as a way to signal that the DWARF doesn't need to be mapped
into memory at runtime (which we need to continue to do).
This patch changes the initial protection on the __DWARF segment to
zero, which dyld seems to be happy with (this is used for other similar
non-loadable sections such as __LLVM).
Fixes#32673
Change-Id: I9a73449c6d26c172f3d70361719943af381f37e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/182958
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Fix a stale reference to Apple's Mach-O file format reference in the
header comment.
Change-Id: I5f120fd5bf31ee0b8b29a33879305abb31a7913d
Reviewed-on: https://go-review.googlesource.com/c/go/+/182957
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Previously, when we resolved a commit hash (not a complete version),
we always checked the contents of the module cache for any
pseudo-version matching that commit.
However, there are many possible names for a given commit. Generally
the semantically-highest valid name is the best, and that may change
over time as new tags are added, so if we are able to fetch a better
name from upstream we should do so. Otherwise, we should fall back to
the highest appropriate name found in the cache.
Fixes#27171
Updates #27173
Change-Id: Ib5c7d99eb463af84674e969813039cbbee7e395b
Reviewed-on: https://go-review.googlesource.com/c/go/+/182178
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: roger peppe <rogpeppe@gmail.com>
CL 46434 changed the doc for Server.IdleTimeout to include
falling back to Server.ReadHeaderTimeout if both
Server.IdleTimeout and Server.ReadTimeout are zero.
However, we explicitly set the ReadDeadlines firstly based
off Server.IdleTimeout or Server.ReadTimeout before attempting
to read the next request, thus the current doc is incorrect.
This CL reverts CL 46434 and also updates the doc for
Server.ReadHeaderTimeout to documenting falling back
to Server.ReadTimeout, if the former is zero, otherwise
there is no timeout.
Fixes#32053
Change-Id: I43dd0252d1bcee6c29a8529abd84c84a49b2fba9
GitHub-Last-Rev: e1cdb59977
GitHub-Pull-Request: golang/go#32164
Reviewed-on: https://go-review.googlesource.com/c/go/+/178337
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Broadened the regular expression used to test error messages for
failing to connect to "localhost.localdev/sumdb". Some DNS servers
resolve unknown domains like "localhost.localdev" to real IP addresses
to serve ads. We may get a variety of error messages.
Fixes#31779
Change-Id: Ib389c633c9a9f70f8e89bbcba5282a375da4e708
Reviewed-on: https://go-review.googlesource.com/c/go/+/182799
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
There is a subtle distinction between a value
*being* the zero value vs being *equal to* the zero value.
This was discussed at length in #31450.
Using "a zero value" in the docs suggests that there may
be more than zero value. That is possible on the "equal to
zero value" reading, but not the "is zero" reading that we
selected for the semantics of IsZero.
This change attempts to prevent any confusion on this front by
switching to "the zero value" in the documentation.
And while we're here, eliminate a double-space.
(Darn macbook keyboards.)
Change-Id: Iaa02ba297438793f5a90be9919a4d53baef92f8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/182617
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This fixes a regression introduced in CL 180337. When we query a
module at "latest" that has no tagged versions, we tried to use ""
as the version because we used info.Name instead of info.Version. This
only happened when using a proxy: in direct mode, info.Name is set to
the underlying VCS revision, which is fine.
Also: serve "/mod/path/@latest" through our test proxy.
Previously, we served a 404, which made this bug hard to detect.
Fixes#32636
Change-Id: I5c60975656297f862cad66675170e819685ebd39
Reviewed-on: https://go-review.googlesource.com/c/go/+/182697
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This change updates the doc comments of the various ParseGlob functions
and methods to state that they use the semantics of filepath.Match when
matching the file name pattern.
Fixes#30608
Change-Id: Iee4bdc0a2a2f8647d1f9a910e4d72a5de9204d11
Reviewed-on: https://go-review.googlesource.com/c/go/+/179739
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Add a special case to print a generic nil error when context.err is
nil.
Previously, this case was unchecked, leading to a call to (*Error).Error
with a nil receiver, which was triggering a nil pointer access. However,
this bug was masked by the panic-recovery code in package fmt.
I tested this change by running `dlv test` in src/html/template, running
the `continue` command, and verifying that no "bad access" errors are
returned.
Fixes#28854
Change-Id: I0b637b943de003d9efc294f6f1e49b793668d037
Reviewed-on: https://go-review.googlesource.com/c/go/+/181579
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
* In doc/install-source.html, clarify the meaning of $GOBIN and
describe where executables from the Go distribution are
installed. Also describe $GOPATH, since it provides a default value
for $GOBIN and may conflict with $GOROOT.
* Add more detail to 'go help install' as well.
Fixes#31576
Change-Id: Ib8a8c21677c3aa0ebef97a3b587b6f8fe338b80e
Reviewed-on: https://go-review.googlesource.com/c/go/+/182341
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Fixes the test on the linux-arm64-packet builder.
Change-Id: Icaf9edf9542f4f6e3791ca43298a1e7051eaa576
Reviewed-on: https://go-review.googlesource.com/c/go/+/182378
Run-TryBot: Elias Naur <mail@eliasnaur.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
It is forbidden by App Store.
Fixes#31628
Change-Id: Ie6d14a524ee55b57af8db685f3a79f474733add5
Reviewed-on: https://go-review.googlesource.com/c/go/+/182297
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Changes Darwin semaphore support from using pthread mutexes and
condition variables to using dispatch semaphores. Signaling a dispatch
semaphore is async-signal-safe.
Fixes#31264
Change-Id: If0ce47623501db13e3804b14ace5f4d8eaef461e
Reviewed-on: https://go-review.googlesource.com/c/go/+/182258
Reviewed-by: Elias Naur <mail@eliasnaur.com>
Reviewed-by: Keith Randall <khr@golang.org>
Currently, 'go get -u' and 'go get -u=patch' avoid accidentally
downgrading modules by preventing upgrades in two cases:
1) If the current version is a prerelease that is semantically later
than the "latest" or "patch" version.
2) If the current version is a pseudoversion that is chronologically
newer than the "latest" or "patch" version.
With this change, 'go get m@latest' and 'go get m@patch' prevent
downgrades using the same checks.
Also: 'go get m@patch' now works if m is a module path but not a
package path (i.e., there is no package in the module root directory).
Fixes#30634Fixes#32537
Change-Id: I916630c385b5f3ba7c13e0d65ba08f73a1a67829
Reviewed-on: https://go-review.googlesource.com/c/go/+/180337
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Add support for scanning decimal types into values. If the dest
supports the decimal composer interface and the src supports
the decimal decomposer, set the value of the decimal when Scanning.
Add support for sending decimal decomposer interface values
as parameters.
For #30870
Change-Id: Ic5dbf9069df8d56405852b17542a9188d55c2947
Reviewed-on: https://go-review.googlesource.com/c/go/+/174181
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Exposing the underlying driver conn will allow the use of the
standard connection pool while still able to run special function
directly on the driver.
Fixes#29835
Change-Id: Ib6d3b9535e730f008916805ae3bf76e4494c88f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/174182
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Factor the try-on-failure variants are now in the package
cmd/go/internal/robustio.
Add to them a RemoveAll variant using the same retry loop,
and use it to attempt to address the observed flakes in
TestLinkXImportPathEscape.
Fixes#19491
Updates #25965
Updates #28387
Updates #32188
Change-Id: I9db1a0c7537b8aaadccab1b9eca734595668ba29
Reviewed-on: https://go-review.googlesource.com/c/go/+/181541
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Also, in 'go get' in GOPATH mode, report an error for package paths
that start with '-'.
Change-Id: Ic2575381aa2d093ba15c53b893bf2eaded8b6066
Reviewed-on: https://go-review.googlesource.com/c/go/+/181237
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
While it is possible for the connection pool to guard against panics
on every valuer read, this seems like a high cost to be added,
in both code complexity and possible runtime performance.
Most uses of the Valuer will be trivial, like returning
a struct field. Optimize for that case. If sometime may panic the
valuer should itself use recover and return an error.
Fixes#26332
Change-Id: Iad18780b8028f669f5a7841b74a5384d62fb6a7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/170700
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It is too confusing to have to set GONOSUMDB and GONOPROXY
in common use cases, but one cannot be guaranteed to be a
subset of the other.
This CL adds GOPRIVATE, which takes the same kind of pattern list
but is defined as "these patterns are private (non-public) modules".
Today the implication is that GOPRIVATE is the default setting for
GONOSUMDB and GONOPROXY. If there are other accommodations
to make for private packages in the future or in other tools,
having this clear statement of intent will let us do that.
(For example maybe an IDE integration would hyperlink an import
path to godoc.org; consulting GOPRIVATE would be a reasonable
way to decide not to do that for certain imports. In contrast,
consulting GONOPROXY or GONOSUMDB clearly would not.)
Fixes#32184.
Change-Id: If54c12d353c7a0a5c0e0273764140cce3c154a02
Reviewed-on: https://go-review.googlesource.com/c/go/+/181719
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
For int8, int16, and int32, comparing their unsigned value to MaxInt64
to determine non-negativity doesn't make sense, because they have
negative values whose unsigned representation is smaller than that.
Fix is simply to compare with the appropriate upper bound based on the
value type's size.
Fixes#32560.
Change-Id: Ie7afad7a56af92bd890ba5ff33c86d1df06cfd9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/181797
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Make "go test" run the new errorsas vet check by default.
Fixes#31213.
Change-Id: I5c93c000874ffe1c0b6d647bf10de803f414c5c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/179977
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
This change revendors golang.org/x/tools to include the check and
modifies cmd/vet to add it to the command.
CL 179977 will enable the check by default for 'go test'.
Commands run (starting in GOROOT/src):
cd cmd
emacs vet/main.go
go get -u=patch golang.org/x/tools/go/analysis/passes/errorsas@latest
go mod tidy
go mod vendor
cd ..
./make.bash
go test all
Updates #31213
Change-Id: Ic2ba9bd2d31c4c5fd9e7c42ca14e8dc38520c93b
Reviewed-on: https://go-review.googlesource.com/c/go/+/181717
Reviewed-by: Jonathan Amsterdam <jba@google.com>
Check the value of target after As returns true.
Change-Id: I76a2b25fe825ee1dbb5f39f8f0b211c55bd25a4f
Reviewed-on: https://go-review.googlesource.com/c/go/+/181299
Reviewed-by: Bryan C. Mills <bcmills@google.com>
$GOEXE exists and is documented in 'go env', so $exe is redundant and
a bit confusing. Notably, mod_modinfo.txt already assumes that GOEXE
is set (even though it isn't), and thus fails on Windows.
After this CL, `go test cmd/go/...` passes on a windows-amd64-2016
builder. However, given that the $PATH on the builder is very minimal
(#32430) and network access is limited, tests that rely on binaries
(such as 'git') or external networking may still be broken.
Updates #25300
Change-Id: I9d80f2a0fbaa8bc35fa2205b6898aeccecda4e94
Reviewed-on: https://go-review.googlesource.com/c/go/+/181542
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
No references to this function remain; remove it to avoid confusion
and reduce build overhead.
The last reference was removed in CL 167748.
Change-Id: I9d023c5d8904800edd3898fed79aa9f824dfb46a
Reviewed-on: https://go-review.googlesource.com/c/go/+/181548
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Add a helper-function to testenv to make these skips more ergonomic.
Also update a few existing skips in cmd/go/... to use it.
Updates #25300
Change-Id: I4205b4fb2b685dfac1cff3c999f954bff7b0f3c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/181538
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This reverts CL 180761
Reason for revert: Reinstate the stack-allocated defer CL.
There was nothing wrong with the CL proper, but stack allocation of defers exposed two other issues.
Issue #32477: Fix has been submitted as CL 181258.
Issue #32498: Possible fix is CL 181377 (not submitted yet).
Change-Id: I32b3365d5026600069291b068bbba6cb15295eb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/181378
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
On freebsd 12, the system call for getdirentries writes 64 bits to
*basep, even on 32-bit systems. Accomodate that by providing a uint64
to the system call and copy the base to/from that uint64.
The uint64 seems to be a virtual file offset, so failing if the high
bits are not zero should be fine for reasonable-sized directories.
Fixes#32498
Change-Id: Ie22c0d301c6091bd20e813432928b24ab95cc314
Reviewed-on: https://go-review.googlesource.com/c/go/+/181377
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is a followup to CL 181278 and CL 181177.
According to cmd/go/testdata/script/README:
Each line is parsed into a sequence of space-separated command words,
with environment variable expansion and # marking an end-of-line comment.
Adding single quotes around text keeps spaces in that text from being treated
as word separators and also disables environment variable expansion.
We want $HOME to be expanded, so leave it out of the single-quoted
block of text.
I tested this change on macOS, and it makes TestScript/env_write pass.
Fixes#32503
Change-Id: I13621aec82263e5cb6978c13a1ad71d2210a0e42
Reviewed-on: https://go-review.googlesource.com/c/go/+/181418
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
I didn't realise that the trybots don't include any Mac machines, so I
assumed this test change was fine when submitting CL 181177.
In any case, this is a simple fix. I forgot to add the quotes, as the
new UserConfigDir on Mac includes a space.
Change-Id: I0766b966fc41736e9fc859e37f059a3f12788d7a
Reviewed-on: https://go-review.googlesource.com/c/go/+/181278
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The old code used ~/Library/Preferences, which is documented by
Apple as:
This directory contains app-specific preference files. You
should not create files in this directory yourself. Instead, use
the NSUserDefaults class or CFPreferences API to get and set
preference values for your app.
It looks like we missed everything after the first sentence; it's
definitely not the right choice for files that Go programs and users
should be touching directly.
Instead, use ~/Library/Application Support, which is documented as:
Use this directory to store all app data files except those
associated with the user’s documents. For example, you might use
this directory to store app-created data files, configuration
files, templates, or other fixed or modifiable resources that
are managed by the app. An app might use this directory to store
a modifiable copy of resources contained initially in the app’s
bundle. A game might use this directory to store new levels
purchased by the user and downloaded from a server.
This seems in line with what UserConfigDir is for, so use it.
The documentation quotes above are obtained from the surprisingly long
link below:
https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.htmlFixes#32475.
Change-Id: Ic27a6c92d76a5d7a4d4b8eac5cd8472f67a533a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/181177
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Bonventre <andybons@golang.org>
The logic for detecting deferreturn calls is wrong.
We used to look for a relocation whose symbol is runtime.deferreturn
and has an offset of 0. But on some architectures, the relocation
offset is not zero. These include arm (the offset is 0xebfffffe) and
s390x (the offset is 6).
This ends up setting the deferreturn offset at 0, so we end up using
the entry point live map instead of the deferreturn live map in a
frame which defers and then segfaults.
Instead, use the IsDirectCall helper to find calls.
Fixes#32477
Update #6980
Change-Id: Iecb530a7cf6eabd7233be7d0731ffa78873f3a54
Reviewed-on: https://go-review.googlesource.com/c/go/+/181258
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This is the net/http half of #32476. This supplies the method needed
by the other half in x/net/http2 in the already-submitted CL 181259,
which this CL also bundles in h2_bundle.go.
Thanks to Tom Thorogood (@tmthrgd) for the bug report and test.
Fixes#32476
Updates #30694
Change-Id: I79d2a280e486fbf75d116f6695fd3abb61278765
Reviewed-on: https://go-review.googlesource.com/c/go/+/181260
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
dist passes the -allabis flag to the compiler to avoid having to
recreate the cross-package ABI logic from cmd/go. However, we removed
that logic from cmd/go in CL 179863 and replaced it with a different
mechanism that doesn't depend on the build system. Hence, passing
-allabis in dist is no longer necessary.
This CL removes -allabis from dist and, since that was the only use of
it, removes support for it from the compiler as well.
Updates #31230.
Change-Id: Ib005db95755a7028f49c885785e72c3970aea4f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/181079
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The documentation comment was duplicated for each of these methods, and
the LazyProc.Call documentation incorrectly mentioned that Call accepts
only 15 arguments, but it actually accepts 18 now.
To prevent further documentation drift, refer the reader to the
documentation for Proc.Call instead of duplicating it for LazyProc.Call.
In addition, note that LazyProc's Addr, Call, and Find methods each
trigger a procedure lookup.
Change-Id: I6756cf7601fba79d1414ff5a5d6eef900aa590e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/181199
Run-TryBot: Matt Layher <mdlayher@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Checks if modules are enabled in GOPATH mode.
Error message returned when no version is provided. Relevant tests
updated. Test for GO111MODULE=off added.
Fixes#27783
Change-Id: I12cdaced5fa38a9c49c0ecfed4c479eb86ed061f
Reviewed-on: https://go-review.googlesource.com/c/go/+/179998
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
In #32038, it was decided to remove get's -m, since one former use case
is removed, and the other can be done via -d, as pointed by Russ.
However, a user getting this short error might not realise that they can
switch to -d to skip building packages. Add a short mention to point
them in the right direction.
It's important to note "packages", because -m was a flag that acted on
modules, while -d acts on packages. Simply replacing -m with -d might
not be enough in some cases because of that distinction.
Change-Id: I0947b25c4223bdad3cd0e535848527da8db8a16d
Reviewed-on: https://go-review.googlesource.com/c/go/+/179361
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In particular, the returned template isn't independent from the parent.
For example, it can't be parsed concurrently with other children
templates. Only methods which are explicitly safe for concurrent use,
like Execute, may be used concurrently.
Fixes#30281.
Change-Id: Idc84bf4199c035316cdb83b950fd4a8f2a71cd0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/172297
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Andrew Gerrand <adg@golang.org>
This recognizes new features that the gofrontend has started emitting
in the export data to support cross-package inlinable functions.
This is a port of CL 180677 and 180758 from the gofrontend repo.
Change-Id: I48af6e71f9d8b04ba874ea0c204d39d1d461f8ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/181118
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
To pick up the structtag vet fix for 1.13.
Fixes#30846.
Change-Id: I5e011a7db1ffb9435793d533097d768f209c18e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/179999
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
CL 179862 introduced go:linkname directives to create ABI wrappers for
Store and Store64 on s390x, but a concurrent change (CL 180439)
replaced the Go definitions of these functions with assembly
definitions. This resulted in conflicting definitions for the ABI0
symbols, which led to a bootstrap linking failure.
Fix this by removing the now-incorrect go:linkname directives for
Store and Store64. This should fix the linux-s390x builders.
Updates #31230.
Change-Id: I8de8c03c23412fc217d428c0018cc56eb2f9996f
Reviewed-on: https://go-review.googlesource.com/c/go/+/181078
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Somehow I missed these two functions in CL 179863. This should fix the
linux-arm builders.
Updates #31230.
Change-Id: I3f8bef3fac331b505a55c0850b0fbc799b7c06c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/181077
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
The built-in Go resolver works significantly better.
In particular, the use of res_search does not support
CNAME or PTR queries and may not even be thread-safe.
This CL is essentially a revert of CL 166297 plus fixes,
including CL 180842.
See CL 180842 for additional notes about problems
with this approach.
Fixes#31705.
Change-Id: I0a30a0de2fbd04f6c461520fd34378c84aadf66c
Reviewed-on: https://go-review.googlesource.com/c/go/+/180843
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Filippo Valsorda
Dominik Honnef
Emmanuel T Odeke
Jordi Martin
Ian Lance Taylor
Bryan C. Mills
Jay Conrod
Austin Clements
Allen Li
Joe Tsai
Cherry Zhang
LE Manh Cuong
Clément Chigot
Francesco Renzi
Gernot Vormayr
Agniva De Sarker
Russ Cox
Daniel Martí
Patrik Lundin
Keith Randall
Dmitri Shuralyov
Robert Griesemer
Damien Neil
Baokun Lee
Heschi Kreinick
Tobias Klauser
Lynn Boger
Ben Shi
kawakami
Than McIntosh
guitarbum722
Daniel Cormier
David Chase
Michael Brandenburg
Raghavendra Nagaraj
Josh Bleecher Snyder
Andrew Gerrand
Samuel Tan
Elias Naur
Daniel Theophanes
Matthew Dempsky
Jonathan Amsterdam
Andrew Bonventre
Keith Randall
Keith Randall
Brad Fitzpatrick
Matt Layher
Constantin Konstantinidis