| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I64d76a35ad113110cb83117c6ce5d4d923d93c93
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/558789
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
Change-Id: If694ce529393b8ae9c6c55270665efc3a108a3b2
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/558778
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/558784
|
|
spaces before the colon
RFC 7230 is clear about headers with a space before the colon, like
X-Answer : 42
being invalid, but we've been accepting and normalizing them for compatibility
purposes since CL 5690059 in 2012.
On the client side, this is harmless and indeed most browsers behave the same
to this day. On the server side, this becomes a security issue when the
behavior doesn't match that of a reverse proxy sitting in front of the server.
For example, if a WAF accepts them without normalizing them, it might be
possible to bypass its filters, because the Go server would interpret the
header differently. Worse, if the reverse proxy coalesces requests onto a
single HTTP/1.1 connection to a Go server, the understanding of the request
boundaries can get out of sync between them, allowing an attacker to tack an
arbitrary method and path onto a request by other clients, including
authentication headers unknown to the attacker.
This was recently presented at multiple security conferences:
https://portswigger.net/blog/http-desync-attacks-request-smuggling-reborn
net/http servers already reject header keys with invalid characters.
Simply stop normalizing extra spaces in net/textproto, let it return them
unchanged like it does for other invalid headers, and let net/http enforce
RFC 7230, which is HTTP specific. This loses us normalization on the client
side, but there's no right answer on the client side anyway, and hiding the
issue sounds worse than letting the application decide.
Fixes CVE-2019-16276
Change-Id: I6d272de827e0870da85d93df770d6a0e161bbcf1
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/549719
Reviewed-by: Brad Fitzpatrick <bradfitz@google.com>
(cherry picked from commit 1280b868e82bf173ea3e988be3092d160ee66082)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/558776
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
Change-Id: I70dc0e2accd83d9c974b95075f9e83a82d89563d
Reviewed-on: https://go-review.googlesource.com/c/go/+/190407
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
|
|
Change-Id: I88b7e085fc70f9c021788d364099f5bc6b705ba8
Reviewed-on: https://go-review.googlesource.com/c/go/+/190438
Reviewed-by: Filippo Valsorda <filippo@golang.org>
(cherry picked from commit 0212f0410f845815f5327a7f2e705891a9598f3d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/190406
Reviewed-by: Alexander Rakoczy <alex@golang.org>
|
|
release-branch.go1.12
Change-Id: I29801b98d975da0bbc092b16dc9771564a39a10a
|
|
Change-Id: I131f93770f9bc5f2d4ee73f158607c1c9e1550bb
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/527000
Reviewed-by: Filippo Valsorda <valsorda@google.com>
|
|
Change-Id: I0daab6cd347e1fc0066e516f02c33f1b63e3f1a3
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526992
Reviewed-by: Filippo Valsorda <valsorda@google.com>
(cherry picked from commit 685bfb1adec3d9fcb589f35eb2bc0b99d2f84bf0)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526993
|
|
for invalid Host values
When Host is not valid per RFC 3986, the behavior of Hostname and Port
was wildly unpredictable, to the point that Host could have a suffix
that didn't appear in neither Hostname nor Port.
This is a security issue when applications are applying checks to Host
and expecting them to be meaningful for the contents of Hostname.
To reduce disruption, this change only aims to guarantee the following
two security-relevant invariants.
* Host is either Hostname or [Hostname] with Port empty, or
Hostname:Port or [Hostname]:Port.
* Port is only decimals.
The second invariant is the one that's most likely to cause disruption,
but I believe it's important, as it's conceivable an application might
do a suffix check on Host and expect it to be meaningful for the
contents of Hostname (if the suffix is not a valid port).
There are three ways to ensure it.
1) Reject invalid ports in Parse. Note that non-numeric ports are
already rejected if and only if the host starts with "[".
2) Consider non-numeric ports as part of Hostname, not Port.
3) Allow non-numeric ports, and hope they only flow down to net/http,
which will reject them (#14353).
This change adopts both 1 and 2. We could do only the latter, but then
these invalid hosts would flow past port checks, like in
http_test.TestTransportRejectsAlphaPort. Non-numeric ports weren't fully
supported anyway, because they were rejected after IPv6 literals, so
this restores consistency. We could do only the former, but at this
point 2) is free and might help with manually constructed Host values
(or if we get something wrong in Parse).
Note that net.SplitHostPort and net.Dial explicitly accept service names
in place of port numbers, but this is an URL package, and RFC 3986,
Section 3.2.3, clearly specifies ports as a number in decimal.
net/http uses a mix of net.SplitHostPort and url.Parse that would
deserve looking into, but in general it seems that it will still accept
service names in Addr fields as they are passed to net.Listen, while
rejecting them in URLs, which feels correct.
This leaves a number of invalid URLs to reject, which however are not
security relevant once the two invariants above hold, so can be done in
Go 1.14: IPv6 literals without brackets (#31024), invalid IPv6 literals,
hostnames with invalid characters, and more.
Tested with 200M executions of go-fuzz and the following Fuzz function.
u, err := url.Parse(string(data))
if err != nil {
return 0
}
h := u.Hostname()
p := u.Port()
switch u.Host {
case h + ":" + p:
return 1
case "[" + h + "]:" + p:
return 1
case h:
fallthrough
case "[" + h + "]":
if p != "" {
panic("unexpected Port()")
}
return 1
}
panic("Host is not a variant of [Hostname]:Port")
Fixes CVE-2019-14809
Updates #29098
Change-Id: I7ef40823dab28f29511329fa2d5a7fb10c3ec895
Reviewed-on: https://go-review.googlesource.com/c/go/+/189258
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 61bb56ad63992a3199acc55b2537c8355ef887b6)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526408
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
security fix
Apply the following unpublished golang.org/x/net commit.
commit cdfb69ac37fc6fa907650654115ebebb3aae2087
Author: Filippo Valsorda <filippo@golang.org>
Date: Sun Aug 11 02:12:18 2019 -0400
[release-branch.go1.12] http2: limit number of control frames in server send queue
An attacker could cause servers to queue an unlimited number of PING
ACKs or RST_STREAM frames by soliciting them and not reading them, until
the program runs out of memory.
Limit control frames in the queue to a few thousands (matching the limit
imposed by other vendors) by counting as they enter and exit the scheduler,
so the protection will work with any WriteScheduler.
Once the limit is exceeded, close the connection, as we have no way to
communicate with the peer.
Change-Id: I842968fc6ed3eac654b497ade8cea86f7267886b
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/525552
Reviewed-by: Brad Fitzpatrick <bradfitz@google.com>
(cherry picked from commit 589ad6cc5321fb68a90370348a241a5da0a2cc80)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526069
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Fixes CVE-2019-9512 and CVE-2019-9514
Updates #33606
Change-Id: I282b3e0fa22422d9ea0d07f4a3935685ce4a7433
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/526071
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
|
|
There is real (albeit generated) code that exceeds the limit.
Updates #33555
Fixes #33557
Change-Id: I668e85825d3d2a471970e869abe63f3492213cc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/189697
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
(cherry picked from commit 951143cf1425189965498cc32fc8dc132bf7c777)
Reviewed-on: https://go-review.googlesource.com/c/go/+/189717
|
|
shlVU on arm64
For the case where the addresses of parameter z and x of the function
shlVU overlap and the address of z is greater than x, x (input value)
can be polluted during the calculation when the high words of x are
overlapped with the low words of z (output value).
Updates #31084
Fixes #32940
Change-Id: I9bb0266a1d7856b8faa9a9b1975d6f57dece0479
Reviewed-on: https://go-review.googlesource.com/c/go/+/169780
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
(cherry picked from commit 503e6ccd740c48f21c1d159d904b51da2d9a8ca9)
Reviewed-on: https://go-review.googlesource.com/c/go/+/185041
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
|
|
There's a race here with fork/exec, enable the close-on-exec flag
for the new file descriptor.
Updates #33405
Fixes #33424
Change-Id: Ib1e405c3b48b11c867f183fd13eff8b73d95e3b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/188537
Run-TryBot: Baokun Lee <nototon@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 2d6ee6e89a4b30c7528d2977df4e1aa86651e4e4)
Reviewed-on: https://go-review.googlesource.com/c/go/+/188538
Run-TryBot: Ian Lance Taylor <iant@golang.org>
|
|
behavior
Fixes #30401
Change-Id: I7b5035ffc7333c746d4e31563df26ff4f934dfc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/188237
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
(cherry picked from commit fe8a86646478b11db5697108a4db0deeaca29595)
Reviewed-on: https://go-review.googlesource.com/c/go/+/188357
|
|
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.
Updates #30768
Fixes #33040
Change-Id: I8aba3934ffa994b1a19fc442cfe3e05642792a25
Reviewed-on: https://go-review.googlesource.com/c/go/+/186278
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@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.
Updates #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>
(cherry-picked from 20e4540e9084528a1b36978882596daa7d8d8800)
Reviewed-on: https://go-review.googlesource.com/c/go/+/186277
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
Change-Id: I9696d71d6087c469911c6bdc494ce01ac4e52a11
Reviewed-on: https://go-review.googlesource.com/c/go/+/185261
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Change-Id: Id5d2f4cc6bc310bed2516ce0f50c395802475f66
Reviewed-on: https://go-review.googlesource.com/c/go/+/185258
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
(cherry picked from commit c893ea8f8b5fc824b1fdd0b2e56d0cda5eacb02b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/185146
|
|
Change-Id: I1b2e369befc58b3f88ac201442a2d9f76d87d54e
Reviewed-on: https://go-review.googlesource.com/c/go/+/185257
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
(cherry picked from commit 0fddd668671c44a622be7d7ea71962be644d8218)
Reviewed-on: https://go-review.googlesource.com/c/go/+/185145
|
|
rewrite rules
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
Updates #32680.
Fixes #32712.
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>
(cherry picked from commit 769fda2d5110eef6146d7df3bf0219872c9b0da6)
Reviewed-on: https://go-review.googlesource.com/c/go/+/183241
|
|
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.
Fixes #32697
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>
Reviewed-on: https://go-review.googlesource.com/c/go/+/183398
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
__DWARF segment
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).
Updates #32697
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>
Reviewed-on: https://go-review.googlesource.com/c/go/+/183397
|
|
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 #32583.
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>
(cherry picked from commit f44404ebbfeff57f3e45ebf4b314a320bb89841f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/181978
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
|
|
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.
This is a backport of CLs 183458 and 183778 to the 1.12 release branch.
It is not a cherry pick because the code in misc/cgo/test has changed.
Updates #32579
Fixes #32756
Change-Id: I0daa75ec62cccbe82ab658cb2947f51423e0c235
Reviewed-on: https://go-review.googlesource.com/c/go/+/183627
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
|
|
Change-Id: If156d9582ad5d76589e83ac00b4fa7f3b61f1502
Reviewed-on: https://go-review.googlesource.com/c/go/+/181658
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
|
|
Change-Id: I8ae00d2392c20c627d58cf7e79015e982b971802
Reviewed-on: https://go-review.googlesource.com/c/go/+/181551
Reviewed-by: Filippo Valsorda <filippo@golang.org>
(cherry picked from commit ef84fa082caec4d1757377c11e98f3b5ebc934d3)
Reviewed-on: https://go-review.googlesource.com/c/go/+/181598
|
|
Change-Id: I1c3e3305dfee4545a6caedd48243770ab3b28277
Reviewed-on: https://go-review.googlesource.com/c/go/+/181550
Reviewed-by: Filippo Valsorda <filippo@golang.org>
(cherry picked from commit 55453016979124e18d3afb53c9df1590877a3b53)
Reviewed-on: https://go-review.googlesource.com/c/go/+/181552
|
|
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 IsDirectJump helper to find calls.
Fixes #32484
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>
(cherry picked from commit 9eb403159da9debbb4881140995e62bec0c943f3)
Reviewed-on: https://go-review.googlesource.com/c/go/+/181262
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
|
|
This is a backport of CL 178397.
Updates #32167
Fixes #32168
Change-Id: Idb16a01d56814ea09ad277798787355dc6a3121f
Reviewed-on: https://go-review.googlesource.com/c/go/+/181437
Reviewed-by: Jason Donenfeld <Jason@zx2c4.com>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
libraries
This fixes TestScript/cover_pkgall_multiple_mains, which started
failing after CL 174657.
When compiling main packages with coverage instrumentation
(e.g., for -coverpkg all), we now pass -p with the full import path
instead of '-p main'. This avoids link errors
'duplicate symbol main.main (types 1 and 1)'.
Fixes #32295
Updates #31946
Updates #32150
Change-Id: Id147527b1dbdc14bb33ac133c30d50c250b4365c
Reviewed-on: https://go-review.googlesource.com/c/go/+/176558
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 3b8c804164e26bdec6ca94a5ab1b5c35fa119e5e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/179677
|
|
server 408 reply
HTTP 408 responses now exist and are seen in the wild (e.g. from
Google's GFE), so make Go's HTTP client not spam about them when seen.
They're normal (now).
Fixes #32367
Updates #32310
Change-Id: I558eb4654960c74cf20db1902ccaae13d03310f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/179457
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
(cherry picked from commit ba66d89d7882892f762e7980562287d2c79ad87e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/181239
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
CFDictionaryGetValueIfPresent does not take ownership of the value, so
releasing the properties dictionary before passing the value to CFEqual
can crash. Not really clear why this works most of the time.
See https://developer.apple.com/library/archive/documentation/CoreFoundation/Conceptual/CFMemoryMgmt/Concepts/Ownership.html
Fixes #32282
Updates #28092
Updates #30763
Change-Id: I5ee7ca276b753a48abc3aedfb78b8af68b448dd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/178537
Reviewed-by: Adam Langley <agl@golang.org>
(cherry picked from commit a3d4655c2435e3777c45f09650539b943bab1c66)
Reviewed-on: https://go-review.googlesource.com/c/go/+/179339
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
processes
This is CVE-2019-11888.
Previously, passing a nil environment but a non-nil token would result
in the new potentially unprivileged process inheriting the parent
potentially privileged environment, or would result in the new
potentially privileged process inheriting the parent potentially
unprivileged environment. Either way, it's bad. In the former case, it's
an infoleak. In the latter case, it's a possible EoP, since things like
PATH could be overwritten.
Not specifying an environment currently means, "use the existing
environment". This commit amends the behavior to be, "use the existing
environment of the token the process is being created for." The behavior
therefore stays the same when creating processes without specifying a
token. And it does the correct thing when creating processes when
specifying a token.
Updates #32000
Fixes #32081
Change-Id: Ib4a90cfffb6ba866c855f66f1313372fdd34ce41
Reviewed-on: https://go-review.googlesource.com/c/go/+/177538
Run-TryBot: Jason Donenfeld <Jason@zx2c4.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
of slices
If a slice's entries are sparse, we decide to initialize it dynamically
instead of statically. That's CL 151319.
But if we do initialize it dynamically, we still need to initialize
the static entries. Typically we do that, but the bug fixed here is
that we don't if the entry's value is itself an array or struct.
To fix, use initKindLocalCode to ensure that both static and
dynamic entries are initialized via code.
Fixes #32013
Change-Id: I1192ffdbfb5cd50445c1206c4a3d8253295201dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/176904
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
(cherry picked from commit a9e107c85cf69d735ac81c29f4a354643e40b2b5)
Reviewed-on: https://go-review.googlesource.com/c/go/+/177040
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
version to 10.9
Satisfies the Apple Notary.
Fixes #30526
Change-Id: I91cf2d706a3ebe79bafdb759a0d32266ed6b9096
Reviewed-on: https://go-review.googlesource.com/c/go/+/175918
Run-TryBot: Elias Naur <mail@eliasnaur.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/175919
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Change-Id: Ib253d4aafab3ad65b4ba666f4eeb8b2f245997a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/175447
Run-TryBot: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
resolve symlinks
info.Name returns a name relative to the directory, so we need to
prefix that directory in the Stat call.
(This was missed in CL 141097 due to the fact that the test only
happened to check symlinks in the current directory.)
This allows the misc/ tests to work in module mode on platforms that
support symlinks.
Updates #30228
Updates #28107
Fixes #31763
Change-Id: Ie31836382df0cbd7d203b7a8b637c4743d68b6f3
Reviewed-on: https://go-review.googlesource.com/c/163517
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/175441
Reviewed-by: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Change-Id: I9986a323db2a8f5fa74b071cfd04e8c786da0cb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/175438
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit 1560264f70a90de8d8b68e246c476d79e4d60574)
Reviewed-on: https://go-review.googlesource.com/c/go/+/175444
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
Change-Id: Icca4495f727e3921b717a4bbb441cd832d321d46
Reviewed-on: https://go-review.googlesource.com/c/go/+/175439
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit e1f9e701be094741b234320cc49b8776cce27c3f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/175443
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
stdout
Fixes #31783
Change-Id: I3cc0ebc4be34d7c2d2d4fd655bfd0c2515ff3021
Reviewed-on: https://go-review.googlesource.com/c/go/+/174739
Reviewed-by: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit fad365ba924291ce9994cb382191fc610984ed79)
Reviewed-on: https://go-review.googlesource.com/c/go/+/175419
Run-TryBot: Andrew Bonventre <andybons@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
object symbol
Stack object generation code was always using the local package name
for its symbol. Normally that doesn't matter, as we usually only
compile functions in the local package. But for wrappers, the compiler
generates functions which live in other packages. When there are two
other packages with identical functions to wrap, the same name appears
twice, and the compiler goes boom.
Fixes #31396
Change-Id: I7026eebabe562cb159b8b6046cf656afd336ba25
Reviewed-on: https://go-review.googlesource.com/c/go/+/171464
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
(cherry picked from commit 43001a0dc96a29f662f2782c5fb3ca998eadd623)
Reviewed-on: https://go-review.googlesource.com/c/go/+/173317
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
Add explicit tests for:
#30465 cmd/vet: Consider reverting tag conflict for embedded fields
#30399 cmd/vet: possible to get a printf false positive with big.Int
because we have managed not to fix them in the last
couple point releases, and it will be too embarrassing
to do that yet again.
Change-Id: Ib1da5df870348b6eb9bfc8a87c507ecc6d44b8dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/174520
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
from release-branch.go1.12
$ ./update-xtools.sh
Copied /Users/rsc/src/golang.org/x/tools@aa829657 to .
$ cd ~/src/golang.org/x/tools
$ git log -n1 aa829657
commit aa82965741a9fecd12b026fbb3d3c6ed3231b8f8 (HEAD -> release-branch.go1.12, origin/release-branch.go1.12)
Author: Daniel Martí <mvdan@mvdan.cc>
AuthorDate: Fri Mar 1 11:00:19 2019 +0000
Commit: Brad Fitzpatrick <bradfitz@golang.org>
CommitDate: Wed Mar 13 21:06:03 2019 +0000
...
$
Picks up cmd/vet fixes that have been inadvertently missed in point releases so far.
Fixes #30399.
Fixes #30465.
Change-Id: Ibcfaac51d134205b986b32f857d54006b19c896a
Reviewed-on: https://go-review.googlesource.com/c/go/+/174519
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
This reverts commit 8e093e7a1cd8a092f23717cb8f34bca489a3eee5
(CL 159500).
Reason for revert: Increases memory allocation latency in certain
situations.
Fixes #31679.
Change-Id: I15e02c53a58009fd907b619b8649de2cdeb29ef0
Reviewed-on: https://go-review.googlesource.com/c/go/+/174102
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
|
|
This change modifies the implementation of mTreap.find to find the
best-fit span with the lowest possible base address.
Fixes #31677.
Change-Id: Ib4bda0f85d7d0590326f939a243a6e4665f37d3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/173479
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
(cherry picked from commit 8c05d67661c966f5130e51ca685b0c70a5a929ff)
Reviewed-on: https://go-review.googlesource.com/c/go/+/173939
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
This change exports the runtime mTreap in export_test.go and then adds a
series of tests which check that the invariants of the treap are
maintained under different operations. These tests also include tests
for the treap iterator type.
Also, we note that the find() operation on the treap never actually was
best-fit, so the tests just ensure that it returns an appropriately
sized span.
For #30333.
Change-Id: If81f7c746dda6677ebca925cb0a940134701b894
Reviewed-on: https://go-review.googlesource.com/c/go/+/164100
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
(cherry picked from commit d13a9312f52a3e861e02aff8ccb3f237b45b0822)
Reviewed-on: https://go-review.googlesource.com/c/go/+/173940
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
The top right menu in Gerrit is now a gear icon, and the link
has a slightly different title.
Change-Id: I3f5d194f31ad09a99416a45db392aa4b5c7d98ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/173400
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit d0fadb93c2cc5d067813a106e6679f8a3ffd9c0f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/173361
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
|
TestSectionsWithSameName
The test doesn't really require cgo, but it does require that we know
the right flags to use to run the C compiler, and that is not
necessarily correct if we don't support cgo.
Fixes #31565
Change-Id: I04dc8db26697caa470e91ad712376aa621cf765d
Reviewed-on: https://go-review.googlesource.com/c/go/+/172981
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 4c236b9b097882f3aef8116e1ac9f65463bf6f01)
Reviewed-on: https://go-review.googlesource.com/c/go/+/173117
|
|
the same name
New versions of clang can generate multiple sections named ".text"
when using vague C++ linkage. This is valid ELF, but would cause the
Go linker to report an error when using internal linking:
symbol PACKAGEPATH(.text) listed multiple times
Avoid the problem by renaming section symbol names if there is a name
collision.
Change-Id: I41127e95003d5b4554aaf849177b3fe000382c02
Reviewed-on: https://go-review.googlesource.com/c/go/+/172697
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
(cherry picked from commit 3235f7c0720338a160debe6e9c632b8af968b4dd)
Reviewed-on: https://go-review.googlesource.com/c/go/+/172701
|
|
Change-Id: I3cb4fb7cacba51bfd611ade918f16c618e2569fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/172159
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
(cherry picked from commit e47090ab40967c2e5e6058838319259b4cc0d508)
Reviewed-on: https://go-review.googlesource.com/c/go/+/172317
Reviewed-by: Andrew Bonventre <andybons@golang.org>
|
