| Age | Commit message (Collapse) | Author |
|---|
|
Change-Id: I3399052efb62529d32bb0866fd324d802beb6e4c
Reviewed-on: https://go-review.googlesource.com/c/go/+/223923
Run-TryBot: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
|
|
For #35033
For #36878
Change-Id: Ie15353322d5cfe7320199103ad9543fb89a842ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/223957
Reviewed-by: Brendan Jackman <jackmanb@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit e39de05186af24cec8a5f98258086e9899153e29)
Reviewed-on: https://go-review.googlesource.com/c/go/+/223962
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
signal pending
If multiple threads call preemptone to preempt the same M, it may
send many signals to the same M such that it hardly make
progress, causing live-lock problem. Only send a signal if there
isn't already one pending.
Updates #37741.
Fixes #37833.
Change-Id: Id94adb0b95acbd18b23abe637a8dcd81ab41b452
Reviewed-on: https://go-review.googlesource.com/c/go/+/223737
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
(cherry picked from commit 0c0e8f224d5724e317952f77d215a752a3a7b7d9)
Reviewed-on: https://go-review.googlesource.com/c/go/+/223939
Reviewed-by: Austin Clements <austin@google.com>
|
|
pointer-free base type
Fixes #37905
Change-Id: I8ba9c8b106e16cea7dd25473c7390b0f2ba9a1a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/223781
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/223749
|
|
Instead, note that mlock has failed, start trying the mitigation of
touching the signal stack before sending a preemption signal, and,
if the program crashes, mention the possible problem and a wiki page
describing the issue (https://golang.org/wiki/LinuxKernelSignalVectorBug).
Tested on a kernel in the buggy version range, but with the patch,
by using `ulimit -l 0`.
For #37436
Fixes #37807
Change-Id: I072aadb2101496dffd655e442fa5c367dad46ce8
Reviewed-on: https://go-review.googlesource.com/c/go/+/223121
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
(cherry picked from commit b851e51160bc8ed412e229152b430b75e7ce56f9)
Reviewed-on: https://go-review.googlesource.com/c/go/+/223417
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Fixes #37822
Updates #37804
Change-Id: I4381dc5c58cfd467506d3d73fbd19c2c7257338e
Reviewed-on: https://go-review.googlesource.com/c/go/+/223139
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
(cherry picked from commit feea3f165770025b045c6dd46747b1debdaf348e)
Reviewed-on: https://go-review.googlesource.com/c/go/+/223141
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
panic/recover/re-panics and open-coded defers
In the open-code defer implementation, we add defer struct entries to the defer
chain on-the-fly at panic time to represent stack frames that contain open-coded
defers. This allows us to process non-open-coded and open-coded defers in the
correct order. Also, we need somewhere to be able to store the 'started' state of
open-coded defers. However, if a recover succeeds, defers will now be processed
inline again (unless another panic happens). Any defer entry representing a frame
with open-coded defers will become stale once we run the corresponding defers
inline and exit the associated stack frame. So, we need to remove all entries for
open-coded defers at recover time.
The current code was only removing the top-most open-coded defer from the defer
chain during recovery. However, with recursive functions that do repeated
panic-recover-repanic, multiple stale entries can accumulate on the chain. So, we
just adjust the loop to process the entire chain. Since this is at panic/recover
case, it is fine to scan through the entire chain (which should usually have few
elements in it, since most defers are open-coded).
The added test fails with a SEGV without the fix, because it tries to run a stale
open-code defer entry (and the stack has changed).
Updates #37664.
Fixes #37782.
Change-Id: I8e3da5d610b5e607411451b66881dea887f7484d
Reviewed-on: https://go-review.googlesource.com/c/go/+/222420
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
(cherry picked from commit fae87a2223e1fa959a20017742455200fe3c35f1)
Reviewed-on: https://go-review.googlesource.com/c/go/+/222818
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
|
|
hashes exactly
If typehash (used by reflect) does not match the built-in map's hash,
then problems occur. If a map is built using reflect, and then
assigned to a variable of map type, the hash function can change. That
causes very bad things.
This issue is rare. MapOf consults a cache of all types that occur in
the binary before making a new one. To make a true new map type (with
a hash function derived from typehash) that map type must not occur in
the binary anywhere. But to cause the bug, we need a variable of that
type in order to assign to it. The only way to make that work is to
use a named map type for the variable, so it is distinct from the
unnamed version that MapOf looks for.
Fixes #37721
Change-Id: I3537bfceca8cbfa1af84202f432f3c06953fe0ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/222357
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 2b8e60d464515634462ca472ca09c791e2cbf6ae)
Reviewed-on: https://go-review.googlesource.com/c/go/+/222778
|
|
Interfaces often contain pointers. Implement a fast path for this case.
name old time/op new time/op delta
MapInterfaceString-16 21.4ns ±19% 20.5ns ±10% ~ (p=0.361 n=10+10)
MapInterfacePtr-16 25.8ns ± 8% 17.3ns ± 7% -33.11% (p=0.000 n=10+9)
We need this CL as well to fix 37721.
Update #37721
Fixes #37613
Change-Id: Ice52820e6259a3edeafcbbbeb25b1e363bef00d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/219338
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 afd691c579198387c874512ef1c75db651dba9bd)
Reviewed-on: https://go-review.googlesource.com/c/go/+/222779
Run-TryBot: Alexander Rakoczy <alex@golang.org>
|
|
truncation
When generating stacks, the runtime automatically expands inline
functions to inline all inline frames in the stack. However, due to the
stack size limit, the final frame may be truncated in the middle of
several inline frames at the same location.
As-is, we assume that the final frame is a normal function, and emit and
cache a Location for it. If we later receive a complete stack frame, we
will first use the cached Location for the inlined function and then
generate a new Location for the "caller" frame, in violation of the
pprof requirement to merge inlined functions into the same Location.
As a result, we:
1. Nondeterministically may generate a profile with the different stacks
combined or split, depending on which is encountered first. This is
particularly problematic when performing a diff of profiles.
2. When split stacks are generated, we lose the inlining information.
We avoid both of these problems by performing a second expansion of the
last stack frame to recover additional inline frames that may have been
lost. This expansion is a bit simpler than the one done by the runtime
because we don't have to handle skipping, and we know that the last
emitted frame is not an elided wrapper, since it by definition is
already included in the stack.
Fixes #37447
Change-Id: If3ca2af25b21d252cf457cc867dd932f107d4c61
Reviewed-on: https://go-review.googlesource.com/c/go/+/221577
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
(cherry picked from commit fadbf7404d2b1aca63993e289448fcc3b6a23107)
Reviewed-on: https://go-review.googlesource.com/c/go/+/222762
|
|
softfloat mode on MIPS(64)
Fixes #37667.
Updates #37653.
Change-Id: I6188e44b4bc4aba7b56f29d9ce9de4618c70fd7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/222057
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 588ee7987d7f6be605166872ff8c478aa125bc58)
Reviewed-on: https://go-review.googlesource.com/c/go/+/222062
|
|
panicking/exiting tests
'go test -json' should report that a test failed if the test binary
did not exit normally with status 0. This covers panics, non-zero
exits, and abnormal terminations.
These tests don't print a final result when run with -test.v (which is
used by 'go test -json'). The final result should be "PASS" or "FAIL"
on a line by itself. 'go test' prints "FAIL" in this case, but
includes error information.
test2json was changed in CL 192104 to report that a test passed if it
does not report a final status. This caused 'go test -json' to report
that a test passed after a panic or non-zero exit.
With this change, test2json treats "FAIL" with error information the
same as "FAIL" on a line by itself. This is intended to be a minimal
fix for backporting, but it will likely be replaced by a complete
solution for #29062.
Fixes #37671
Updates #37555
Updates #29062
Updates #31969
Change-Id: Icb67bcd36bed97e6a8d51f4d14bf71f73c83ac3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/222243
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
(cherry picked from commit 5ea58c63468bbc7e8705ee13d0bddbf3693785fe)
Reviewed-on: https://go-review.googlesource.com/c/go/+/222658
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
|
|
net/url.Error is now quoted
Updates #37614
Updates #36878
Updates #29384
Fixes #37630
Change-Id: I63dad8b554353197ae0f29fa2a84f17bffa58557
GitHub-Last-Rev: 5297df32200ea5b52b2e7b52c8ee022d37e44111
GitHub-Pull-Request: golang/go#37661
Reviewed-on: https://go-review.googlesource.com/c/go/+/222037
Reviewed-by: Ian Lance Taylor <iant@golang.org>
(cherry picked from commit 2b0f481278cc093e9f61945592257e6d651a169c)
Reviewed-on: https://go-review.googlesource.com/c/go/+/222317
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
Old trace viewer stopped working with Chrome M80+ because the
old trace viewer heavily depended on WebComponents V0 which are deprecated.
Trace viewer recently migrated to use WebComponents V0 polyfill
(crbug.com/1036492). This CL brings in the newly updated trace_viewer_full.html
(sync'd @ 9508452e)
and updates the javascript snippet included in the /trace endpoint
to use the polyfill.
This brings in webcomponents.min.js copied from
https://chromium.googlesource.com/catapult/+/9508452e18f130c98499cb4c4f1e1efaedee8962/third_party/polymer/components/webcomponentsjs/webcomponents.min.js
That is necessary because the /trace endpoint needs to import
the vulcanized trace_viewer_full.html.
It's possible that some features are not working correctly with
this polyfill. In that case, report the issue to crbug.com/1036492.
There will be a warning message in the UI (yellow banner above the timeline)
which can be hidden by clicking the 'hide' button.
This allows to render the trace in browsers other than chrome in theory,
but I observed some buttons and functions still don't work outside
chrome.
Updates #34374.
Fixes #37343.
Change-Id: I0f369b15349dd0f4718c261ec23dfab6a47ace2f
Reviewed-on: https://go-review.googlesource.com/c/go/+/219997
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
(cherry picked from commit 75ea964b3f6073076e1a86a0de2be9a2f159da24)
Reviewed-on: https://go-review.googlesource.com/c/go/+/220323
|
|
In CL 219131 we inserted a VZEROUPPER instruction on darwin/amd64.
The instruction is not available on pre-AVX machines. Guard it
with CPU feature.
Updates #37459.
Fixes #37478.
Change-Id: I9a064df277d091be4ee594eda5c7fd8ee323102b
Reviewed-on: https://go-review.googlesource.com/c/go/+/221057
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
(cherry picked from commit c46ffdd2eca339918ed30b6ba9d4715ba769d35d)
Reviewed-on: https://go-review.googlesource.com/c/go/+/221058
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
|
|
If we see a racy use of timers, as in concurrent calls to Timer.Reset,
do the operations in an unpredictable order, rather than crashing.
Updates #37400
Updates #37449
Fixes #37494
Change-Id: Idbac295df2dfd551b6d762909d5040fc532c1b34
Reviewed-on: https://go-review.googlesource.com/c/go/+/221077
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit 98858c438016bbafd161b502a148558987aa44d5)
Reviewed-on: https://go-review.googlesource.com/c/go/+/221298
|
|
potential
As far as I can tell, there is no public documentation on this topic,
which cost me several days of debugging.
I am possibly unusual in that I run binaries in production with the
race detector turned on, but I think that others who do the same may
want to be aware of the risk.
Updates #26813.
Updates #37233.
Change-Id: I1f8111bd01d0000596e6057b7cb5ed017d5dc655
Reviewed-on: https://go-review.googlesource.com/c/go/+/220586
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
(cherry picked from commit ba093c4562e7464e95a4bde6505d270b71ed623f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/221019
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Adding a link to this guide will provide more value to instructing Go
users to migrate to modules.
Updates #36878
Change-Id: Ie6ab45efcd35cc5e5ba5adc16ba0ca4cca4292bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/220906
Run-TryBot: Alexander Rakoczy <alex@golang.org>
Reviewed-by: thepudds <thepudds1460@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 8e2dad5529d250d548e87720741d20e88a1dfaf2)
Reviewed-on: https://go-review.googlesource.com/c/go/+/220981
Reviewed-by: Carlos Amedee <carlos@golang.org>
|
|
Change-Id: Ic949a6caa8d55115630d0e8e7c9480b54c987b31
Reviewed-on: https://go-review.googlesource.com/c/go/+/220901
Run-TryBot: Carlos Amedee <carlos@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
Change-Id: I02afbd08ce9e0cd2af8953693b9c3066f6465914
Reviewed-on: https://go-review.googlesource.com/c/go/+/220937
Reviewed-by: Carlos Amedee <carlos@golang.org>
|
|
FreeBSD 12.0 or later
Updates #24715
Updates #37345
Change-Id: I787a9b2ab1c68e1d379aac0a31bdf6217f04f911
Reviewed-on: https://go-review.googlesource.com/c/go/+/220426
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
(cherry picked from commit 28c501b7b3405cf2afa7b9a440c9fc835d5276a0)
Reviewed-on: https://go-review.googlesource.com/c/go/+/220427
|
|
Use consistent indentation for one of the paragraphs.
Include issue number in the visible text, so it is easier to read.
Updates #36878
Change-Id: Iab857b26b1d27b0137e981126207089db108d530
Reviewed-on: https://go-review.googlesource.com/c/go/+/220646
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
(cherry picked from commit 1c0d664128ed5f1d7c66afb69cb2d15064a1ba43)
Reviewed-on: https://go-review.googlesource.com/c/go/+/220650
|
|
Also fix typo in crypto/cipher/gcm_test.go.
Updates #37118
Fixes #37416
Change-Id: I8544d1eeeb1f0336cebb977b8c5bfa5e4c5ad8c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/218500
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
(cherry picked from commit 4e8badbbc2fe7854bb1c12a9ee42315b4d535051)
Reviewed-on: https://go-review.googlesource.com/c/go/+/220651
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
|
|
Hash initializes seed on the first usage of seed or state with initSeed.
initSeed uses SetSeed which discards accumulated data.
This causes hash to return different sums for the same data in the first use
and after reset.
This CL fixes this issue by separating the seed set from data discard.
Updates #37315
Change-Id: Ic7020702c2ce822eb700af462e37efab12f72054
GitHub-Last-Rev: 48b2f963e86c1b37d49b838a050cc4128bb01266
GitHub-Pull-Request: golang/go#37328
Reviewed-on: https://go-review.googlesource.com/c/go/+/220259
Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
(cherry picked from commit 638df87fa4f927763f99ebf0c6bc9c4a5380d1f9)
Reviewed-on: https://go-review.googlesource.com/c/go/+/220617
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
|
|
This update was automatically generated using the updatecontrib command:
cd gotip
go run golang.org/x/build/cmd/updatecontrib
With minor manual changes based on publicly available information
to canonicalize letter case and formatting for a few names.
Actions taken (relative to CONTRIBUTORS at origin/master):
Added Aaron Bieber <deftly@gmail.com>
Added Adam Williams <pwnfactory@gmail.com>
Added Ayke van Laethem <aykevanlaethem@gmail.com>
Added Bradford Lamson-Scribner <brad.lamson@gmail.com>
Added Brian Falk <falk@logicparty.org>
Added Chen Zhihan <energiehund@gmail.com>
Added Christopher Loessl <cloessl+github@gmail.com>
Added Frederik Zipp <fzipp@gmx.de>
Added Fujimoto Kyosuke <kyoro.f@gmail.com>
Added GitHub User jopbrown (6345470) <msshane2008@gmail.com>
Added GitHub User yah01 (12216890) <kagaminehuan@gmail.com>
Added Hiromichi Ema <ema.hiro@gmail.com>
Added Jamal Carvalho <jamal.a.carvalho@gmail.com>
Added Jason Baker <jason-baker@users.noreply.github.com>
Added Kanta Ebihara <kantaebihara@gmail.com>
Added Kirill Tatchihin <kirabsuir@gmail.com>
Added Kévin Dunglas <dunglas@gmail.com>
Added Mariano Cano <mariano@smallstep.com>
Added Sergey Ivanov <ser1325@gmail.com>
Added Thomas Symborski <thomas.symborski@gmail.com>
Added Tomohiro Kusumoto <zabio1192@gmail.com>
Added Xingqang Bai <bxq2011hust@qq.com>
Used GitHub User jopbrown (6345470) form for jopbrown <msshane2008@gmail.com> https://github.com/golang/exp/commit/0405dc7 [exp]
Used GitHub User yah01 (12216890) form for yah01 <kagaminehuan@gmail.com> https://github.com/golang/go/commit/ee55dd6b64 [go]
Used GitHub name "Hiromichi Ema" for emahiro <ema.hiro@gmail.com> https://github.com/golang/tools/commit/b6336cbc [tools]
Used GitHub name "Jamal Carvalho" for Gopher <jamal.a.carvalho@gmail.com> https://github.com/golang/gddo/commit/31dd61d [gddo]
Used GitHub name "Xingqang Bai" for bxq2011hust <bxq2011hust@qq.com> https://github.com/golang/go/commit/79ccbe1b67 [go]
Updates #12042
Change-Id: I13f8ab37f8b38f8f5d0ff71c939ad39d0bc4f985
Reviewed-on: https://go-review.googlesource.com/c/go/+/220363
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-on: https://go-review.googlesource.com/c/go/+/220368
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
It might break a program if it was depending on undocumented behavior.
Give a proper heads up.
Updates #37308.
Change-Id: Id65bc70def1138d5506b694329c52250b417ec6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/220418
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/220367
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
1cd724acb6 doc/go1.14: highlight the addition of hash/maphash package
a0cf2c872f doc/go1.14: remove TODO comment for CL 200439
a9ea91d571 cmd/link, runtime: skip holes in func table
88e564edb1 doc/go1.14: add missing period at sentence end
6917529cc6 testing: remove obsolete comment in testing.(*T) docs
Change-Id: Ifb581c251474e9445d65a4f34dd4dcbc469fdd79
|
|
Given that it's a package that did not exist before, was a proposal
in issue #28322, got accepted and implemented for 1.14, it seems to
be more than a minor change to the library. Highlight it accordingly.
Also specify the results are 64-bit integers, as done in CL 219340.
Updates #36878
Updates #28322
Change-Id: Idefe63d4c47a02cdcf8be8ab08c40cdb94ff2098
Reviewed-on: https://go-review.googlesource.com/c/go/+/219877
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Toshihiro Shiino <shiino.toshihiro@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Based on https://golang.org/issue/36878#issuecomment-587533153
and https://golang.org/issue/36878#issuecomment-587549692,
this is not a CL that needs to be mentioned in the release notes.
Updates #36878
Change-Id: Icaa9153da7481a1d3ebabc237411539dd770cef2
Reviewed-on: https://go-review.googlesource.com/c/go/+/219898
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
On PPC64 when external linking, for large binaries we split the
text section to multiple sections, so the external linking may
insert trampolines between sections. These trampolines are within
the address range covered by the func table, but not known by Go.
This causes runtime.findfunc to return a wrong function if the
given PC is from such trampolines.
In this CL, we generate a marker between text sections where
there could potentially be a hole in the func table. At run time,
we skip the hole if we see such a marker.
Fixes #37216.
Change-Id: I95ab3875a84b357dbaa65a4ed339a19282257ce0
Reviewed-on: https://go-review.googlesource.com/c/go/+/219717
Reviewed-by: David Chase <drchase@google.com>
|
|
Change-Id: I82050f16906e7d34555a592e96b7855515a1726a
Reviewed-on: https://go-review.googlesource.com/c/go/+/219641
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
|
|
We now only accumulate logs when not using -v. Just drop the sentence
entirely rather than try to describe the current situation.
Updates #24929
Updates #37203
Change-Id: Ie3bf37894ab68b5b129eff54637893c7a129da03
Reviewed-on: https://go-review.googlesource.com/c/go/+/219540
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
|
|
3eab754cd0 runtime: correct caller PC/SP offsets in walltime1/nanotime1
123f7dd3e1 runtime: zero upper bit of Y registers in asyncPreempt on darwin/amd64
a0c9fb6bd3 hash/maphash: mention the results are 64-bit integers
e237df5b53 runtime: fix fallback logic for aeshash on 32/64 bit
363bcd0068 cmd/go: eliminate empty '()' when passing -mod=readonly explicitly to 'go list'
7385947825 cmd/go/internal/modcmd: remove dead function addModFlag
5ce8005990 cmd/go/internal/web: fix a typo
d0050e2871 go/build: populate partial package information in importGo
1c241d2879 hash/maphash: mention that hash values do not persist in package docs
25da21ddc9 crypto/elliptic: document the Name and names of each curve
ab5d9f5831 doc/go1.14: add a couple minor crypto release notes
6a8164a254 go/doc: clarify that NewFromFiles caller must filter by GOOS/GOARCH
dff55c1f76 doc: move doc/modules.md to x/website
cfe2ab42e7 doc/go1.14: rearrange in alphabetical order
ca8bf63809 doc/go1.14: add link to TempFile in io/ioutil
a528215693 doc/go1.14: fix inconsistent markup
a6b03c64b2 runtime/race: update reference to compiler-rt sources
60d437f994 runtime: avoid double notewakeup in netpoll stub code
b8061825e5 doc: fill in 'go mod init' section of module documentation
cb16d26bd6 doc: fill in 'go mod download' section of module documentation
08d41dbb10 doc: fill in 'go list -m' section in module documentation
ff091b5fa0 doc: fill in 'Module-aware commands' section in module documentation
c7c525a79d doc: add section on module paths to module documentation
153a9e8033 doc: add section on go.mod file syntax
1a37095062 Revert "cmd/link: code cleanup in macho_combine_dwarf.go"
494dd1dddc cmd/link: code cleanup in macho_combine_dwarf.go
Change-Id: I9cd3edde698c3b87d2f3b3d9d6bdd5e6dae4e221
|
|
In walltime1/nanotime1, we save the caller's PC and SP for stack
unwinding. The code does that assumed zero frame size. Now that
the frame size is not zero, correct the offset. Rewrite it in a
way that doesn't depend on hard-coded frame size.
May fix #37127.
Change-Id: I47d6d54fc3499d7d5946c3f6a2dbd24fbd679de1
Reviewed-on: https://go-review.googlesource.com/c/go/+/219118
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
|
|
Apparently, the signal handling code path in darwin kernel leaves
the upper bits of Y registers in a dirty state, which causes many
SSE operations (128-bit and narrower) become much slower. Clear
the upper bits to get to a clean state.
We do it at the entry of asyncPreempt, which is immediately
following exiting from the kernel's signal handling code, if we
actually injected a call. It does not cover other exits where we
don't inject a call, e.g. failed preemption, profiling signal, or
other async signals. But it does cover an important use case of
async signals, preempting a tight numerical loop, which we
introduced in this cycle.
Running the benchmark in issue #37174:
name old time/op new time/op delta
Fast-8 90.0ns ± 1% 46.8ns ± 3% -47.97% (p=0.000 n=10+10)
Slow-8 188ns ± 5% 49ns ± 1% -73.82% (p=0.000 n=10+9)
There is no more slowdown due to preemption signals.
For #37174.
Change-Id: I8b83d083fade1cabbda09b4bc25ccbadafaf7605
Reviewed-on: https://go-review.googlesource.com/c/go/+/219131
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
|
|
Change-Id: I0d2ba52d79c34d77d475ec8d673286d0e56b826b
Reviewed-on: https://go-review.googlesource.com/c/go/+/219340
Reviewed-by: Alan Donovan <adonovan@google.com>
|
|
We were using the fallback hash unconditionally. Oops.
Fixes #37212
Change-Id: Id37d4f5c08806fdda12a3148ba4dbc46676eeb54
Reviewed-on: https://go-review.googlesource.com/c/go/+/219337
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
|
|
Discovered while investigating #37197.
Updates #33326
Updates #34822
Change-Id: I38b136a4ee762a580a554125066b9778491295f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/219237
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
This function is never called and should have been removed
earlier. work.AddModCommonFlags defines the -modfile flag instead.
Fixes #37189
Change-Id: I73ad2a727013a849cba44bf70de04160f37c97dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/219197
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
dependenicies -> dependencies
Change-Id: I0b8f06c04cf397c6330ffb43ac3ae5c2f7cf3138
Reviewed-on: https://go-review.googlesource.com/c/go/+/219157
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
This is a followup to CL 199840 and CL 203820. Cumulatively, they caused
a previously known bug to trigger more often while also nearly fixing it.
This change is a small fixup to CL 199840 that resolves the known bug
and prevents it from causing an additional regression in Go 1.14.
Part 1
The intention in CL 199840 was to return the same error that 'go list'
reported when the package wasn't located, so an early return was added.
However, to determine whether the package was located or not, p.Dir was
unintentionally checked instead of dir.
p is initialized to &Package{ImportPath: path} at top of Context.Import,
and its Dir field is never set before that line in importGo is reached.
So return errors.New(errStr) was always executed whenever errStr != "".
Originally, in CL 125296, the "go list" invocation did not include an
'-e' flag, so it would return a non-zero exit code on packages where
build constraints exclude all Go files, and importGo would return an
error like "go/build: importGo import/path: unexpected output: ...".
CL 199840 added an '-e' flag to the "go list" invocation, but checking
the wrong dir variable caused partial package information to never get
populated, and thus issue #31603 continued to occur, although with a
different error message (which ironically included the location of the
package that was supposedly "not found").
Now that the right dir is checked, issue #31603 is fixed.
Part 2
importGo checks whether it can use the go command to find the directory
of a package. In Go 1.13.x and earlier, one of the conditions to use the
go command was that the source directory must be provided.
CL 203820 made a change such that knowing the source directory was
no longer required:
// To invoke the go command,
-// we must know the source directory,
// ...
That meant build.Import invocations where srcDir is the empty string:
build.Import(path, "", build.FindOnly)
Started using the go command to find the directory of the package, and
started to run into issue #31603 as well. That's the #37153 regression.
Since this change fixes issue #31603, it also fixes issue #37153.
Part 3
There is one more thing. Delete the debugImportGo constant, it's unused.
Updates #26504 (CL 125296)
Updates #34752 (CL 199840)
Updates #34860 (CL 203820)
Fixes #31603
Fixes #37153
Change-Id: Iaa7dcc45ba0f708a978950c75fa4c836b87006f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/218817
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
Updates #36878
Fixes #37040
Change-Id: Ib0bd21481e5d9c3b3966c116966ecfe071243a24
Reviewed-on: https://go-review.googlesource.com/c/go/+/218297
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
|
|
See https://tools.ietf.org/html/rfc8422#appendix-A for a helpful table.
Also, commit to keeping them singletons, as that assumption is already
made all over the place in the ecosystem.
Fixes #34193
Change-Id: I2ec50fa18bb80e11d6101f2562df60b5e27d4f66
Reviewed-on: https://go-review.googlesource.com/c/go/+/218921
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
These were left out of CL 216759 because they are trivial, but I was
advised to be thorough.
Updates #36878
Change-Id: Id4fd3a84866a82265e3f89abfdad6e3d231b507c
Reviewed-on: https://go-review.googlesource.com/c/go/+/218918
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
The most well known and important build constraints to take into
account when rendering package documentation are the GOOS/GOARCH
values. Make it more clear in the NewFromFiles documentation that
they are a part of all build constraints that the caller is
responsible for filtering out.
Also suggest the "go/build".Context.MatchFile method for performing
file matching. The logic to perform build context file matching is
subtle and has many rules that aren't well known (for example,
taking the gc or gccgo compiler into account). It is currently the
only exported API in the standard library that implements this logic,
and it would be unfortunate if people attempt to re-create it because
they don't realize it is already available.
Updates #23864
Change-Id: I3c5901e7081acf79125b2d429ec3aa3b58416ed7
Reviewed-on: https://go-review.googlesource.com/c/go/+/218477
Reviewed-by: Robert Griesemer <gri@golang.org>
|
|
Moved /doc/modules.md from GOROOT to x/website. The corresponding
change in x/website is CL 218239. See explanation there.
Updates #33637
Change-Id: I329935624e6e264873bc68b6487405a63d3e7030
Reviewed-on: https://go-review.googlesource.com/c/go/+/218240
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
|
|
"Minor changes to the library" are basically arranged in alphabetical
order, but there are some mistakes so we will correct them.
Updates #36878
Change-Id: I8498563b739eff9f1b0a76ead3cf290191e0ce36
Reviewed-on: https://go-review.googlesource.com/c/go/+/218638
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
For convenience, TempFile in io/ioutil now has a link to the document.
Updates #36878
Change-Id: I5c22f57c886badd8ca423e34527c4b4bb029847b
Reviewed-on: https://go-review.googlesource.com/c/go/+/218637
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
|
|
Unlike the others, the dt tag of reflect is not next to the dl tag.
The dd's closing tags may or may not have been omitted. They were unified without omission.
Updates #36878
Change-Id: I4e24f93fe8763ae8a1e4392db72e0b4818884f44
Reviewed-on: https://go-review.googlesource.com/c/go/+/217701
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
|
|
Change-Id: Iabe46677f24fef6e482a4beca774dbfc553026a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/217778
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
|
