When importing generic named types, it is possible for Checker.newNamed
to be called during type instantiation when the Checker is nil.
In this case we should be able to safely skip this delayed expansion.
Updates #45580
Change-Id: I75422100464d57eba24642c93e06e8b47d904fc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/322974
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This reverts commit c89f1224a5.
Reason for revert: reverting so we can apply follow-up fixes and do a single cherry pick.
Change-Id: I16c6283a0bcab056216f330fb98fa3b5f2b0780c
Reviewed-on: https://go-review.googlesource.com/c/go/+/323129
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Instead, check that stale packages in the standard library
are not rebuilt when already present in the build cache,
and are not installed implicitly when rebuilt.
We retain the staleness checks for the runtime package in tests
involving '-i', because those are guaranteed to fail anyway if the
package is stale and the "stale" failure message is arguably clearer.
They can be removed if/when we remove the '-i' flag, but the runtime
package is less likely to become stale because it does not have cgo
dependencies.
Fixes#46347
Updates #33598
Updates #35459
Updates #41696
Change-Id: I7b0a808addd930f9f4911ff53ded62272af75a40
Reviewed-on: https://go-review.googlesource.com/c/go/+/322629
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The test would hang if the call to Fd set the pipe to be non-blocking
before the Read entered the first read system call. Avoid that problem
by writing data to the pipe to wake up the read.
For #24481Fixes#44818
Change-Id: I0b798874c7b81e7308a38ebbf657efc4392ffacd
Reviewed-on: https://go-review.googlesource.com/c/go/+/322893
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Change-Id: Ib34984a6bd0abc76266e8aac96f9f8ad8ae21d17
Reviewed-on: https://go-review.googlesource.com/c/go/+/322894
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixes#46023
Change-Id: Ia63829d03afb0936862b16f0971175cbaa1095bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/322890
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For #44513.
Fixes#46013.
Change-Id: I382603208aa94b66d5220cf0f418b8528a4e4148
Reviewed-on: https://go-review.googlesource.com/c/go/+/322892
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
To support lazy expansion of defined types, *Named holds on to a
*Checker field, which can pin the *Checker in memory. This can have
meaningful memory implications for applications that keep type
information around.
Ensure that the Checker field is nilled out for any Named types that are
instantiated during the type checking pass, by deferring a clean up to
'later' boundaries.
In testing this almost exactly offset the ~6% memory footprint increase
I observed with 1.17.
Fixes#45580
Change-Id: I8aa5bb777573a924afe36e79fa65f8729336bceb
Reviewed-on: https://go-review.googlesource.com/c/go/+/318849
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Code moved and functions reordered to be in a consistent
top-down dependency order, but otherwise unchanged.
First step toward commenting division algorithms.
Change-Id: Ib5e604fb5b2867edff3a228ba4e57b5cb32c4137
Reviewed-on: https://go-review.googlesource.com/c/go/+/321077
Trust: Russ Cox <rsc@golang.org>
Trust: Katie Hockman <katie@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Also add a link to the time.Time type and adjust the wording a bit.
Change-Id: I2f4210ada6d253eb5804e6327b2432487beb8a05
Reviewed-on: https://go-review.googlesource.com/c/go/+/321811
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Since the number of files in the EOCD record isn't validated, it isn't
safe to preallocate Reader.Files using that field. A malformed archive
can indicate it contains up to 1 << 128 - 1 files. We can still safely
preallocate the slice by checking if the specified number of files in
the archive is reasonable, given the size of the archive.
Thanks to the OSS-Fuzz project for discovering this issue and to
Emmanuel Odeke for reporting it.
Fixes#46242
Fixes CVE-2021-33196
Change-Id: I3c76d8eec178468b380d87fdb4a3f2cb06f0ee76
Reviewed-on: https://go-review.googlesource.com/c/go/+/318909
Trust: Roland Shoemaker <roland@golang.org>
Trust: Katie Hockman <katie@golang.org>
Trust: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
For the methods LookupCNAME, LookupSRV, LookupMX, LookupNS, and
LookupAddr check that the returned domain names are in fact valid DNS
names using the existing isDomainName function.
Thanks to Philipp Jeitner and Haya Shulman from Fraunhofer SIT for
reporting this issue.
Fixes#46241
Fixes CVE-2021-33195
Change-Id: Icf231acd93178a3b6aec3f178cff7e693f74ef8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/320949
Trust: Roland Shoemaker <roland@golang.org>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
The stack pointer may have changed after a call from JavaScript into Go
code because of stack growth. The normal case already updated the
sp variable accordingly, but the catch case did not yet.
Fixes#45433
Change-Id: I3e0a33381929626f6b21902948935eb5ffb26c96
Reviewed-on: https://go-review.googlesource.com/c/go/+/321936
Trust: Richard Musiol <neelance@gmail.com>
Run-TryBot: Richard Musiol <neelance@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
On architectures which don't support unaligned loads, make sure we
don't generate code that requires them.
Generated hash functions also matter in this respect, but they all look ok.
Update #37716Fixes#46283
Change-Id: I6197fdfe04da4428092c99bd871d93738789e16b
Reviewed-on: https://go-review.googlesource.com/c/go/+/322151
Trust: Keith Randall <khr@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Records if regabi was enabled during compilation in the DW_AT_producer
attribute of each compile unit.
This is useful to debuggers that support the debugCall protocol.
Change-Id: I5ad2c48ebf126aeb8bfb459b53a1a5304550036a
Reviewed-on: https://go-review.googlesource.com/c/go/+/318050
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is a different fix for #37716.
Should help make the fix for #46283 easier, since we will no longer
need to keep compiler-generated hash functions and the runtime
hash function in sync.
Change-Id: I84cb93144e425dcd03afc552b5fbd0f2d2cc6d39
Reviewed-on: https://go-review.googlesource.com/c/go/+/322150
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The Go ABI, as it stands, requires spill space to be reserved for
register arguments. syscall.NewCallback (because of compileCallback)
does not actually reserve this space, leading to issues if the Go code
it invokes actually makes use of it.
Fixes#46301.
Change-Id: Idbc3578accaaaa29e4ba32291ef08d464da0b7b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/322029
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Egon Elbre <egonelbre@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This is a revert of https://go-review.googlesource.com/c/go/+/316890,
which has positive effects on debugging + DWARF variable locations
for register parameters when the reg abi is in effect, but also
turns out to interact badly with the register allocator.
Fixes#46304.
Change-Id: I624bd980493411a9cde45d44fcd3c46cad796909
Reviewed-on: https://go-review.googlesource.com/c/go/+/321830
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Changes include:
* ReadRequest function now returns an error when a request has multiple
Host headers.
For #44513.
Updates #46015.
Change-Id: I48ea7c5cee3f1d1a247035fd37191362a53d1f04
Reviewed-on: https://go-review.googlesource.com/c/go/+/317914
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Heschi Kreinick <heschi@google.com>
As of CL 318629, 'go mod download' without arguments does not save
checksums for module source code. Without a checksum, 'go list' will
not report the location of the source code even if it is present, in
order to prevent accidental access of mismatched code.
Downloading an explicit module here also more clearly expresses the
intent of the test (“download this module and see where it is”), and
may be somewhat more efficient (since the test doesn't need source
code for the other modules in the build list).
Updates #45332
Change-Id: Ic589b22478e3ed140b95365bb6729101dd598ccc
Reviewed-on: https://go-review.googlesource.com/c/go/+/321956
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Fixes#43894
Change-Id: I2add7b8a4f6ae69a5ef1c48703fde21a4b74307c
Reviewed-on: https://go-review.googlesource.com/c/go/+/321852
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>
Fixes#38874
Change-Id: I819dd008fd6869d335888b4aa03dcf739da9a9a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/320069
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>
'go mod download' without arguments is frequently used to populate the
module cache. It tends to fetch a lot of extra files (for modules in
the build list that aren't needed to build packages in the main
module). It's annoying when sums are written for these extra files.
'go mod download mod@version' will still write sums for specific
modules in the build list. 'go mod download all' still has the
previous behavior.
For now, all invocations of 'go mod download' still update go.mod and
go.sum with changes needed to load the build list (1.15 behavior).
Fixes#45332
Change-Id: I9e17d18a7466ac7271a0e1a2b663f6b3cb168c97
Reviewed-on: https://go-review.googlesource.com/c/go/+/318629
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Fixes#46294
Change-Id: I50023006dab83dee455f98a702ca1c72e61764ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/321649
Trust: Jay Conrod <jayconrod@google.com>
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The test harness waits for "ready" as a sign that the Go runtime has
installed its signal handler and is ready to be tested. But actually,
while LoadLibrary starts the loading of the Go runtime, it does so
asynchronously, so the "ready" sign is potentially premature and
certainly racy. However, all exported cgo entry points make a call to
_cgo_wait_runtime_init_done which waits for that asynchronous
initialization to complete. Therefore, this commit fixes the test to
call into the exported "Dummy" cgo function before emitting the "ready"
sign, so that we're sure the Go runtime is actually loaded.
Updates #45638.
Change-Id: I9b12b172d45bdcc09d54dd301de3a3e499544834
Reviewed-on: https://go-review.googlesource.com/c/go/+/321769
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The documentation currently does not show how to get an `FS` instance for the operating system's filesystem. This example demonstrates how to accomplish this using the `os` package.
Fixes#46083
Change-Id: I053111c12ab09ef13f0d04fcdff8a6ea0dccf379
Reviewed-on: https://go-review.googlesource.com/c/go/+/319989
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
This brings in CLs 312829, 317431, 319211.
Fixes#40356.
Fixes#46129.
Change-Id: I2ee1f858b2a41ffa60d88b0c17511ccad57f1816
Reviewed-on: https://go-review.googlesource.com/c/go/+/321389
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Tim King <taking@google.com>
Run-TryBot: Tim King <taking@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Documents the changes to File.WriteString method.
For #44513.
Fixes#46018.
Change-Id: I3a8ef9df9f84662614d54802710bd705d626b995
Reviewed-on: https://go-review.googlesource.com/c/go/+/317910
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
Up to FreeBSD 12.1 the package ca_root_nss was needed in order to have
certificates under /usr/local/share/certs as the base system didn't have
a system trusted certificate store.
This has been fixed in FreeBSD 12.2 using /etc/ssl/certs:
https://svnweb.freebsd.org/base?view=revision&revision=357082Fixes#46284
Change-Id: I912b1bacc30cdf20d19e3ef9d09b69bb8055ff49
GitHub-Last-Rev: 0fa5542ea3
GitHub-Pull-Request: golang/go#46276
Reviewed-on: https://go-review.googlesource.com/c/go/+/321190
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Update #36739
Change-Id: I14ab2cd0e29966b9a2f992e8c3bcb415203e63e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/321449
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Currently NewCallback and NewCallbackCDecl may only be called a limited
number of times in a single Go process, but this property of the API is
not documented. This change fixes that, but does not document the
precise limit to avoid making that limit part of the API, leaving us
open to increasing or decreasing the limit in the future as needed.
Although the API avoids documenting a limit, it does guarantee a minimum
callback count so users can rely on at least some amount of callbacks
working.
Updates #46184.
Change-Id: I5129bf5fe301efff73ac112ba1f207ab32058833
Reviewed-on: https://go-review.googlesource.com/c/go/+/321133
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
