The linker now accepts unrecognized object files in external linking mode.
These objects will simply be passed to the external linker.
This permits using -flto which can generate pure byte code objects,
whose symbol table the linker does not know how to read.
The cgo tool now passes -fno-lto when generating objects whose symbols
it needs to read. The cgo tool now emits matching types in different
objects, so that the lto linker does not report a mismatch.
This is based on https://golang.org/cl/293290 by Derek Parker.
For #43505Fixes#43830Fixes#46295
Change-Id: I6787de213417466784ddef5af8899e453b4ae1ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/322614
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Also delete the TODO for the linker section.
Updates #44513.
Updates #40724.
Change-Id: I4d62a907e8c3070831a052cdfe1e21648698df12
Reviewed-on: https://go-review.googlesource.com/c/go/+/323289
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
When 'go get' updates a module, it may update another module in the
build list that provides a package in 'all' that wasn't loaded as part
of the 'go get' command. If 'go get' doesn't add a sum for that
module, builds may fail later.
With this change, 'go get' will fetch a sum for the content of an
updated module if we had a sum for the version before the update.
'go get' won't load the complete package graph, so there are still
cases where the build may be broken, like when an updated (but not
loaded) package imports a package from a new module.
Fixes#44129
Change-Id: I62eba3df4137a3e84e2ca8d549c36eec3670f08c
Reviewed-on: https://go-review.googlesource.com/c/go/+/322832
Trust: Jay Conrod <jayconrod@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The GoVersion field was added to types.Config as part of the work on
type parameters. Specifically, it was added to be consistent with
cmd/compile/internal/types2, which requires such an option.
This configuration option is useful, but is also non-trivial and did not
go through the proposal process. Unexport it for Go 1.17; we can create
a proposal to export it for Go 1.18.
Fixes#46296
Change-Id: Id82d8a7096887dcfc404c4d6d8da9c761b316609
Reviewed-on: https://go-review.googlesource.com/c/go/+/323430
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>
Documents the newly added mode that skips type checking
functions as per CL 301493.
Fixes#46025
For #34652
For #44513
For #38627
Change-Id: I56c4f65924702a931944796e39f43cfeb66abc8a
Reviewed-on: https://go-review.googlesource.com/c/go/+/311569
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Michael Knyszek <mknyszek@google.com>
For #44513
Change-Id: I8c0070b116ee520a76726eb9d3dcbdd489a1fb1f
Reviewed-on: https://go-review.googlesource.com/c/go/+/323351
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
For #44513
Change-Id: Ib21af742e574fcaa7e38bb437d42dbeed9d01f0b
Reviewed-on: https://go-review.googlesource.com/c/go/+/323350
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
The IsMethod method was added to FuncDecl in the process of working on
support for type parameters, but is now only used in one place. It also
didn't go through the proposal process. Remove it for 1.17.
Also clean up a doc comment that mentioned type parameters.
Fixes#46297
Change-Id: I432bdd626324f613baf059540b7c5436985b2b16
Reviewed-on: https://go-review.googlesource.com/c/go/+/323369
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>
The documentation of the Client.Do method and Get function incorrectly
stated that, in case of context cancelation, the returned url.Error
Timeout method returns true.
Update the documentation to correctly match the implementation.
See also CL 200798 that, due to an oversight, corrected only the
documentation of the Client.Get method.
Remove a TODO note added in CL 125575 (net/http: document that Client
methods always return *url.Error), since it is no longer applicable
after CL 200798 (net/http: fix and lock-in Client.Do docs on request
cancelation).
Fixes#46402
Change-Id: Ied2ee971ba22b61777762dbb19f16e08686634ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/323089
Reviewed-by: Damien Neil <dneil@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
For #44513.
Fixes#46019.
Change-Id: Ica84edd5703a4ccf343ff01e10483f8d51d1c79f
Reviewed-on: https://go-review.googlesource.com/c/go/+/323069
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
'go mod download' calls modload.LoadModFile early to find the main
module path in order to validate arguments. LoadModFile may write
go.mod and go.sum to fix formatting and add a go directive. This calls
keepSums, which, in eager mode, loaded the complete module graph in
order to find out what sums are needed to load the complete module
graph. If go.mod requires a lower version of a module than will be
selected later, keepSums causes the sum for that version's go.mod to
be retained, even though it isn't needed later after a consistent
go.mod is written.
This CL fixes keepSums not to load the graph if it hasn't already been
loaded (whether eager or lazy), addressing comments from CL 318629.
For #45332
Change-Id: I20d4404004e4ad335450fd0fd753e7bc0060f702
Reviewed-on: https://go-review.googlesource.com/c/go/+/322369
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
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: I47a4f58c031cb752f732e88bbdae7f819f0af4f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/323131
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
During DWARF debug location generation, as a preamble to the main data
flow analysis, examine the function entry block to look for in-params
arriving in registers that are partially or completely dead, and
insert new OpArg{Int,Float}Reg values for the dead or partially-dead
pieces. In addition, add entries to the f.NamedValues table for
incoming live register-resident params that don't already have
entries. This helps create better/saner DWARF location expressions for
params. Example:
func foo(s string, used int, notused int) int {
return len(s) + used
}
When optimization is complete for this function, the parameter
"notused" is completely dead, meaning that there is no entry for it in
the f.NamedValues table (which then means we don't emit a DWARF
variable location expression for it in the function enty block). In
addition, since only the length field of "s" is used, there is no
DWARF location expression for the other component of "s", leading to
degraded DWARF.
There are still problems/issues with DWARF location generation, but
this does improve things with respect to being able to print the
values of incoming parameters when stopped in the debugger at the
entry point of a function (when optimization is enabled).
Updates #40724.
Change-Id: I5bb5253648942f9fd33b081fe1a5a36208e75785
Reviewed-on: https://go-review.googlesource.com/c/go/+/322631
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Tweak the register allocator to maintain the invariant that
OpArg{Int,Float}Reg values are placed together at the start of the
entry block, before any other non-pseudo-op values. Without this
change, when the register allocator adds spills we can wind up with an
interleaving of OpArg*Reg and stores, which complicates debug location
analysis.
Updates #40724.
Change-Id: Icf30dd814a9e25263ecbea2e48feb840a6e7f2bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/322630
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Apparently C printf emits "\r\n" on Windows. Accept that.
Change-Id: If87ba41435e3147d3892cfc3fe3a105b066ff0aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/322973
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
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>
