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>
In CL 217064, we made symbol's global index unique, but we still
reserve index space for each object file, which means we may
leave holes in the index space if the symbol is a dup or is
overwritten. In this CL, we stop reserving index spaces. Instead,
symbols are added one at a time, and only added if it does not
already exist. There is no more holes in the index space.
Change-Id: I3c4e67163c556ba1198e13065706510dac4692fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/217519
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
We have converted all the host object readers to the new loader
based mechanism, and no longer do sym.Symbol host object loading.
Remove that support. So we don't have to take care of that in
future changes to the loader.
TODO: there are still code outside the loader than can be
removed. This CL only focuses on the loader.
Change-Id: I67dd75f631964921a7c7a6576ed95b071241484a
Reviewed-on: https://go-review.googlesource.com/c/go/+/217518
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Now that we have local-global index mappings, just use that for
symbol reference resolution.
Change-Id: I6bc5405853fe040ff21b624ccd8da7965d66ec8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/217065
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@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>
The solaris-amd64-oraclerel builder is passing for the main Go repo
(on tip and release branches for 1.13 and 1.12), and golang.org/x repos
(also on tip and release branches for 1.13 and 1.12).
The builder is still maintained as described at
https://golang.org/issue/15581#issuecomment-550368581.
Updates #36878
Updates #15581
Change-Id: Icc6f7529ca2e05bb34f09ce4363d9582e80829c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/217738
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
There is an active builder that was added in CL 201597,
and it is passing on Go tip and release-branch.go1.13
(with one failure that appears to be flaky due to being
out of memory). It's also passing on all golang.org/x repos
on tip and release-branch.go1.13. It's not configured to
run on Go 1.12 release branches.
Updates #36878
Updates #15581
Change-Id: I4ed7fc62c11a09743832fca39bd61fa0cf6e7ded
Reviewed-on: https://go-review.googlesource.com/c/go/+/217737
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Both the Dragonfly release and tip builder have been passing for a
while. The net package's interface API is working on both builders since
CL 202317 which has been re-vendored in CL 202438.
Updates #34368
Updates #36878
Change-Id: I187178b3a59f2604187af453207fb4e24a56105c
Reviewed-on: https://go-review.googlesource.com/c/go/+/217358
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This saves a redirect and makes the document more consistent.
Change-Id: I67840f5dc05dffd8893a055618eb202b682a0ebc
Reviewed-on: https://go-review.googlesource.com/c/go/+/217698
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A js.Func object in fsCall was created for each call but never
released. This CL fixes this.
Change-Id: I2e2b504cbf4fb130b8cfe890a66d3a66aadf56a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/217417
Run-TryBot: Hajime Hoshi <hajimehoshi@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Agniva De Sarker <agniva.quicksilver@gmail.com>
Reviewed-by: Richard Musiol <neelance@gmail.com>
We don't usually document past behavior (like "As of Go 1.14 ...") and
in isolation the current docs made it sound like a and b could only be
negative or zero.
Change-Id: I0d3c2b8579a9c01159ce528a3128b1478e99042a
Reviewed-on: https://go-review.googlesource.com/c/go/+/217302
Reviewed-by: Ian Lance Taylor <iant@golang.org>
GCD is a method, not a function, so the link was broken.
Change-Id: Icbb09d39959e7c71a48987b15bb82febe12c3a19
Reviewed-on: https://go-review.googlesource.com/c/go/+/217303
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently, when mapping symbol's local index to global index, for
duplicated and overwriting/overwritten symbols, each appearance
of the symbol gets a global index, with one being the "primary",
and others "redirect" to it through the overwrite map. Basically,
the local-global index mapping is one to one, with overwrite/
dedup happening in global index level.
This has a few drawbacks:
- All symbol accesses effectively need to query the overwrite
map. This may hurt performance.
- For multi-level overwrites, (Y overwrites X, Z overwrites Y),
this can get quite complicated, and we have to follow the
redirection recursively.
- Failed to follow or to update the overwrite map leads to bugs.
In this CL, we change the index mapping mechanism so that each
symbol get a unique global index. Multiple appearances of the
same symbol get the same index. Now the local-global index
mapping is N to one. Overwrite/dedup happens directly in the
local-global mapping.
We keep both mapping directions in arrays. Each object carries
an array for its local-global mapping. The loader carries an
array mapping global index to the "primary" local index, which is
the one we should load from. This way, we can get rid of the
overwrite map, and index conversions are simply array accesses.
TODO: we still make reservation of the index space upfront, and
leave holes for dup symbols. Maybe get rid of the reservation and
holes.
Change-Id: Ia251489d5f2ff16a0b3156a71d141a70cdf03a4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/217064
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
A few minor changes that didn't feel worth mentioning:
* CL 205059: support leaving Certificates/GetCertificate nil if
GetConfigForClient is set
* CL 205059: send the unrecognized_name alert when there are no
available certificates
* CL 205068: add correct names for CHACHA20_POLY1305 ciphersuite constants
* CL 204046: fix CreateCRL for Ed25519 CAs
* CL 205058: add CertificateRequestInfo.Version
Change-Id: Ie820fb0c6842e669edde031132c7cda5b09e7682
Reviewed-on: https://go-review.googlesource.com/c/go/+/216759
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
It has been a while we have not done this.
Merge conflict resolution:
- deleted/rewritten code modified on master
- CL 214286, ported in CL 217317
(cmd/internal/obj/objfile.go)
- CL 210678, it already includes a fix to new code
(cmd/link/internal/ld/deadcode.go)
- CL 209317, applied in this CL
(cmd/link/internal/loadelf/ldelf.go)
Change-Id: Ie927ea6a1d69ce49e8d03e56148cb2725e377876
Port CL 214286 to new object files. This is in preparation of
merging master branch to dev.link.
Change-Id: I8cd93908a795c03b8c44df47f66728017c542f4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/217317
Reviewed-by: Jeremy Faller <jeremy@golang.org>
This heading was below the minor changes to the standard library.
It should be on top.
Many of the minor changes have been documented, so remove the broad
TODO comment. It is still a TODO to highlight more prominent changes
to the library, if there are any, under the "Core library" heading.
Updates #36878
Change-Id: If7fd9af9a933af917523e33fd2922c5f3c02c98b
Reviewed-on: https://go-review.googlesource.com/c/go/+/217277
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Currently, the symbol updater uses a pointer pointing to the
loader's payloads array. If the payloads slice grows (and moves),
the pointer may become stale and no longer point to the symbol's
actual payload. Specifically, consider
sb, sym := l.MakeSymbolUpdater(...)
// add a bunch of external symbols, which grows payload slice
sb.SetType(t)
l.SymType(sym) // may not return t
sb.SetType on line 3 may not have the desired effect, as
sb.extSymPayload may no longer point to the right payload. As a
result, the type we get on line 4 may be not the one we set.
Fix this by making the payload's address permanent. Once it is
allocated it will never move.
Change-Id: Iab190ea5aceb5c37f91d09ad4ffd458e881b03f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/217063
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
This was mistakenly changed during the refactor in CL 201728.
Restore the old behavior.
Change-Id: I9991859e7587f5f567bbe86ae19dede904b3a399
Reviewed-on: https://go-review.googlesource.com/c/go/+/217062
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Some tweaks based on comments from CL 216917.
Change-Id: I538ea0dfa947b53d5c4a7135c1aec912b0357083
Reviewed-on: https://go-review.googlesource.com/c/go/+/217121
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Implementation changes in go/types for #6977 required that internal
LookupFieldOrMethod calls had access to the current *Checker. In
order to make quick progress, I added a *Checker receiver to the
function LookupFieldOrMethod (thus making it a method), and added
a new function LookupFieldOrMethod. The plan was always to rename
that function (Checker.LookupFieldOrMethod) such that it wouldn't
be exported; with the obvious name being Checker.lookupFieldOrMethod.
But that name was already in use which is why I postponed the rename.
Eventually I forgot to clean it up. This CL fixes that with the
following renames:
Checker.lookupFieldOrMethod => Checker.rawLookupFieldOrMethod
Checker.LookupFieldOrMethod => Checker.lookupFieldOrMethod
Updates #6977.
Fixes#36916.
Change-Id: Icfafd0de9a19841ba5bd87142730fe7323204491
Reviewed-on: https://go-review.googlesource.com/c/go/+/217134
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Filippo Valsorda
Cherry Zhang
Jeremy Faller
Emmanuel T Odeke
Bryan C. Mills
David Chase
Dmitri Shuralyov
Ian Lance Taylor
Josh Bleecher Snyder
Katie Hockman
Toshihiro Shiino
Tobias Klauser
Hajime Hoshi
Brad Fitzpatrick
Jean de Klerk
Robert Griesemer
Keith Randall