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>
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>
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>
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>
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>
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>
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#31603Fixes#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>
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>
Otherwise we can see
- goroutine 1 calls netpollBreak, the atomic.Cas succeeds, then suspends
- goroutine 2 calls noteclear, sets netpollBroken to 0
- goroutine 3 calls netpollBreak, the atomic.Cas succeeds, calls notewakeup
- goroutine 1 wakes up calls notewakeup, crashes due to double wakeup
This doesn't happen on Plan 9 because it only runs one thread at a time.
But Fuschia wants to use this code too.
Change-Id: Ib636e4f327bb15e44a2c40fd681aae9a91073a30
Reviewed-on: https://go-review.googlesource.com/c/go/+/218537
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This reverts commit 494dd1dddc.
Reason for revert: Not suitable for Go 1.14, will send to Go 1.15 instead.
Change-Id: Iedc04fe6a9ace29a16498046eef9420afbaf4636
Reviewed-on: https://go-review.googlesource.com/c/go/+/218482
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
HTML pages served by the website have the option to opt-in to template
processing, by including "Template: true" in the page metadata.
This functionality is documented at
403f1254bd/godoc/template.go (L5-L30).
Historically, the Go 1 release notes have used template processing
to a great extent, but release notes for all subsequent major Go
releases have not.
Since this feature is generally not used and not very well known,
it tends to do more harm than good by making it possible for errors
in the template to prevent the release notes from showing up at all.
Disable this feature for Go 1.14 release notes and onwards.
We can consider enabling it when there's a stronger need for it.
Fixes#37072
Updates #37070
Change-Id: If93553d52df12544b46c4edcf3aa5eddc2a155ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/218058
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This caused 35 test failures in Google internal code,
so it's worth mentioning in the release notes.
Updates #31810
Updates #36878Fixes#37066
Change-Id: I2faa6bce4c7d735107eceaef7d95223844846454
Reviewed-on: https://go-review.googlesource.com/c/go/+/217978
Reviewed-by: Rob Pike <r@golang.org>
Documents io/ioutil.TempDir's new ability to create
predictable prefixes and suffixes, derived from the argument
'pattern', separated by the last '*' in it.
References: CL 198488
Updates #36878
Change-Id: I92c52fcc7d480ce74746e99e6e85a04efb87294f
Reviewed-on: https://go-review.googlesource.com/c/go/+/217780
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This commit changes the wording of a comment in malloc.go that describes
how span objects are zeroed to make it more clear.
Change-Id: I07722df1e101af3cbf8680ad07437d4a230b0168
GitHub-Last-Rev: 0e909898c7
GitHub-Pull-Request: golang/go#37008
Reviewed-on: https://go-review.googlesource.com/c/go/+/217618
Reviewed-by: Austin Clements <austin@google.com>
It was removed in CL 217302 but was intentionally added in CL 217104.
Change-Id: I1a478d80ad1ec4f0a0184bfebf8f1a5e352cfe8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/217941
Reviewed-by: Robert Griesemer <gri@golang.org>
Document that for Windows, net/http.ServeFile can now
correctly serve files >2GB after we fixed internal/poll.SendFile
to transmit files larger than the default Windows limit of 2GB.
References: CL 192518, CL 194218
Updates #36878
Change-Id: Ibefc8b2841bc0cee3a89884a680085f99d2b6928
Reviewed-on: https://go-review.googlesource.com/c/go/+/217779
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In CL 199417, we updated “How to Write Go Code” to give a basic
introduction to modules and to include module-mode commands.
However, most new users will end up reading “Getting Started”
(doc/install.html) before “How to Write Go Code”, and we forgot to
update the handful of commands there for module mode.
Before this change, the “Test your installation” section also covered
quite a few operations beoyond merely testing the installation: it
included setting up a GOPATH, building a binary, and installing and
cleaning binaries. Those are valuable operations to learn, but they
arguably belong in “How to Write Go Code”, not “Test your
installation” — and having all that extra detail in the install
instructions may well discourage folks from further essential reading.
Rather than updating all of those operations here, I've removed them.
A companion CL will update “How to Write Go Code” to ensure that it
mentions GOPATH (as the location of the module cache and the default
install location for binaries) and 'go clean -i'.
Updates #37042
Change-Id: I157f21ccbe3896575fa1115dc821abf6c71ed15e
Reviewed-on: https://go-review.googlesource.com/c/go/+/217840
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tyler Bui-Palsulich <tbp@google.com>
These 3 release notes have had an element ID collision because both
the runtime changes and changes to the package "runtime" used the
same ID. Fix it by using a "pkg-" prefix for the runtime package.
Move the "runtime-again" ID from CL 129635 to a nearby <dt> element
so that existing links to https://golang.org/doc/go1.11#runtime-again
don't break.
Fixes#37036
Updates #36878
Change-Id: Ib68d93acfac802fd84c0a57485937e45dea2064a
Reviewed-on: https://go-review.googlesource.com/c/go/+/217797
Reviewed-by: Toshihiro Shiino <shiino.toshihiro@gmail.com>
Reviewed-by: Agniva De Sarker <agniva.quicksilver@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
net.LookupHost("foo\x00bar") may resolve successfully on some networks.
Reduce the scope of the test to check only that the call doesn't panic.
Also update the test comment to reference the relevant issue.
Fixes#37031
Updates #31597
Change-Id: If175deed8121625ef507598c6145e937ccffd89e
Reviewed-on: https://go-review.googlesource.com/c/go/+/217729
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
It's possible for the scheduler to try to preempt a goroutine running
on a thread created by C code just as the goroutine returns from Go code
to C code. If that happens, the goroutine will have a nil g,
which would normally cause us to enter the badsignal code.
The badsignal code will allocate an M, reset the signal handler,
and raise the signal. This is all wasted work for SIGURG,
as the default behavior is for the kernel to ignore the signal.
It also means that there is a period of time when preemption requests
are ignored, because the signal handler is reset to the default.
And, finally, it triggers a bug on 386 OpenBSD 6.2. So stop doing it.
No test because there is no real change in behavior (other than on OpenBSD),
the new code is just more efficient
Fixes#36996
Change-Id: I8c1cb9bc09f5ef890cab567924417e2423fc71f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/217617
Reviewed-by: Austin Clements <austin@google.com>
Previously, the release notes broke up the sentences that modules
is now ready for production use and where to file issues for
migration problems into separate paragraphs. This made it look like
the migration paragraph was about upgrading to 1.14, not to modules,
and made the reading a bit confusing. Now the entire idea is in one
paragraph.
Change-Id: I10bddfb8aba5f5909ac6842f25e3e97d505835e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/217720
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This reverts CL 217417 (commit 753d56d364).
This change was unintentionally submitted to master during the
Go 1.14 code freeze; it should be sent again for Go 1.15.
Change-Id: Ie790342f227ae3adfc5f9a90ce3abdc2c9be619b
Reviewed-on: https://go-review.googlesource.com/c/go/+/217721
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
