| Age | Commit message (Collapse) | Author |
|---|
|
Most of the time, the pprof tests are passing, except
for the builder. The reason is still unknown but I'd rather release
the builder to avoid missing other more important bugs.
Updates #45170
Change-Id: I667543ee1ae309b7319c5b3676a0901b4d0ecf2e
Reviewed-on: https://go-review.googlesource.com/c/go/+/306489
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
(cherry picked from commit 7bfd681c2f11918c6245ad2906b2efc12eda2914)
Reviewed-on: https://go-review.googlesource.com/c/go/+/317297
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
The runtime support for syscall.AllThreadsSyscall() functions had
some corner case deadlock issues when signal handling was in use.
This was observed in at least 3 build test failures on ppc64 and
amd64 architecture CGO_ENABLED=0 builds over the last few months.
The fixes involve more controlled handling of signals while the
AllThreads mechanism is being executed. Further details are
discussed in bug #44193.
The all-threads syscall support is new in go1.16, so earlier
releases are not affected by this bug.
Fixes #45307
Change-Id: I01ba8508a6e1bb2d872751f50da86dd07911a41d
Reviewed-on: https://go-review.googlesource.com/c/go/+/305149
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Pratt <mpratt@google.com>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
(cherry picked from commit 7e97e4e8ccdba9677f31ab9380802cd7613f62c5)
Reviewed-on: https://go-review.googlesource.com/c/go/+/316869
Run-TryBot: Ian Lance Taylor <iant@golang.org>
|
|
The shift amount should be masked to avoid rotation values
beyond the numer of bits. In this case, if the shift amount
is 0, it should rotate 0, not 32.
Fixes #45636
Change-Id: I1e764497a39d0ec128e29af42352b70c70b2ecc5
Reviewed-on: https://go-review.googlesource.com/c/go/+/310569
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Trust: Carlos Eduardo Seo <carlos.seo@linaro.org>
(cherry picked from commit c8fb0ec5a005289e9dd890b746e543b38bbd9528)
Reviewed-on: https://go-review.googlesource.com/c/go/+/311378
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
|
|
expandFinalInlineFrame
This is a follow-up to golang.org/cl/301369, which made the same change
in Frames.Next. The same logic applies here: a profile stack may have
been truncated at an invalid PC provided by cgoTraceback.
expandFinalInlineFrame will then try to lookup the inline tree and
crash.
The same fix applies as well: upon encountering a bad PC, simply leave
it as-is and move on.
For #44971
For #45480
Fixes #45482
Change-Id: I2823c67a1f3425466b05384cc6d30f5fc8ee6ddc
Reviewed-on: https://go-review.googlesource.com/c/go/+/309109
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Michael Pratt <mpratt@google.com>
(cherry picked from commit aad13cbb749d1e6c085ff0556d306de1a2d5d063)
Reviewed-on: https://go-review.googlesource.com/c/go/+/309551
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
While we're here fix the ModTime value for directories.
For #43872
For #45345
Fixes #45347
Change-Id: I155e6517713ef6a9482b9431f1167a44337c6ad2
Reviewed-on: https://go-review.googlesource.com/c/go/+/311530
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
(cherry picked from commit 87e4dcd446df2ab1985ef61ce15da329493248a1)
Reviewed-on: https://go-review.googlesource.com/c/go/+/315249
Trust: Jeremy Faller <jeremy@golang.org>
|
|
20210428183300-3f4a416c7d3b
Steps:
go get -d golang.org/x/net@internal-branch.go1.16-vendor
go mod tidy
go mod vendor
This http2 bundle does not need to be updated.
Fixes #45712
Change-Id: I7c86c31248e0cd250d17495c3f985671cfcf44a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/314789
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
extend string
If the current time is computed from extend string
and the zone file contains multiple zones with the
same name, the lookup by name might find incorrect
zone.
This happens for example with the slim Europe/Dublin
time zone file in the embedded zip. This zone file
has last transition in 1996 and rest is covered by
extend string.
tzset returns IST as the zone name to use, but there
are two records with IST name. Lookup by name finds
the wrong one. We need to check offset and isDST too.
In case we can't find an existing zone, we allocate
a new zone so that we use correct offset and isDST.
I have renamed zone variable to zones as it shadowed
the zone type that we need to allocate the cached zone.
Backport note: this change also incorporates portions of
CL 264077.
For #45370
Fixes #45385
Change-Id: If7a0cccc1908e27f0509bf422d824133133250fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/307211
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
|
|
Under certain circumstances, the existing rules for bit operations can
produce code that writes beyond its intended bounds. For example,
consider the following code:
func repro(b []byte, addr, bit int32) {
_ = b[3]
v := uint32(b[0]) | uint32(b[1])<<8 | uint32(b[2])<<16 | uint32(b[3])<<24 | 1<<(bit&31)
b[0] = byte(v)
b[1] = byte(v >> 8)
b[2] = byte(v >> 16)
b[3] = byte(v >> 24)
}
Roughly speaking:
1. The expression `1 << (bit & 31)` is rewritten into `(SHLL 1 bit)`
2. The expression `uint32(b[0]) | uint32(b[1])<<8 | uint32(b[2])<<16 |
uint32(b[3])<<24` is rewritten into `(MOVLload &b[0])`
3. The statements `b[0] = byte(v) ... b[3] = byte(v >> 24)` are
rewritten into `(MOVLstore &b[0], v)`
4. `(ORL (SHLL 1, bit) (MOVLload &b[0]))` is rewritten into
`(BTSL (MOVLload &b[0]) bit)`. This is a valid transformation because
the destination is a register: in this case, the bit offset is masked
by the number of bits in the destination register. This is identical
to the masking performed by `SHL`.
5. `(MOVLstore &b[0] (BTSL (MOVLload &b[0]) bit))` is rewritten into
`(BTSLmodify &b[0] bit)`. This is an invalid transformation because
the destination is memory: in this case, the bit offset is not
masked, and the chosen instruction may write outside its intended
32-bit location.
These changes fix the invalid rewrite performed in step (5) by
explicitly maksing the bit offset operand to `BT(S|R|C)(L|Q)modify`. In
the example above, the adjusted rules produce
`(BTSLmodify &b[0] (ANDLconst [31] bit))` in step (5).
These changes also add several new rules to rewrite bit sets, toggles,
and clears that are rooted at `(OR|XOR|AND)(L|Q)modify` operators into
appropriate `BT(S|R|C)(L|Q)modify` operators. These rules catch cases
where `MOV(L|Q)store ((OR|XOR|AND)(L|Q) ...)` is rewritten to
`(OR|XOR|AND)(L|Q)modify` before the `(OR|XOR|AND)(L|Q) ...` can be
rewritten to `BT(S|R|C)(L|Q) ...`.
Overall, compilecmp reports small improvements in code size on
darwin/amd64 when the changes to the compiler itself are exlcuded:
file before after Δ %
runtime.s 536464 536412 -52 -0.010%
bytes.s 32629 32593 -36 -0.110%
strings.s 44565 44529 -36 -0.081%
os/signal.s 7967 7959 -8 -0.100%
cmd/vendor/golang.org/x/sys/unix.s 81686 81678 -8 -0.010%
math/big.s 188235 188253 +18 +0.010%
cmd/link/internal/loader.s 89295 89056 -239 -0.268%
cmd/link/internal/ld.s 633551 633232 -319 -0.050%
cmd/link/internal/arm.s 18934 18928 -6 -0.032%
cmd/link/internal/arm64.s 31814 31801 -13 -0.041%
cmd/link/internal/riscv64.s 7347 7345 -2 -0.027%
cmd/compile/internal/ssa.s 4029173 4033066 +3893 +0.097%
total 21298280 21301472 +3192 +0.015%
Fixes #45253
Change-Id: I2e560548b515865129e1724e150e30540e9d29ce
GitHub-Last-Rev: ab94ede1d097f920a9d1d3da403c8e4a3d8f6d44
GitHub-Pull-Request: golang/go#45242
Reviewed-on: https://go-review.googlesource.com/c/go/+/305069
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
When using cgo, some of the frames can be provided by cgoTraceback, a
cgo-provided function to generate C tracebacks. Unlike Go tracebacks,
cgoTraceback has no particular guarantees that it produces valid
tracebacks.
If one of the (invalid) frames happens to put the PC in the alignment
region at the end of a function (filled with int 3's on amd64), then
Frames.Next will find a valid funcInfo for the PC, but pcdatavalue will
panic because PCDATA doesn't cover this PC.
Tolerate this case by doing a non-strict PCDATA lookup. We'll still show
a bogus frame, but at least avoid throwing.
For #44971
Fixes #45303
Change-Id: I9eed728470d6f264179a7615bd19845c941db78c
Reviewed-on: https://go-review.googlesource.com/c/go/+/301369
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
(cherry picked from commit e4a4161f1f3157550846e1b6bd4fe83aae15778e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/305889
|
|
intertwined phi values
We need to be careful that when doing value graph surgery, we not
re-substitute a value that has already been substituted. That can lead
to confusing a previous iteration's value with the current iteration's
value.
The simple fix in this CL just aborts the optimization if it detects
intertwined phis (a phi which is the argument to another phi). It
might be possible to keep the optimization with a more complicated
CL, but:
1) This CL is clearly safe to backport.
2) There were no instances of this abort triggering in
all.bash, prior to the test introduced in this CL.
Fixes #45192
Change-Id: I2411dca03948653c053291f6829a76bec0c32330
Reviewed-on: https://go-review.googlesource.com/c/go/+/304251
Trust: Keith Randall <khr@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
(cherry picked from commit 771c57e68ed5ef2bbb0eafc0d48419f59d143932)
Reviewed-on: https://go-review.googlesource.com/c/go/+/304530
|
|
This change upgrades x/mod to pull in the fix from CL 300152.
Updates #44776.
Fixes #44885.
Change-Id: I273f41df2abfff76d91315b7f19fce851c8770d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/300176
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
(cherry picked from commit d33e2192a71c33a604af247161ba1d2c1969e4c7)
Reviewed-on: https://go-review.googlesource.com/c/go/+/300153
|
|
run.rc
We used to clear GOPATH in all the build scripts.
Clearing GOPATH is misleading at best, since you just end up
with the default GOPATH (%USERPROFILE%\go on Windows).
Unless that's your GOROOT, in which case you end up with a
fatal error from the go command (#43938).
run.bash changed to setting GOPATH=/dev/null, which has no
clear analogue on Windows.
run.rc still clears GOPATH.
Change them all to set GOPATH to a non-existent directory
/nonexist-gopath or c:\nonexist-gopath.
For #45238.
Fixes #45240.
Change-Id: I51edd66d37ff6a891b0d0541d91ecba97fbbb03d
Reviewed-on: https://go-review.googlesource.com/c/go/+/288818
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
(cherry picked from commit bb6efb96092cc8ae398c29e3b052a0051c746f88)
Reviewed-on: https://go-review.googlesource.com/c/go/+/304772
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Trust: Carlos Amedee <carlos@golang.org>
|
|
packages
Currently, in the trampoline generation pass we expect packages
are laid out in dependency order, so a cross-package jump always
has a known target address so we can check if a trampoline is
needed. With linknames, there can be cycles in the package
dependency graph, making this algorithm no longer work. For them,
as the target address is unkown we conservatively generate a
trampoline. This may generate unnecessary trampolines (if the
packages turn out laid together), but package cycles are extremely
rare so this is fine.
Updates #44639.
Fixes #44640.
Change-Id: I2dc2998edacbda27d726fc79452313a21d07787a
Reviewed-on: https://go-review.googlesource.com/c/go/+/292490
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
(cherry picked from commit 098504c73ff6ece19566a1ac811ceed73be7c81d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/296909
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
static tmps
Static tmps are private to a package, but with plugins a package
can be shared among multiple DSOs. They need to have a consistent
view of the static tmps, especially for writable ones. So export
them. (Read-only static tmps have the same values anyway, so it
doesn't matter. Also Mach-O doesn't support dynamically exporting
read-only symbols anyway.)
Updates #44956.
Fixes #45030.
Change-Id: I921e25b7ab73cd5d5347800eccdb7931e3448779
Reviewed-on: https://go-review.googlesource.com/c/go/+/301793
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
(cherry picked from commit de012bc095359e1b552d4ea6fb6b2995f3ab04f5)
Reviewed-on: https://go-review.googlesource.com/c/go/+/302449
|
|
missing ziphash file
Previously, if an extracted module directory existed in the module
cache, but the corresponding ziphash file did not, if the sum was
missing from go.sum, we would not verify the sum. This caused 'go get'
not to write missing sums. 'go build' in readonly mode (now the
default) checks for missing sums and doesn't attempt to fetch modules
that can't be verified against go.sum.
With this change, when requesting the module directory with
modfetch.DownloadDir, if the ziphash file is missing, the go command
will re-hash the zip without downloading or re-extracting it again.
Note that the go command creates the ziphash file before the module
directory, but another program could remove it separately, and it
might not be present after a crash.
Fixes #44812
Change-Id: I64551e048a3ba17d069de1ec123d5b8b2757543c
Reviewed-on: https://go-review.googlesource.com/c/go/+/298352
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit 302a400316319501748c0f034464fa70e7815272)
Reviewed-on: https://go-review.googlesource.com/c/go/+/298851
|
|
parent's helperNames has not been set when frameSkip called, moving
helperNames initilazing to frameSkip.
For #44887
Fixes #44888
Change-Id: I5107c5951033e5e47d1ac441eac3ba5344a7bdc0
GitHub-Last-Rev: 44b90b2e2eeca8e2bb4a2084ec6fdd279c88f76d
GitHub-Pull-Request: golang/go#45071
Reviewed-on: https://go-review.googlesource.com/c/go/+/302469
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
(cherry picked from commit 67048432026062a98a3937a865aeb05a398148c5)
Reviewed-on: https://go-review.googlesource.com/c/go/+/303189
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
|
|
install'
Fixes #44860
Change-Id: I5a12c6437a91ce59307483ffcc70e084edc32197
Reviewed-on: https://go-review.googlesource.com/c/go/+/301329
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
(cherry picked from commit 86bbf4beee276b9a7f9a427a9d1a9277bd904709)
Reviewed-on: https://go-review.googlesource.com/c/go/+/301429
|
|
The timerpMask optimization updates a mask of Ps (potentially)
containing timers in pidleget / pidleput. For correctness, it depends on
the assumption that new timers can only be added to a P's own heap.
addtimer violates this assumption if it is preempted after computing pp.
That G may then run on a different P, but adding a timer to the original
P's heap.
Avoid this by disabling preemption while pp is in use.
Other uses of doaddtimer should be OK:
* moveTimers: always moves to the current P's heap
* modtimer, cleantimers, addAdjustedTimers, runtimer: does not add net
new timers to the heap while locked
For #44868
Fixes #44869
Change-Id: I4a5d080865e854931d0a3a09a51ca36879101d72
Reviewed-on: https://go-review.googlesource.com/c/go/+/300610
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
(cherry picked from commit aa26687e457d825fc9c580e8c029b768e0e70d38)
Reviewed-on: https://go-review.googlesource.com/c/go/+/300611
|
|
The new error message tells the user what was wrong (no go.mod found)
and directs them to 'go help modules', which links to tutorials.
Includes test fix from CL 298794
Fixes #44746
Change-Id: I98f31fec4a8757eb1792b45491519da4c552cb0f
Reviewed-on: https://go-review.googlesource.com/c/go/+/298650
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit b87e9b9f68f1eb0d685fd250b3b47495710e0059)
Reviewed-on: https://go-review.googlesource.com/c/go/+/298929
|
|
tidy and vendor
'go mod tidy' and 'go mod vendor' normally report errors when a
package can't be imported, even if the import appears in a file that
wouldn't be compiled by the current version of Go. These errors are
common for packages introduced in higher versions of Go, like "embed"
in 1.16.
This change causes 'go mod tidy' and 'go mod vendor' to ignore
missing package errors if the import path appears to come from the
standard library because it lacks a dot in the first path element.
Fixes #44793
Updates #27063
Change-Id: I61d6443e77ab95fd8c0d1514f57ef4c8885a77cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/298749
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
(cherry picked from commit 56d52e661114be60fb1893b034ac0c5976b622af)
Reviewed-on: https://go-review.googlesource.com/c/go/+/298949
|
|
release-branch.go1.16
Change-Id: Icc8775f559b0125eae94ce4ffd4dcb4e7146a500
|
|
When operating on a Zip file that contains a file prefixed with "../",
Open(...) would cause a panic in toValidName when attempting to strip
the prefixed path components.
Fixes CVE-2021-27919
Change-Id: Ic755d8126cb0897e2cbbdacf572439c38dde7b35
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1004761
Reviewed-by: Filippo Valsorda <valsorda@google.com>
Reviewed-by: Russ Cox <rsc@google.com>
Reviewed-by: Katie Hockman <katiehockman@google.com>
(cherry picked from commit ce22003b26eaf8e4a690757f699aae7062d41472)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1013753
Reviewed-by: Roland Shoemaker <bracewell@google.com>
|
|
decoding
This change properly handles a TokenReader which
returns an EOF in the middle of an open XML
element.
Thanks to Sam Whited for reporting this.
Fixes CVE-2021-27918
Change-Id: Id02a3f3def4a1b415fa2d9a8e3b373eb6cb0f433
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1004594
Reviewed-by: Russ Cox <rsc@google.com>
Reviewed-by: Roland Shoemaker <bracewell@google.com>
Reviewed-by: Filippo Valsorda <valsorda@google.com>
(cherry picked from commit e7ce1f6746223ec7b4caa3b1ece25d9be3864710)
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1014235
|
|
This incorporates CL 298009, which allows leading dots in import path
elements but not module path elements. Also added a test.
Fixes #44647
Updates #34992
Change-Id: I2d5faabd8f7b23a7943d3f3ccb6707ab5dc2ce3c
Reviewed-on: https://go-review.googlesource.com/c/go/+/297530
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit 97bdac03aee805cfa54e7762037a568d85339970)
Reviewed-on: https://go-review.googlesource.com/c/go/+/297912
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
canonical versions
If a canonical version is passed to fixVersion when loading the main
go.mod and that version don't match the module path's major version
suffix, don't call Query.
Query doesn't return a useful error in this case when the path is
malformed, for example, when it doens't have a dot in the first path
element. It's better to report the major version mismatch error.
Fixes #44496
Change-Id: I97b1f64aee894fa0db6fb637aa03a51357ee782c
Reviewed-on: https://go-review.googlesource.com/c/go/+/296590
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit 5fafc0bbd4819578e58e5b9163981b0074ab0b01)
Reviewed-on: https://go-review.googlesource.com/c/go/+/297989
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
modfile.Parse passed an empty string to the VersionFixer for the
module path. This caused errors for v2+ versions.
For #44496
Change-Id: I13b86b6ecf6815c4bc9a96ec0668284c9228c205
Reviewed-on: https://go-review.googlesource.com/c/go/+/296131
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit bcac57f89c0ec609e6fbebcbcd42bb73fdaef2f0)
Reviewed-on: https://go-review.googlesource.com/c/go/+/297990
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
message
Updates #44674
Fixes #44676
Change-Id: Icbdb79084bf7bd2f52cc0a53abcc1ec6f0c4a1bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/297350
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
(cherry picked from commit 87beecd6dfd3b12ed30785ec502f7380dc79ec29)
Reviewed-on: https://go-review.googlesource.com/c/go/+/297633
Trust: Bryan C. Mills <bcmills@google.com>
|
|
when dynlink
When using plugins, a type (whose value) may be pass to a plugin
and get converted to interface there, or vice versa. We need to
treat the type as potentially converted to interface, and retain
its methods.
Updates #44586.
Fixes #44638.
Change-Id: I80dd35e68baedaa852a317543ccd78d94628d13b
Reviewed-on: https://go-review.googlesource.com/c/go/+/296709
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
(cherry picked from commit a655208c9ecd2fee4de6deff35a863b1c28a091c)
Reviewed-on: https://go-review.googlesource.com/c/go/+/296910
|
|
results
One of escape analysis's responsibilities is to summarize whether/how
each function parameter flows to the heap so we can correctly
incorporate those flows into callers' escape analysis data flow
graphs.
As an optimization, we separately record when parameters flow to
result parameters, so that we can more precisely analyze parameter
flows based on how the results are used at the call site. However, if
a named result parameter itself needs to be heap allocated, this
optimization isn't safe and the parameter needs to be recorded as
flowing to heap rather than flowing to result.
Escape analysis used to get this correct because it conservatively
rewalked the data-flow graph multiple times. So even though it would
incorrectly record the result parameter flow, it would separately find
a flow to the heap. However, CL 196811 (specifically, case 3)
optimized the walking logic to reduce unnecessary rewalks causing us
to stop finding the extra heap flow.
This CL fixes the issue by correcting location.leakTo to be sensitive
to sink.escapes and not record result-flows when the result parameter
escapes to the heap.
Fixes #44659.
Change-Id: I48742ed35a6cab591094e2d23a439e205bd65c50
Reviewed-on: https://go-review.googlesource.com/c/go/+/297289
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/297290
|
|
This fixes two uncommon cases.
First, the tzdata code permits timezone offsets up to 24 * 7, although
the POSIX TZ parsing does not. The tzdata code uses this to specify a
day of week in some cases.
Second, we incorrectly rejected a negative time offset for when a time
zone change comes into effect.
For #44385
Fixes #44618
Change-Id: I5f2efc1d385e9bfa974a0de3fa81e7a94b827602
Reviewed-on: https://go-review.googlesource.com/c/go/+/296392
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
(cherry picked from commit d9fd38e68ba00a51c2c7363150688d0e7687ef84)
Reviewed-on: https://go-review.googlesource.com/c/go/+/297230
|
|
GetQueuedCompletionStatus
The third argument to GetQueuedCompletionStatus is a pointer to a
uintptr, not a uint32. Users of this functions have therefore been
corrupting their memory every time they used it. Either that memory
corruption was silent (dangerous), or their programs didn't work so they
chose a different API to use.
This fixes the problem by passing through an intermediate buffer.
Updates #44538.
Fixes #44593.
Change-Id: Icacd71f705b36e41e52bd8c4d74898559a27522f
Reviewed-on: https://go-review.googlesource.com/c/go/+/296150
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
The fix is to pull in CL 295931 from the x/mod repo.
Updates #44497
Fixes #44498
Change-Id: I008b58d0f4bb48c09d4f1e6ed31d11a714f87dc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/295150
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
(cherry picked from commit 691ac806d20616fab66bb50752edfa9e4e9f8151)
Reviewed-on: https://go-review.googlesource.com/c/go/+/295930
|
|
arguments with call method in go/defer
In CL 253457, we did the same fix for direct function calls. But for
method calls, the receiver argument also need to be passed through the
wrapper function, which we are not doing so the compiler crashes with
the code in #44415.
It will be nicer if we can rewrite OCALLMETHOD to normal OCALLFUNC, but
that will be for future CL. The passing receiver argument to wrapper
function is easier for backporting to go1.16 branch.
Fixes #44464
Change-Id: I03607a64429042c6066ce673931db9769deb3124
Reviewed-on: https://go-review.googlesource.com/c/go/+/296490
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/296769
Trust: Bryan C. Mills <bcmills@google.com>
|
|
obfuscated code
DWARF generation uses variable source positions (file/line/col) as a
way to uniquely identify locals and parameters, as part of the process
of matching up post-optimization variables with the corresponding
pre-optimization versions (since the DWARF needs to be in terms of the
original source constructs).
This strategy can run into problems when compiling obfuscated or
machine-generated code, where you can in some circumstances wind up
with two local variables that appear to have the same name, file,
line, and column. This patch changes DWARF generation to skip over
such duplicates as opposed to issuing a fatal error (if an
obfuscation tool is in use, it is unlikely that a human being will be
able to make much sense of DWARF info in any case).
Fixes #44433.
Change-Id: I198022d184701aa9ec3dce42c005d29b72d2e321
Reviewed-on: https://go-review.googlesource.com/c/go/+/294289
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
(cherry picked from commit e78e04ce39b9df316edda08f43f253f5e9ac509e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/294789
|
|
empty returns
The code for delayed declaration of inlined result parameters only
handles non-empty return statements. This is generally okay, because
we already early declare if there are any (non-blank) named result
parameters.
But if a user writes a function with only blank result parameters and
with exactly one return statement, which is empty, then they could end
up hitting the dreaded "Value live at entry" ICE.
This CL fixes the issue by ensuring we always early declare inlined
result parameters if there are any empty return statements.
Fixes #44358.
Change-Id: I315f3853be436452883b1ce31da1bdffdf24d506
Reviewed-on: https://go-review.googlesource.com/c/go/+/293293
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/296569
|
|
This permits analysis of the syscall package by tools built with
older versions of Go that do not recognize ios as a GOOS.
For #44459
Fixes #44462
Change-Id: I79cec2ffe0dbcbc2dc45a385e556dc9e62033125
Reviewed-on: https://go-review.googlesource.com/c/go/+/294634
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
(cherry picked from commit 03d36d8198428a6970ba01f5de41c264acbff8fc)
Reviewed-on: https://go-review.googlesource.com/c/go/+/294635
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
warning
For #44340
Fixes #44346
Change-Id: Id80dd1f44a988b653933732afcc8e49a826affc4
Reviewed-on: https://go-review.googlesource.com/c/go/+/293209
Reviewed-by: Andrew G. Morgan <agm@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 07ef3135253321176704bce6e629a07ac02bf1c6)
Reviewed-on: https://go-review.googlesource.com/c/go/+/293411
TryBot-Result: Go Bot <gobot@golang.org>
|
|
The package documentation referenced sample metadata that was removed in CL 282632. Update this documentation to be less specific
about what metadata is available.
Additionally, the documentation on the Sample type referred to Descriptions instead of All as the source of metrics names.
Fixes #44280.
Change-Id: I24fc63a744bf498cb4cd5bda56c1599f6dd75929
Reviewed-on: https://go-review.googlesource.com/c/go/+/292309
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
In net/http package, the ServeContent/ServeFile doesn't check the I/O
timeout error from chunkWriter or *net.TCPConn, which means that both
HTTP status and headers might be missing when WriteTimeout happens. If
the poll.SendFile() doesn't check the *poll.FD state before sending
data, the client will only receive the response body with status and
report "malformed http response/status code".
This patch is to enable netpollcheckerr before sendfile, which should
align with normal *poll.FD.Write() and Splice().
Fixes #43822
Change-Id: I32517e3f261bab883a58b577b813ef189214b954
Reviewed-on: https://go-review.googlesource.com/c/go/+/285914
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
|
|
They have moved to x/website in CL 291693.
The docs that are left are the ones that are edited at the same time
as development in this repository and are tied to the specific version
of Go being developed. Those are:
- the language spec
- the memory model
- the assembler manual
- the current release's release notes
Change-Id: I437c4d33ada1b1716b1919c3c939c2cacf407e83
Reviewed-on: https://go-review.googlesource.com/c/go/+/291711
Trust: Russ Cox <rsc@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
On current Linux kernels copy_file_range does not correctly handle
files in certain special file systems, such as /proc. For those file
systems it fails to copy any data and returns zero. This breaks Go's
io.Copy for those files.
Fix the problem by assuming that if copy_file_range returns 0 the
first time it is called on a file, that that file is not supported.
In that case fall back to just using read. This will force an extra
system call when using io.Copy to copy a zero-sized normal file,
but at least it will work correctly.
For #36817
Fixes #44272
Change-Id: I02e81872cb70fda0ce5485e2ea712f219132e614
Reviewed-on: https://go-review.googlesource.com/c/go/+/291989
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
|
|
For the command
go vet -?
the output was,
usage: go vet [-n] [-x] [-vettool prog] [build flags] [vet flags] [packages]
Run 'go help vet' for details.
Run 'go tool vet -help' for the vet tool's flags.
but "go help vet" is perfunctory at best. (That's another issue I'm
working on—see https://go-review.googlesource.com/c/tools/+/291909—
but vendoring is required to sort that out.) Add another line and rewrite
a bit to make it actually helpful:
usage: go vet [-n] [-x] [-vettool prog] [build flags] [vet flags] [packages]
Run 'go help vet' for details.
Run 'go tool vet help' for a full list of flags and analyzers.
Run 'go tool vet -help' for an overview.
Change-Id: I9d8580f0573321a57d55875ac3185988ce3eaf64
Reviewed-on: https://go-review.googlesource.com/c/go/+/291929
Trust: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
specfic -> specific
Change-Id: Icad0f70c77c866a1031a2929b90fef61fe92aaee
GitHub-Last-Rev: f66b56491c0125f58c47f7f39410e0aeef2539be
GitHub-Pull-Request: golang/go#44246
Reviewed-on: https://go-review.googlesource.com/c/go/+/291829
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
|
|
* Link to privacy policies for proxy.golang.org and sum.golang.org in
'go help modules'. It's important that both policies are linked from
the go command's documentation.
* Fix wording and typo in 'go help vcs' following comments in CL 290992,
which adds reference documentation for GOVCS.
* Fix whitespace on GOVCS in 'go help environment'.
For #41730
Change-Id: I86abceacd4962b748361244026f219157c9285e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/291230
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
|
|
If the file won't be packed into a module,
don't put those files into embeds.
Otherwise people will be surprised when things work
locally but not when imported by another module.
Observed on CL 290709
Change-Id: Ia0ef7d0e0f5e42473c2b774e57c843e68a365bc7
Reviewed-on: https://go-review.googlesource.com/c/go/+/290809
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
|
|
Rejecting backslash introduces problems with presenting
underlying OS file systems that contain names with backslash.
Rejecting backslash also does not Windows-proof the syntax,
because colon can also be a path separator. And we are not
going to reject colon from all names. So don't reject backslash
either.
There is a similar problem on Windows with names containing
slashes, but those are more difficult (though not impossible)
to create.
Also document and enforce that paths must be UTF-8.
Fixes #44166.
Change-Id: Iac7a9a268025c1fd31010dbaf3f51e1660c7ae2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/290709
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
|
|
For functions that call reflect.Type.Method (or MethodByName), we
mark it as REFLECTMETHOD, which tells the linker that methods
can be retrieved via reflection and the linker keeps all exported
methods live. Currently, this marking expects exactly the
interface call reflect.Type.Method (or MethodByName). But now the
compiler can devirtualize that call to a concrete call
reflect.(*rtype).Method (or MethodByName), which is not handled
and causing the linker to discard methods too aggressively.
Handle the latter in this CL.
Fixes #44207.
Change-Id: Ia4060472dbff6ab6a83d2ca8e60a3e3f180ee832
Reviewed-on: https://go-review.googlesource.com/c/go/+/290950
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
|
|
conditionally exist
Fixes #44106
Fixes #29268
Change-Id: Id113f2ced274d43fbf66cb804581448218996f81
Reviewed-on: https://go-review.googlesource.com/c/go/+/289769
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
|
|
padded lengths
Handles the case in which padding of a PAX record's length field
violates invariants about the formatting of record, whereby it no
longer matches the prescribed format:
"%d %s=%s\n", <length>, <keyword>, <value>
as per:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_03
0-padding, and paddings of other sorts weren't handled and we assumed
that only non-padded decimal lengths would be passed in.
Added test cases to ensure that the parsing still proceeds as expected.
The prior crashing repro:
0000000000000000000000000000000030 mtime=1432668921.098285006\n30 ctime=2147483649.15163319
exposed the fallacy in the code, that assumed that the length would ALWAYS be a
non-padded decimal length string.
This bug has existed since Go1.1 as per CL 6700047.
Thanks to Josh Bleecher Snyder for fuzzing this package, and thanks to Tom
Thorogood for advocacy, raising parity with GNU Tar, but for providing more test cases.
Fixes #40196
Change-Id: I32e0af4887bc9221481bd9e8a5120a79f177f08c
Reviewed-on: https://go-review.googlesource.com/c/go/+/289629
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
|
|
Fixes #44150
Change-Id: Ibe5bfba01491dd8c2f0696fab40a1673230d76e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/290349
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
|
