In 1.17, //go:build lines are fully supported. This entails changes to
the go command, vet, and gofmt. Document all of them.
I'm not Russ, but this is a significant change, it slipped under the
radar, and we're trying to get the release out. So here's what I got.
I wasn't sure where to put the go command change. On the one hand,
it's pretty significant. On the other, it certainly affects fewer
people than lazy loading. So it probably shouldn't be first, but I also
didn't want to bury it the middle of all the other module changes. Open
to suggestions.
Change-Id: Ia1a96bcfb1977973c5b0b0a6b18a9242a745af12
Reviewed-on: https://go-review.googlesource.com/c/go/+/326209
Trust: Heschi Kreinick <heschi@google.com>
Run-TryBot: Heschi Kreinick <heschi@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Semicolons are no longer valid separators, so
net/url.ParseQuery will now return an error
if any part of the query contains a semicolon.
net/http.(*Request).ParseMultipartForm has been
changed to fall through and continue parsing
even if the call to (*Request).ParseForm fails.
This change also includes a few minor refactors
to existing tests.
Fixes#25192
Change-Id: Iba3f108950fb99b9288e402c41fe71ca3a2ababd
Reviewed-on: https://go-review.googlesource.com/c/go/+/325697
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
The comments in the code refer to Knuth and to Burnikel and Ziegler,
but Knuth's presentation is inscrutable, and our recursive division
code does not bear much resemblance to Burnikel and Ziegler's paper
(which is fine, ours is nicer).
Add a standalone explanation of division instead of referring to
difficult or not-directly-used references.
Change-Id: Ic1b35dc167fb29a69ee00e0b4a768ac9cc9e1324
Reviewed-on: https://go-review.googlesource.com/c/go/+/321078
Trust: Russ Cox <rsc@golang.org>
Trust: Katie Hockman <katie@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
The compiler machinery that generates "map.zero" symbols marks them as
RODATA and DUPOK, which is problematic when a given application has
multiple map zero symbols (from different packages) with varying
sizes: the dupok path in the loader assumes that if two symbols have
the same name, it is safe to pick any of the versions. In the case of
map.zero, the link needs to select the largest symbol, not an
arbitrary sym.
To fix this problem, mark map.zero symbols as content-addressable,
since the loader's content addressability processing path already
supports selection of the larger symbol in cases where there are dups.
Fixes#46653.
Change-Id: Iabd2feef01d448670ba795c7eaddc48c191ea276
Reviewed-on: https://go-review.googlesource.com/c/go/+/326211
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>
The linker's -strictdups debugging option was not properly checking
for cases where you have two dupok BSS symbols with different length
(the check examined data length and content, but not symbol size).
Updates #46653.
Change-Id: I3844f25ef76dd6e4a84ffd5caed5d19a1b1a57c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/326210
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>
For interface types, t.Methods contains only unexpanded method set, i.e
exclusive of interface embedding. Thus, we can't use it to detect an
interface contains embedding empty interface, like in:
type EI interface{}
func f() interface{ EI } {
return nil
}
At the time we generate runtime types, we want to check against the full
method set of interface instead.
Fixes#46386
Change-Id: Idff53ad39276be6632eb5932b76e855c15cbdd2e
Reviewed-on: https://go-review.googlesource.com/c/go/+/323649
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The package-level documentation on fmt previously had only two formal
sections, for printing and scanning. Because of this, the section on
printing was very long, including some pseudo-sections describing
particular features. This feature makes those pseudo-sections into
proper sections, both to improve readability and so that those sections
have hyperlinks on documentation sites.
Fixes#46522
Change-Id: I38b7bc3447610faca446051da235edcbbd063f61
Reviewed-on: https://go-review.googlesource.com/c/go/+/324349
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
The test was using the wrong column numbers, and was erroneously
passing because there happened to be line numbers that matched those
column numbers. Change the test harness to require the expected line
number for the ERROR HERE regexp case, so that this doesn't happen again.
Also rename a couple of variables in the test to avoid useless
redeclaration errors.
Fixes#46534
Change-Id: I2fcbf5e379c346de5346035c73d174a3980c0927
Reviewed-on: https://go-review.googlesource.com/c/go/+/324970
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
CL 249238 changes ResponseWriter.ReadFrom to probe the source with
a single read of sniffLen bytes before writing the response header.
If the source returns less than sniffLen bytes without reaching
EOF, this can cause Content-Type and Content-Length detection to
fail.
Fix ResponseWrite.ReadFrom to copy a full sniffLen bytes from
the source as a probe.
Drop the explicit call to w.WriteHeader; writing the probe will
trigger a WriteHeader call.
Consistently use io.CopyBuffer; ReadFrom has already acquired a
copy buffer, so it may as well use it.
Fixes#44953.
Change-Id: Ic49305fb827a2bd7da4764b68d64b797b5157dc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/301449
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The declaration order in CL 319310 does not match what the generator
produces from scratch. That currently causes
cmd/internal/moddeps.TestAllDependencies to fail, since it is
explicitly checking for that kind of skew.
Updates #45914
Change-Id: If2a9cabc3d54e21deba7cb438fa364df205f38ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/325112
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
On Windows 7 (and below), console handles are not real kernel handles
but are rather userspace objects, with information passed via special
bits in the handle itself. That means they can't be passed in
PROC_THREAD_ATTRIBUTE_HANDLE_LIST, even though they can be inherited.
So, we filter the list passed to PROC_THREAD_ATTRIBUTE_HANDLE_LIST to
not have any console handles on Windows 7. At the same time, it turns
out that the presence of a NULL handle in the list is enough to render
PROC_THREAD_ATTRIBUTE_HANDLE_LIST completely useless, so filter these
out too. Console handles also can't be duplicated into parent processes,
as inhertance always happens from the present process, so duplicate
always into the present process even when a parent process is specified.
Fixes#45914.
Change-Id: I70b4ff4874dbf0507d9ec9278f63b9b4dd4f1999
Reviewed-on: https://go-review.googlesource.com/c/go/+/319310
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This ir.Dump call is a debugging artifact introduced in
golang.org/cl/274103, which should never be printed for valid,
non-generic code, but evidently can now sometimes appear due to how
the parser handles invalid syntax.
The parser should probably not recognize "x[2]" as a type expression
in non-generics mode, but also probably we shouldn't try noding after
reporting syntax errors. Either way, this diagnostic has outlived its
usefulness, and noder's days are numbered anyway, so we might as well
just remove it to save end users any confusion.
Updates #46558.
Change-Id: Ib68502ef834d610b883c2f2bb11d9b385bc66e37
Reviewed-on: https://go-review.googlesource.com/c/go/+/324991
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Set the correct section flags to insure that .debug_* sections are
using 1-byte alignment instead of the default. This seems to be
important for later versions of LLVM-mingw on windows (shows up on the
windows/arm64 builder).
Updates #46406.
Change-Id: I023d5208374f867552ba68b45011f7990159868f
Reviewed-on: https://go-review.googlesource.com/c/go/+/324763
Trust: 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>
Following https://golang.org/cl/291329, exitsyscall0 accesses gp.lockedm
after releasing gp to the global runq. This creates a race window where
another M may schedule the (unlocked) G, which subsequently calls
LockOSThread, setting gp.lockedm and thus causing exitsyscall0 to think
it should call stoplockedm.
Avoid this race by checking if gp is locked before releasing it to the
global runq.
Fixes#46524
Change-Id: I3acdaf09e7a2178725adbe61e985130e9ebd0680
Reviewed-on: https://go-review.googlesource.com/c/go/+/324350
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Documents the newly implemented changes of
- Time.IsDST() method
- Addition of Time.UnixMilli, Time.UnixMicro and to-Time helpers UnixMicro, UnixMilli methods
- Addition of comma "," support as separator for fraction seconds
For #44513Fixes#46026
Change-Id: Ib8d3449d3b061f013112d33362b50e68ad6ddffa
Reviewed-on: https://go-review.googlesource.com/c/go/+/317913
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
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>
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>
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>
'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>
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>
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>
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>
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 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>
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>
'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>
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>
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>
If a filepath.WalkFunc returns filepath.SkipDir when invoked on a
non-directory file, it skips the remaining files in the containing
directory.¹
CL 276272 accidentally added a code path that triggers this behavior
whenever filepath.Walk reaches a non-directory file that begins with
a dot, such as .gitattributes or .DS_Store, causing findGorootModules
to return early without finding any modules in GOROOT. Tests that use
it ceased to provide test coverage that the tree is tidy.
Add an explicit check for info.IsDir in the 5 places that intend to
use filepath.SkipDir to skip traversing that directory. Even paths
like GOROOT/bin and GOROOT/pkg which are unlikely to be anything but
a directory are worth checking, since the goal of moddeps is to take
a possibly problematic GOROOT tree as input and detect problems.
While the goal of findGorootModules is to find all modules in GOROOT
programmatically (in case new modules are added or modified), there
are 4 modules now that are quite likely to exist, so check for their
presence to avoid similar regressions. (It's not hard to update this
test if a well-known GOROOT module is removed or otherwise modified;
but if it becomes hard we can simplify it to check for a reasonable
number of modules instead.)
Also fix the minor skew that has crept in since the test got disabled.
¹ This wasn't necessarily an intentional design decision, but it was
found only when Go 1.4 was already out. See CL 11690 for details.
Fixes#46254.
Change-Id: Id55ed926f8c0094b1af923070de72bacca05996f
Reviewed-on: https://go-review.googlesource.com/c/go/+/320991
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
In cases where the socket operation has no underlying address,
golang.org/cl/291509 unintentionally changed ReadFromUDP from return a
nil *UDPAddr to a non-nil (but zero value) *UDPAddr.
This may break callers that assume "no address" is always addr == nil,
so change it back to remain nil.
Fixes#46238
Change-Id: I8531e8fa16b853ed7560088eabda0b9e3e53f5be
Reviewed-on: https://go-review.googlesource.com/c/go/+/320909
Trust: Michael Pratt <mpratt@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
issue46234.go expects an error output "segmentation violation",
which is UNIX-specific. Check for "nil pointer dereference"
instead, which is emitted by the Go runtime and should work on all
platforms.
Should fix Windows builders.
Change-Id: I3f5a66a687d43cae5eaf6a9e942b877e5a248900
Reviewed-on: https://go-review.googlesource.com/c/go/+/321072
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 inlining functions with closures, ensure that we don't mark the
body of the closure with a src.Pos marker that reflects the inline,
since this will result in the generation of an inltree table for the
closure itself (as opposed to the routine that the func-with-closure
was inlined into).
Fixes#46234.
Change-Id: I348296de6504fc4745d99adab436640f50be299a
Reviewed-on: https://go-review.googlesource.com/c/go/+/320913
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Than McIntosh <thanm@google.com>
Apparently, in bash, the "continue" keyword can only be used
inside of a loop, not in an if block. If readelf exists but $CC
does not, make.bash emits a warning:
./make.bash: line 135: continue: only meaningful in a `for', `while', or `until' loop
Change it to a conditional.
Change-Id: I00a0940ed99bc0c565094e506705961b6b3d362e
Reviewed-on: https://go-review.googlesource.com/c/go/+/320170
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
People continue to be confused by how these work. Address that by some
rejiggering.
Introduce a constant called Layout that both defines the time and
provides a reference point for Parse and Format to refer to. We can
then delete much redundancy, especially for Format's comments, but
Parse tightens a bit too.
Then change the way the concept of the layout string is introduced,
and provide a clearer catalog of what its elements are.
Fixes#38871
Change-Id: Ib967ae70c7d5798a97b865cdda1fda4daed8a99a
Reviewed-on: https://go-review.googlesource.com/c/go/+/320252
Trust: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The test previously had the hardcoded assumption that /proc/self/status
files had "Groups:" lines containing numerical IDs in ascending order.
Because of the possibility of non-monotonic ordering of GIDs in user
namespaces, this assumption was not universally true for all
/proc/self/gid_map setups.
To ensure this test can pass in those setups, sanity check failed
"Groups:" line matches with a string sorted version of the expected
values. (For the test cases here, numerical and string sorted order
are guaranteed to match.)
Fixes#46145
Change-Id: Ia060e80b123604bc394a15c02582fc406f944d36
Reviewed-on: https://go-review.googlesource.com/c/go/+/319591
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
If a user runs 'go get example.com/cmd' for a package in the main
module, it's more likely they intend to fill in missing dependencies
for that package (especially with -u). If the intent were only to
build and install, 'go install example.com/cmd' would be a better
choice.
For #43684
Resolving a comment on CL 305670.
Change-Id: I5c80ffdcdb3425b448f2f49cc20b07a18cb2bbe9
Reviewed-on: https://go-review.googlesource.com/c/go/+/318570
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Some uses of crosscall2 did not work on ppc64le and probably
aix-ppc64. In particular, if there was a main program compiled
with -buildmode=pie and used a plugin which invoked crosscall2,
then failures could occur due to R2 getting set incorrectly along the
way. The problem was due to R2 being saved on the caller's
stack; it is now saved on the crosscall2 stack. More details can be
found in the issue.
This adds a testcase where the main program is built with pie
and the plugin invokes crosscall2.
This also changes the save of the CR bits from MOVD to MOVW as
it should be.
Fixes#43228
Change-Id: Ib5673e25a2ec5ee46bf9a1ffb0cb1f3ef5449086
Reviewed-on: https://go-review.googlesource.com/c/go/+/319489
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Heschi Kreinick <heschi@google.com>
osyield is called in code paths that are not allowed to split
stack, e.g. casgstatus called from entersyscall/exitsyscall.
It is nosplit on all other platforms. Mark it nosplit on OpenBSD
as well.
Change-Id: I3fed5d7f58b3d50610beca6eed2c7e902b8ec52c
Reviewed-on: https://go-review.googlesource.com/c/go/+/319969
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Joel Sing <joel@sing.id.au>
If the client request never makes it to the server, the outstanding
accept is never broken. Change the test to always close the listening
socket when the client request completes.
Updates #45358
Change-Id: I744a91dfa11704e7e528163d7669c394e90456dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/319275
Trust: Heschi Kreinick <heschi@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The Context.ImportDir method in the go/build package sets Package.Root
to $GOPATH, if a package is inside a GOPATH workspace. The
loadPackageData function keeps this value even when modules are enabled.
Override Package.Root when modules are enabled, instead of just set its
value when Context.ImportDir was unable to set it.
Add a regression test.
Fixes#46119
Change-Id: I900a33fe13a445cb771e2952d0d830f1b4a5921f
Reviewed-on: https://go-review.googlesource.com/c/go/+/319209
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Currently all script tests use the UNIX path separator with the cd
command, causing the PWD environment variable to have the incorrect path
separator on Windows.
Call filepath.FromSlash on the cd command argument.
Update the testdata/script/README to document that the cd argument must
use slashes.
Add a regression test.
To reproduce this issue, a test must use the cd command followed by a
stdout or stderr command containing the pattern $PWD.
Change-Id: Ib2dc5f185cc2476451402787996d14df91f7dddb
Reviewed-on: https://go-review.googlesource.com/c/go/+/319311
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
There was a space missing in the first line shown below, and an extra
space in the second line shown. Thanks Peter Bourgon for noting this.
BEFORE:
$ go help build | grep -A1 'has some limitations'
has some limitations:importantly, cgo files included from outside the
include path must be in the same directory as the Go package they are
AFTER:
$ go help build | grep -A1 'has some limitations'
has some limitations: importantly, cgo files included from outside the
include path must be in the same directory as the Go package they are
Note that I edited alldocs.go by hand here, as the mkalldocs.sh script
produces a lot more changes, for example adding the -insecure flag
documentation in. Not sure what's wrong there.
Change-Id: I303f6d6b42b0e24cec0748a949dc23beec64b917
Reviewed-on: https://go-review.googlesource.com/c/go/+/319949
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
In the deadcode path we mark runtime.unreachableMethod symbol,
which is a special symbol used for redirecting unreachable
methods. Currently this code is conditioned on not -linkshared.
This is wrong. It should be marked with -linkshared mode as well.
In fact, -linkshared should only affect the entry symbol. Change
the code accordingly.
Change-Id: I252abf850212a930f275589ef0035a43e52cb9cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/319893
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
We redirect references to unreachable methods to
runtime.unreachableMethod. We choose to use ABIInternal symbol
for this, because runtime.unreachableMethod is a defined Go
function.
When linking against shared libraries, and ABI wrappers are not
enabled, the imported function symbols are all ABI0 and aliased
to ABIInternal. We need to resolve ABI alias in this case.
Change-Id: Idd64ef46ce0b5f54882ea0069ce0d59dc9b7a599
Reviewed-on: https://go-review.googlesource.com/c/go/+/319891
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
It is unclear what the future holds for the go line in go.mod files.
Perhaps at some point we will switch to semver numbering.
Perhaps at some point we will allow specifying minor versions
or even betas and release candidates.
Those kinds of changes are difficult today because the go line
is parsed in dependency modules, meaning that older
versions of the Go toolchain need to understand newer go lines.
This CL makes that case - parsing a go line in a dependency's
go.mod file - a bit more lax about how to find the version.
It allows a leading v and any trailing non-digit-prefixed string
after the MAJOR.MINOR section.
There are no concrete plans to make use of any of these changes,
but if in the future we want to make them, having a few Go releases
under out belt that will accept the syntax in dependencies will
make any changes significantly easier.
Change-Id: I79bb84bba4b769048ac4b14d5c275eb9a3f270c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/317690
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
In Perl mode, (|a)* should match an empty string at the start of the
input. Instead it matches as many a's as possible.
Because (|a)+ is handled correctly, matching only an empty string,
this leads to the paradox that e* can match more text than e+
(for e = (|a)) and that e+ is sometimes different from ee*.
This is a very old bug that ultimately derives from the picture I drew
for e* in https://swtch.com/~rsc/regexp/regexp1.html. The picture is
correct for longest-match (POSIX) regexps but subtly wrong for
preferred-match (Perl) regexps in the case where e has a preferred
empty match. Pointed out by Andrew Gallant in private mail.
The current code treats e* and e+ as the same structure, with
different entry points. In the case of e* the preference list ends up
not quite in the right order, in part because the “before e” and
“after e” states are the same state. Splitting them apart fixes the
preference list, and that can be done by compiling e* as if it were
(e+)?.
Like with any bug fix, there is a very low chance of breaking a
program that accidentally depends on the buggy behavior.
RE2, Go, and Rust all have this bug, and we've all agreed to fix it,
to keep the implementations in sync.
Fixes#46123.
Change-Id: I70e742e71e0a23b626593b16ddef3c1e73b413b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/318750
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
The DWARF standard requires that the DIEs in a subprogram
corresponding to input and output parameters appear in declaration
order; this patch adds some new code in dwarfgen to enforce this
ordering (relying on the existing fn.Dcl ordering is not sufficient).
Prior to the register ABI, it was easy to keep vars/decls sorted
during DWARF generation since you could always rely on frame offset;
with the ABI sorting by frame offset no longer gives you the original
declaration order in all cases.
Fixes#46055.
Change-Id: I0e070cb781d6453caba896e5d3bee7cd5388050d
Reviewed-on: https://go-review.googlesource.com/c/go/+/318829
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This CL add runtime.memmove inlining for AMD64 and ARM64.
According to ssa dump from testcases generic rules can't inline
memmomve properly due to one of the arguments is Phi operation. But this
Phi op will be optimized out by later optimization stages. As a result
memmove can be inlined during arch-specific rules.
The commit add new optimization rules to arch-specific rules that can
inline runtime.memmove if it possible during lowering stage.
Optimization fires 5 times in Go source-code using regabi.
Fixes#41662
Change-Id: Iaffaf4c482d068b5f0683d141863892202cc8824
Reviewed-on: https://go-review.googlesource.com/c/go/+/289151
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: David Chase <drchase@google.com>
As a follow up to an earlier change[1] to add ARMv8+LSE instructions in
the compiler generated atomic intrinsics, make the same change in the
runtime library. Since not all ARMv8 systems support LSE instructions,
they are protected by a feature-flag branch.
[1]: golang.org/cl/234217 commit: ecc3f5112e
Change-Id: I0e2fb22e78d5eddb6547863667a8865946679a00
Reviewed-on: https://go-review.googlesource.com/c/go/+/310591
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Heschi Kreinick <heschi@google.com>
It is valid to see SPWRITE functions at the top of a GC stack traceback,
in the case where they self-preempted during the stack growth check
and haven't actually modified SP in a traceback-unfriendly manner yet.
The current check is therefore too aggressive.
isAsyncSafePoint is taking care of not async-preempting SPWRITE functions
because it doesn't async-preempt any assembly functions at all.
But perhaps it will in the future.
To keep a check that SPWRITE assembly functions are not async-preempted,
add one in preemptPark. Then relax the check in traceback to avoid
triggering on self-preempted SPWRITE functions.
The long and short of this is that the assembly we corrected in x/crypto
issue #44269 was incredibly dodgy but not technically incompatible with
the Go runtime. After this change, the original x/crypto assembly no longer
causes GC traceback crashes during "GOGC=1 go test -count=1000".
But we'll still leave the corrected assembly.
This also means that we don't need to worry about diagnosing SPWRITE
assembly functions that may exist in the wild. They will be skipped for
async preemption and no harm no foul.
Fixes#44269, which was open pending some kind of check for
bad SPWRITE functions in the wild. (No longer needed.)
Change-Id: I6000197b62812bbd2cd92da28eab422634cf75a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/317669
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The documentation of the go list -find flag says that the Deps list will
be empty. However the current implementation adds implicit imports when
supporting Cgo or SWIG and when linking a main package.
Update the documentation of PackageOpts.IgnoreImport to clarify that
both explicit and implicit imports are ignored.
Add a regression test.
Fixes#46092
Change-Id: I37847528d84adb7a18eb6ff29e4af4b4318a66fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/318770
Trust: Jay Conrod <jayconrod@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
As a cleanup, golang.org/cl/307914 unintentionally caused the idle GC
work recheck to drop sched.lock between acquiring a P and committing to
keep it (once a worker G was found).
This is unsafe, as releasing a P requires extra checks once sched.lock
is taken (such as for runSafePointFn). Since checkIdleGCNoP does not
perform these extra checks, we can now race with other users.
In the case of #45975, we may hang with this sequence:
1. M1: checkIdleGCNoP takes sched.lock, gets P1, releases sched.lock.
2. M2: forEachP takes sched.lock, iterates over sched.pidle without
finding P1, releases sched.lock.
3. M1: checkIdleGCNoP puts P1 back in sched.pidle.
4. M2: forEachP waits forever for P1 to run the safePointFn.
Change back to the old behavior of releasing sched.lock only after we
are certain we will keep the P. Thus if we put it back its removal from
sched.pidle was never visible.
Fixes#45975
For #45916
For #45885
For #45884
Change-Id: I191a1800923b206ccaf96bdcdd0bfdad17b532e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/318569
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This change alters the CurveParam methods to upgrade from the generic
curve implementation to the specific P224 or P256 implementations when
called on the embedded CurveParams. This removes the trap of using
elliptic.P224().Params() instead of elliptic.P224(), for example, which
results in using the generic implementation instead of the optimized
constant time one. For P224 this is done for all of the CurveParams
methods, except Params, as the optimized implementation covers all
these methods. For P256 this is only done for ScalarMult and
ScalarBaseMult, as despite having implementations of addition and
doubling they aren't exposed and instead the generic implementation is
used. For P256 an additional check that there actually is a specific
implementation is added, as unlike the P224 implementation the P256 one
is only available on certain platforms.
This change takes the simple, fast approach to checking this, it simply
compares pointers. This removes the most obvious class of mistakes
people make, but still allows edge cases where the embedded CurveParams
pointer has been dereferenced (as seen in the unit tests) or when someone
has manually constructed their own CurveParams that matches one of the
standard curves. A more complex approach could be taken to also address
these cases, but it would require directly comparing all of the
CurveParam fields which would, in the worst case, require comparing
against two standard CurveParam sets in the ScalarMult and
ScalarBaseMult paths, which are likely to be the hottest already.
Updates #34648
Change-Id: I82d752f979260394632905c15ffe4f65f4ffa376
Reviewed-on: https://go-review.googlesource.com/c/go/+/233939
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: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Recently some tsan tests were enabled on ppc64le which had not
been enabled before. This resulted in failures on systems with
tsan available, and while debugging it was determined that
there were other issues related to the use of signals with cgo.
Signals were not being forwarded within programs linked against
libtsan because the nocgo sigaction was being called for ppc64le
with or without cgo. Adding callCgoSigaction and calling that
allows signals to be registered so that signal forwarding works.
For linux-ppc64 and aix-ppc64, this won't change. On linux-ppc64
there is no cgo. I can't test aix-ppc64 so those owners can enable
it if they want.
In reviewing comments about sigtramp in sys_linux_arm64 it was
noted that a previous issue in arm64 due to missing callee save
registers could also be a problem on ppc64x, so code was added
to save and restore those.
Also, the use of R31 as a temp register in some cases caused an
issue since it is a nonvolatile register in C and was being clobbered
in cases where the C code expected it to be valid. The code sequences to
load these addresses were changed to avoid the use of R31 when loading
such an address.
To get around a vet error, the stubs_ppc64x.go file in runtime
was split into stubs_ppc64.go and stubs_ppc64le.go.
Updates #45040
Change-Id: Ia4ecff950613cbe1b89471790b1d3819d5b5cfb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/306369
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
go/build.ImportDir returns a *build.Package with various lists of
files. If a file is invalid for some reason, for example, because it
has a different package name than other files, it's added to
InvalidGoFiles in addition to GoFiles, TestGoFiles, or other lists.
Previously, files with parse errors or build constraint errors were
not included in these lists, which causes problems for tools that use
'go list' since InvalidGoFiles is not printed. With this change, files
with any kind of error are added to one of the GoFiles lists.
Fixes#39986
Change-Id: Iee007b5092293eb4420c8a39ce731805fe32135f
Reviewed-on: https://go-review.googlesource.com/c/go/+/241577
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
If a package has files with conflicting package names, go/build
empirically populates the first name encountered and puts the
remaining files in InvalidGoFiles. That foiled our check for packages
whose name is either unpopulated or "main", since the "package main"
could be found in a source file after the first.
Instead, we now treat any package with a nonzero set of InvalidGoFiles
as potentially a main package. This biases toward over-reporting
errors, but we would rather over-report than under-report.
If we fix#45999, we will be able to make these error checks more
precise.
Updates #42088Fixes#45827Fixes#39986
Change-Id: I588314341b17961b38660192c2130678dc03023e
Reviewed-on: https://go-review.googlesource.com/c/go/+/317300
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Encode the length of type names and tags in a varint encoding
instead of a fixed 2-byte encoding. This allows lengths longer
than 65535 (which can happen for large unnamed structs).
Removed the alignment check for #14962, it isn't relevant any more
since we're no longer reading pointers directly out of this data
(it is encoded as an offset which is copied out bytewise).
Fixes#44155
Update #14962
Change-Id: I6084f6027e5955dc16777c87b0dd5ea2baa49629
Reviewed-on: https://go-review.googlesource.com/c/go/+/318249
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Spreading function compilation across multiple goroutines results in
non-deterministic output. This is how cmd/compile has historically
behaved for concurrent builds, but is troublesome for non-concurrent
builds, particularly because it interferes with "toolstash -cmp".
I spent some time trying to think of a simple, unified algorithm that
can concurrently schedule work but gracefully degrades to a
deterministic build for single-worker builds, but I couldn't come up
with any. The simplest idea I found was to simply abstract away the
operation of scheduling work so that we can have alternative
deterministic vs concurrent modes.
Change-Id: I08afa00527ce1844432412f4f8553781c4e323df
Reviewed-on: https://go-review.googlesource.com/c/go/+/318229
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Like for P-224, we do the constant time selects to hide the
point-at-infinity special cases of addition, but not the P = Q case,
which presumably doesn't happen in normal operations.
Runtime increases by about 50%, as expected, since on average we were
able to skip half the additions, and the additions reasonably amounted
to half the runtime. Still, the Fiat code is so much faster than big.Int
that we're still more than three time faster overall than pre-CL 315271.
name old time/op new time/op delta
pkg:crypto/elliptic goos:darwin goarch:arm64
ScalarBaseMult/P521-8 4.18ms ± 3% 1.35ms ± 1% -67.64% (p=0.000 n=10+10)
ScalarMult/P521-8 4.17ms ± 2% 1.36ms ± 1% -67.45% (p=0.000 n=10+10)
pkg:crypto/ecdsa goos:darwin goarch:arm64
Sign/P521-8 4.23ms ± 1% 1.44ms ± 1% -66.02% (p=0.000 n=9+10)
Verify/P521-8 8.31ms ± 2% 2.73ms ± 2% -67.08% (p=0.000 n=9+9)
GenerateKey/P521-8 4.15ms ± 2% 1.35ms ± 2% -67.41% (p=0.000 n=10+10)
Updates #40171
Change-Id: I782f2b7f33dd60af9b3b75e46d920d4cb47f719f
Reviewed-on: https://go-review.googlesource.com/c/go/+/315274
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
Trust: Katie Hockman <katie@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Fiat Cryptography (https://github.com/mit-plv/fiat-crypto) is a project
that produces prime order field implementations (the code that does
arithmetic modulo a prime number) based on a formally verified model.
The formal verification covers some of the most subtle and hard to test
parts of an elliptic curve implementation, like carry chains. It would
probably have prevented #20040 and #43786.
This CL imports a 64-bit implementation of the P-521 base field,
replacing the horribly slow and catastrophically variable time big.Int
CurveParams implementation.
The code in p521_fiat64.go is generated reproducibly by fiat-crypto,
building and running the Dockerfile according to the README.
The code in fiat/p521.go is a thin and idiomatic wrapper around the
fiat-crypto code. It includes an Invert method generated with the help
of github.com/mmcloughlin/addchain.
The code in elliptic/p521.go is a line-by-line port of the CurveParams
implementation. Lsh(x, N) was replaced with repeated Add(x, x) calls.
Mul(x, x) was replaced with Square(x). Mod calls were removed, as all
operations are modulo P. Likewise, Add calls to bring values back to
positive were removed. The ScalarMult ladder implementation is now
constant time, copied from p224ScalarMult. Only other notable changes
are adding a p512Point type to keep (x, y, z) together, and making
addJacobian and doubleJacobian methods on that type, with the usual
receiver semantics to save 4 allocations per step.
This amounts to a proof of concept, and is far from a mature elliptic
curve implementation. Here's a non-exhaustive list of things that need
improvement, most of which are pre-existing issues with crypto/elliptic.
Some of these can be fixed without API change, so can't.
- Marshal and Unmarshal still use the slow, variable time big.Int
arithmetic. The Curve interface does not expose field operations, so
we'll have to make our own abstraction.
- Point addition uses an incomplete Jacobian formula, which has variable
time behaviors for points at infinity and equal points. There are
better, complete formulae these days, but I wanted to keep this CL
reviewable against the existing code.
- The scalar multiplication ladder is still heavily variable time. This
is easy to fix and I'll do it in a follow-up CL, but I wanted to keep
this one easier to review.
- Fundamentally, values have to go in and out of big.Int representation
when they pass through the Curve interface, which is both slow and
slightly variable-time.
- There is no scalar field implementation, so crypto/ecdsa ends up using
big.Int for signing.
- Extending this to P-384 would involve either duplicating all P-521
code, or coming up with some lower-level interfaces for the base
field. Even better, generics, which would maybe let us save heap
allocations due to virtual calls.
- The readability and idiomaticity of the autogenerated code can
improve, although we have a clear abstraction and well-enforced
contract, which makes it unlikely we'll have to resort to manually
modifying the code. See mit-plv/fiat-crypto#949.
- We could also have a 32-bit implementation, since it's almost free to
have fiat-crypto generate one.
Anyway, it's definitely better than CurveParams, and definitely faster.
name old time/op new time/op delta
pkg:crypto/elliptic goos:darwin goarch:arm64
ScalarBaseMult/P521-8 4.18ms ± 3% 0.86ms ± 2% -79.50% (p=0.000 n=10+9)
ScalarMult/P521-8 4.17ms ± 2% 0.85ms ± 6% -79.68% (p=0.000 n=10+10)
pkg:crypto/ecdsa goos:darwin goarch:arm64
Sign/P521-8 4.23ms ± 1% 0.94ms ± 0% -77.70% (p=0.000 n=9+8)
Verify/P521-8 8.31ms ± 2% 1.75ms ± 4% -78.99% (p=0.000 n=9+10)
GenerateKey/P521-8 4.15ms ± 2% 0.85ms ± 2% -79.49% (p=0.000 n=10+9)
name old alloc/op new alloc/op delta
pkg:crypto/elliptic goos:darwin goarch:arm64
ScalarBaseMult/P521-8 3.06MB ± 3% 0.00MB ± 0% -99.97% (p=0.000 n=10+10)
ScalarMult/P521-8 3.05MB ± 1% 0.00MB ± 0% -99.97% (p=0.000 n=9+10)
pkg:crypto/ecdsa goos:darwin goarch:arm64
Sign/P521-8 3.03MB ± 0% 0.01MB ± 0% -99.74% (p=0.000 n=10+8)
Verify/P521-8 6.06MB ± 1% 0.00MB ± 0% -99.93% (p=0.000 n=9+9)
GenerateKey/P521-8 3.02MB ± 0% 0.00MB ± 0% -99.96% (p=0.000 n=9+10)
name old allocs/op new allocs/op delta
pkg:crypto/elliptic goos:darwin goarch:arm64
ScalarBaseMult/P521-8 19.8k ± 3% 0.0k ± 0% -99.95% (p=0.000 n=10+10)
ScalarMult/P521-8 19.7k ± 1% 0.0k ± 0% -99.95% (p=0.000 n=9+10)
pkg:crypto/ecdsa goos:darwin goarch:arm64
Sign/P521-8 19.6k ± 0% 0.1k ± 0% -99.63% (p=0.000 n=10+10)
Verify/P521-8 39.2k ± 1% 0.1k ± 0% -99.84% (p=0.000 n=9+10)
GenerateKey/P521-8 19.5k ± 0% 0.0k ± 0% -99.91% (p=0.000 n=9+10)
Updates #40171
Change-Id: Ic898b09a2388382bf51ec007d9a79d72d44efe10
Reviewed-on: https://go-review.googlesource.com/c/go/+/315271
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Trust: Katie Hockman <katie@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
Unfortunately, we can't improve the function signature to refer to
crypto.PrivateKey and crypto.PublicKey, even if they are both
interface{}, because it would break assignments to function types.
Fixes#37845
Change-Id: I627f2ac1e1ba98b128dac5382f9cc2524eaef378
Reviewed-on: https://go-review.googlesource.com/c/go/+/224157
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
steals idea from CL 312093
further investigation revealed additional duplicate
slots (equivalent, but not equal), so delete those too.
Rearranged Func.Names to be addresses of slots,
create canonical addresses so that split slots
(which use those addresses to refer to their parent,
and split slots can be further split)
will preserve "equivalent slots are equal".
Removes duplicates, improves metrics for "args at entry".
Change-Id: I5bbdcb50bd33655abcab3d27ad8cdce25499faaf
Reviewed-on: https://go-review.googlesource.com/c/go/+/312292
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This change upgrades the vendored pprof to pick up the fix for a
serious issue that made the source view in browser mode blank
(tracked upstream as google/pprof#621).
I also had to patch pprof.go, since one of the upstream commit we
included introduced a breaking change in the file interface (the Base
method is now called ObjAddr and has a different signature).
I've manually verified that the upgrade fixes the aforementioned
issues with the source view.
Fixes#45786
Change-Id: I00659ae539a2ad603758e1f06572374d483b9ddc
Reviewed-on: https://go-review.googlesource.com/c/go/+/318049
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Before the CL 288297 all Go process handles had to be made
non-inheritable - otherwise they would escape into the child process.
But now this is not necessary.
This CL stops changing inheritance flag of stdint, stdout and stderr
handles.
Fixes#44876
Change-Id: Ib8fcf8066c30282293d96c34486b01b4c04f7116
Reviewed-on: https://go-review.googlesource.com/c/go/+/316269
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
We now have a (well, two, depending on AES hardware support) universal
cipher suite preference order, based on their security and performance.
Peer and application lists are now treated as filters (and AES hardware
support hints) that are applied to this universal order.
This removes a complex and nuanced decision from the application's
responsibilities, one which we are better equipped to make and which
applications usually don't need to have an opinion about. It also lets
us worry less about what suites we support or enable, because we can be
confident that bad ones won't be selected over good ones.
This also moves 3DES suites to InsecureCipherSuites(), even if they are
not disabled by default. Just because we can keep them as a last resort
it doesn't mean they are secure. Thankfully we had not promised that
Insecure means disabled by default.
Notable test changes:
- TestCipherSuiteCertPreferenceECDSA was testing that we'd pick the
right certificate regardless of CipherSuite ordering, which is now
completely ignored, as tested by TestCipherSuitePreference. Removed.
- The openssl command of TestHandshakeServerExportKeyingMaterial was
broken for TLS 1.0 in CL 262857, but its golden file was not
regenerated, so the test kept passing. It now broke because the
selected suite from the ones in the golden file changed.
- In TestAESCipherReordering, "server strongly prefers AES-GCM" is
removed because there is no way for a server to express a strong
preference anymore; "client prefers AES-GCM and AES-CBC over ChaCha"
switched to ChaCha20 when the server lacks AES hardware; and finally
"client supports multiple AES-GCM" changed to always prefer AES-128
per the universal preference list.
* this is going back on an explicit decision from CL 262857, and
while that client order is weird and does suggest a strong dislike
for ChaCha20, we have a strong dislike for software AES, so it
didn't feel worth making the logic more complex
- All Client-* golden files had to be regenerated because the
ClientHello cipher suites have changed.
(Even when Config.CipherSuites was limited to one suite, the TLS 1.3
default order changed.)
Fixes#45430Fixes#41476 (as 3DES is now always the last resort)
Change-Id: If5f5d356c0f8d1f1c7542fb06644a478d6bad1e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314609
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
These operations (BT{S,R,C}{Q,L}modify) are quite a bit slower than
other ways of doing the same thing.
Without the BTxmodify operations, there are two fallback ways the compiler
performs these operations: AND/OR/XOR operations directly on memory, or
load-BTx-write sequences. The compiler kinda chooses one arbitrarily
depending on rewrite rule application order. Currently, it uses
load-BTx-write for the Const benchmarks and AND/OR/XOR directly to memory
for the non-Const benchmarks. TBD, someone might investigate which of
the two fallback strategies is really better. For now, they are both
better than BTx ops.
name old time/op new time/op delta
BitSet-8 1.09µs ± 2% 0.64µs ± 5% -41.60% (p=0.000 n=9+10)
BitClear-8 1.15µs ± 3% 0.68µs ± 6% -41.00% (p=0.000 n=10+10)
BitToggle-8 1.18µs ± 4% 0.73µs ± 2% -38.36% (p=0.000 n=10+8)
BitSetConst-8 37.0ns ± 7% 25.8ns ± 2% -30.24% (p=0.000 n=10+10)
BitClearConst-8 30.7ns ± 2% 25.0ns ±12% -18.46% (p=0.000 n=10+10)
BitToggleConst-8 36.9ns ± 1% 23.8ns ± 3% -35.46% (p=0.000 n=9+10)
Fixes#45790
Update #45242
Change-Id: Ie33a72dc139f261af82db15d446cd0855afb4e59
Reviewed-on: https://go-review.googlesource.com/c/go/+/318149
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ben Shi <powerman1st@163.com>
We can consolidate MOVB load handling with other MOV* loads. Only
Optab.Size bytes are copied from the slice returned by asmout. Thus,
we can an unconditionally append an extsb operation to the slice
modified by asmout. This extra instruction will only be copied into
the final instruction stream if Optab.Size is 4 bytes larger, as is
the case with MOVB loads.
This removes three extra special cases when loading a signed
byte.
Change-Id: I71f5324551a06a2c3fa28177109aafbe27f3e4cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/314849
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Carlos Eduardo Seo <carlos.seo@linaro.org>
CL 276272 accidentally skipped everything in TestStdlib while trying to
skip nested submodules of std and cmd.
For now, narrow the skip to just the problematic submodule rather than
trying to generalize. We can re-evaluate if it becomes a pattern to
vendor submodules in this way.
Fixes#46027
Change-Id: Ib355ff80dfbf17c3cf37d128a2f48d4216305267
Reviewed-on: https://go-review.googlesource.com/c/go/+/317869
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>
Our workaround to get and set types.Info._Inferred makes it harder to
experiment with the new APIs in x/tools.
Instead, just make a copy of the types.Info struct, so that the Inferred
field is accessible when the typeparams build tag is set.
This is a trivially safe change: the only change when not building with
-tags=typeparams is that types.Info._Inferred is removed, and accessing
inferred type information goes through an additional layer of
indirection.
For #46003
Change-Id: I38f2bbb2c80aed28be31d0fe762ccead970476ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/317549
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>
Windows syscall functions (e.g. syscall.Syscall9) are defined as
cgo_unsafe_args (because it takes the address of one argument and
use that to access all arguments) which makes them ABI0. In some
case we may need ABI wrappers for them. Because those functions
have a large number of arguments, the wrapper can take a
non-trivial amount of stack frame, causing nosplit overflow when
inlining is disabled. The overflow call chain involves
deferreturn.
This CL changes a deferred call to unlockOSThread to a direct
call. If the syscall functions panics, it is likely a fatal error
anyway.
Fixes#45698.
Change-Id: I280be826644de1205f9c8f5efaa4ec5e1b4eebc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/316650
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The Darwin linker does not like text sections that are larger
than the jump limit (even if we already inserted trampolines).
Split the text section to multiple smaller sections.
Now external linking very large binaries works on Darwin/ARM64.
Updates #40492.
Change-Id: I584f1ec673170c5e4d2dc1e00c701964d6f14333
Reviewed-on: https://go-review.googlesource.com/c/go/+/316050
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
During the TLS handshake if the server doesn't support any of the
application protocols requested by the client, send the
no_application_protocol alert and abort the handshake on the server
side. This enforces the requirements of RFC 7301.
Change-Id: Iced2bb5c6efc607497de1c40ee3de9c2b393fa5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/289209
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: Filippo Valsorda <filippo@golang.org>
I found a performance regression between the runtime.Hash
benchmarks when comparing Go 1.16 to latest on ppc64le. This
was due to the addition of Mul64 to runtime/internal/math
with the comments that this should be treated as an intrinsic
on platforms where available. However this is was not being
intrinsified on ppc64le because the code in ssagen/ssa.go didn't
correctly specify ppc64le. It had the argument for ArchPPC64
but should have also included ArchPPC64LE.
Treating Mul64 as an intrinsic shows this improvement, and these
results are better than Go 1.16:
Hash5 27.0ns ± 0% 14.0ns ± 0% -48.1
Hash16 26.6ns ± 0% 14.0ns ± 0% -47.3
Hash64 50.7ns ± 0% 17.9ns ± 0% -64.6
Hash1024 500ns ± 0% 99ns ± 0% -80.1
Hash65536 30.6µs ± 0% 4.0µs ± 0% -86
Many of the Map related benchmarks in the runtime package also showed
improvement once Mul64 is intrinsified.
Change-Id: I3b5ce637b1620348d81a30cfc359c97ab63aae0f
Reviewed-on: https://go-review.googlesource.com/c/go/+/317303
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Paul Murphy <murp@ibm.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Replaces the encoding/asn1 certificate parser with a
x/crypto/cryptobyte based parser. This provides a significant increase
in performance, mostly due to a reduction of lots of small allocs,
as well as almost entirely removing reflection.
Since this is a rather large rewrite only the certificate parser is
replaced, leaving the parsers for CSRs, CRLs, etc for follow-up work.
Since some of the functions that the other parsers use are replaced
with cryptobyte versions, they still get a not insignificant performance
boost.
name old time/op new time/op delta
ParseCertificate/ecdsa_leaf-8 44.6µs ± 9% 12.7µs ± 4% -71.58% (p=0.000 n=20+18)
ParseCertificate/rsa_leaf-8 46.4µs ± 4% 13.2µs ± 2% -71.49% (p=0.000 n=18+19)
name old allocs/op new allocs/op delta
ParseCertificate/ecdsa_leaf-8 501 ± 0% 164 ± 0% -67.27% (p=0.000 n=20+20)
ParseCertificate/rsa_leaf-8 545 ± 0% 182 ± 0% -66.61% (p=0.000 n=20+20)
Fixes#21118Fixes#44237
Change-Id: Id653f6ae5e405c3cbf0c5c48abb30aa831e30107
Reviewed-on: https://go-review.googlesource.com/c/go/+/274234
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>
CL 317273 accidentally grouped a fix for bufio, bytes, strings
packages into a single entry, but they should be separate ones.
Fix that, and document these negative rune handling fixes.
The list of fixed functions in package unicode was computed by
taking the functions covered by the new TestNegativeRunes test,
and including those that fail when tested with Go 1.16.3.
For #44513.
Updates #43254.
Change-Id: I6f387327f83ae52543526dbdcdd0bb5775c678bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/317469
Reviewed-by: David Benjamin <davidben@google.com>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Alexander Rakoczy <alex@golang.org>
The proposal as accepted in #34652 named the bit SkipFuncCheck.
It was renamed to DeferFuncCheck during the code review on a suggestion by Rob,
along with a comment to “defer type checking functions until template is executed,”
but this description is not accurate: the package has never type-checked functions,
only verified their existence. And the effect of the bit in this package is to eliminate
this check entirely, not to defer it to some later time.
I was writing code using this new bit and was very confused about when the
"type checking" was being deferred to and how to stop that entirely,
since in my use case I wanted no checks at all. What I wanted is what the bit does,
it just wasn't named accurately.
Rename back to SkipFuncCheck.
Change-Id: I8e62099c8a904ed04521eb5b86155290f6d5b12f
Reviewed-on: https://go-review.googlesource.com/c/go/+/317269
Trust: Russ Cox <rsc@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
This disables the "testing names" for method names and
trailing input types passed to closure/interface/other calls.
The logic using the names remains, so that editing the change
to enable local testing is not too hard.
Also fixes broken build tag in reflect/abi_test.go
Updates #44816.
Change-Id: I3d222d2473c98d04ab6f1122ede9fea70c994af1
Reviewed-on: https://go-review.googlesource.com/c/go/+/300150
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When parsing type parameters, an empty type instantiation was parsed as
an IndexExpr with nil Index. This should be considered a breaking change
to parsing: ast.Walk previously assumed that Index was non-nil.
Back out the nil check in ast.Walk, and for now pack an empty argument
list as a non-nil ListExpr with nil Elems.
Alternatives considered:
- Parsing the entire index expression as a BadExpr: this led to
inferior errors while type checking.
- Parsing the Index as a BadExpr: this seems reasonable, but encodes
strictly less information into the AST.
We may want to opt for one of these alternatives in the future, but for
now let's just fix the breaking change.
Change-Id: I93f2b89641692ac014b8ee98bfa031ed3477afb8
Reviewed-on: https://go-review.googlesource.com/c/go/+/315851
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>
This change replaces the crypto/ed25519/internal/edwards25519 package
with code from filippo.io/edwards25519, a significantly faster, safer,
well tested (over 1600 lines of new tests, 99% test coverage), and
better documented (600 lines of new comments) implementation.
Some highlights:
* an unsaturated 51-bit limb field implementation optimized for 64-bit
architectures and math/bits.Mul64 intrinsics
* more efficient variable time scalar multiplication using multi-width
non-adjacent form with a larger lookup table for fixed-base
* a safe math/big.Int-like API for the Scalar, Point, and field.Element
types with fully abstracted reduction invariants
* a test suite including a testing/quick fuzzer that explores edge case
values that would be impossible to hit randomly, and systematic tests
for arguments and receiver aliasing
* point decoding rules that strictly match the original logic of
crypto/ed25519/internal/edwards25519, to avoid consensus issues
* AssemblyPolicy-compliant assembly cores for arm64 and amd64, the
former under 20 lines, and the latter generated by a program based on
github.com/mmcloughlin/avo that can be reviewed line-by-line against
the generic implementation
Intel(R) Core(TM) i5-7400 CPU @ 3.00GHz
name old time/op new time/op delta
KeyGeneration-4 59.5µs ± 1% 26.1µs ± 1% -56.20% (p=0.000 n=10+10)
NewKeyFromSeed-4 59.3µs ± 1% 25.8µs ± 1% -56.48% (p=0.000 n=9+10)
Signing-4 60.4µs ± 1% 31.4µs ± 1% -48.05% (p=0.000 n=10+10)
Verification-4 169µs ± 1% 73µs ± 2% -56.55% (p=0.000 n=10+10)
Apple M1
name old time/op new time/op delta
KeyGeneration-8 35.1µs ± 0% 20.2µs ± 2% -42.46% (p=0.000 n=8+10)
NewKeyFromSeed-8 35.1µs ± 0% 20.0µs ± 1% -42.93% (p=0.000 n=8+9)
Signing-8 36.2µs ± 0% 25.6µs ± 1% -29.25% (p=0.000 n=8+9)
Verification-8 96.1µs ± 0% 57.6µs ± 1% -40.14% (p=0.000 n=10+10)
The code in this CL is a copy of the filippo.io/edwards25519 module at
version v1.0.0-beta.3.0.20210405211453-c6be47d67779 with only the
following functions removed as irrelevant to crypto/ed25519:
- (*Point).BytesMontgomery()
- (*Point).MultByCofactor()
- (*Scalar).Invert()
- (*Point).MultiScalarMult()
- (*Point).VarTimeMultiScalarMult()
This codebase took a long journey outside the standard library before
making its way back here. Its oldest parts started as a faster field
implementation rewrite by George Tankersley almost four years ago,
eventually submitted as CL 71950 but never merged. That code was then
merged into github.com/gtank/ristretto255, which also started as an
internal/edwards25519 fork. There it was worked on by me, George, and
Henry de Valence as a backend for our Go ristretto255 implementation.
Finally, I extracted the edwards25519 code into a reusable package as
filippo.io/edwards25519.
Now, we're ready for the standard library to become the source of truth
for this code again, while filippo.io/edwards25519 will become a
re-packaged and extended version for external use, since we don't want
to expose unsafe curve operations in x/crypto or the standard library.
Submitted under the Google CLA on behalf of:
- Henry de Valence
https://github.com/gtank/ristretto255/issues/34
- George Tankersley
https://golang.org/cl/71950https://github.com/gtank/ristretto255-private/issues/28
- Luke Champine
https://github.com/FiloSottile/edwards25519/pull/7
- Adrian Hamelink
https://github.com/FiloSottile/edwards25519/pull/12
Changes 32506b5 and 18c803c are trivial and don't require a CLA.
The full history of this code since diverging from internal/edwards25519
is available at https://github.com/FiloSottile/edwards25519, and
summarized below.
+ c6be47d - edwards25519: update TestScalarSetBytesWithClamping <Filippo Valsorda>
+ c882e8e - edwards25519: rewrite amd64 assembly with avo <Filippo Valsorda>
+ 8eb02eb - edwards25519: refactor feMulGeneric and feSquareGeneric <Filippo Valsorda>
+ 8afd860 - edwards25519: remove Go 1.12 compatibility hack <Filippo Valsorda>
+ 1765c13 - edwards25519: don't clobber BP in amd64 assembly <Filippo Valsorda>
+ b73a7c8 - edwards25519: fix ScalarMult when receiver is not the identity (FiloSottile/edwards25519#12) <Adrian Hamelink>
+ 32a46d7 - edwards25519: document why this can't implement X25519 <Filippo Valsorda>
+ c547797 - edwards25519: make SqrtRatio slightly more efficient <Filippo Valsorda>
+ 700f4f4 - edwards25519: panic if an uninitialized Point is used <Filippo Valsorda>
+ d791cf8 - edwards25519: use testing.AllocsPerRun for TestAllocations <Filippo Valsorda>
+ 8cc8037 - edwards25519: smooth a couple test coverage rough edges <Filippo Valsorda>
+ 9063a14 - edwards25519: test that operations cause zero heap allocations <Filippo Valsorda>
+ 6944ac7 - edwards25519: relax the limb schedule slightly <Filippo Valsorda>
+ 21ebdac - edwards25519: rewrite carryPropagate in arm64 assembly <Filippo Valsorda>
+ a260082 - edwards25519: merge carryPropagate[12] <Filippo Valsorda>
+ dbe1792 - edwards25519: add TestScalarSetBytesWithClamping <Filippo Valsorda>
+ c1fe95a - edwards25519: add MultByCofactor <Filippo Valsorda>
+ 132d95c - edwards25519: sprinkle on-curve checks around tests <Filippo Valsorda>
+ ffb3e31 - edwards25519: specify the behavior of Invert(0) and I.BytesMontgomery() <Filippo Valsorda>
+ 9e6a931 - edwards25519: add (*Scalar).MultiplyAdd <lukechampine>
+ 3b045f3 - edwards25519: outline (*Point).Bytes (FiloSottile/edwards25519#6) <Luke Champine>
+ ec6f8a6 - edwards25519: make (*Scalar).SetCanonicalBytes return the receiver <Filippo Valsorda>
+ 77d7b31 - edwards25519: add (*Point).BytesMontgomery <Filippo Valsorda>
+ 6e8d645 - edwards25519: implement (*Point).Bytes and (*Point).SetBytes <Filippo Valsorda>
+ 1c833da - edwards25519: clarify ScalarBaseMult docs <Filippo Valsorda>
+ 3a13cf1 - edwards25519: apply gc build tag <Filippo Valsorda>
+ 90c35a7 - edwards25519: hide FieldElement and (*Point).ExtendedCoords <Filippo Valsorda>
+ 498fb1e - edwards25519: replace FillBytes with Bytes, again <Filippo Valsorda>
+ 9c7303a - edwards25519: remove (*Point).Identity and (*Point).Generator <Filippo Valsorda>
+ 2e52ce2 - edwards25519: drop unused (*Scalar).Zero <Filippo Valsorda>
+ 7c14a36 - edwards25519: rename FromBytes to SetBytes <Filippo Valsorda>
+ e3d0e45 - edwards25519: ensure only test files import math/big <Filippo Valsorda>
+ daa2507 - edwards25519: minor doc and string touch-ups <Filippo Valsorda>
+ e8698cd - edwards25519: implement (*Scalar).FromBytesWithClamping <Filippo Valsorda>
+ f28d75a - edwards25519: change constructors <Filippo Valsorda>
+ 36d8598 - edwards25519: test the invariant that Scalars are always reduced <Filippo Valsorda>
+ feed48c - edwards25519: cleanup the FieldElement API <Filippo Valsorda>
+ f6ee187 - edwards25519: make Point opaque <Filippo Valsorda>
+ 176388b - edwards25519: cleanup Scalar API to match ristretto255 <Filippo Valsorda>
+ c5c2e9e - edwards25519: rename ProjP3 to Point and unexport other point types <Filippo Valsorda>
+ 8542076 - edwards25519: add Scalar aliasing test <Filippo Valsorda>
+ 1a86a9c - edwards25519: make Scalar opaque <Filippo Valsorda>
+ 07a7683 - edwards25519: hide some more exposed symbols <Filippo Valsorda>
+ d3569cb - all: flatten the package and make FieldElement opaque <Filippo Valsorda>
+ 6f5f582 - all: expose edwards25519, base, and scalar packages <Filippo Valsorda>
+ 7ab4a68 - all: ensure compatibility with older Go versions <Filippo Valsorda>
+ e9b8baa - internal/radix51: implement (*FieldElement).Mul32 <Filippo Valsorda>
+ eac4de5 - internal/radix51: restructure according to golang.org/wiki/TargetSpecific <Filippo Valsorda>
+ 32506b5 - internal/radix51: fix !amd64 build (lightReduce -> carryPropagate) (gtank/ristretto255#29) <Sunny Aggarwal>
+ d64d989 - internal/scalar: fix FromUniformBytes <Filippo Valsorda>
+ 044bb44 - internal/scalar: address review comments <Filippo Valsorda>
+ 7dba54f - all: apply suggestions from code review <Filippo Valsorda>
+ 94bd1d9 - ristretto255: expose scalar multiplication APIs <Filippo Valsorda>
+ 5bd5476 - internal/edwards25519: fix shadowing of B in TestAddSubNegOnBasePoint <Filippo Valsorda>
+ 66bf647 - internal/scalar: replace FromBytes/IsCanonical with FromUniformBytes/FromCanonicalBytes <Filippo Valsorda>
+ 024f3f7 - internal/edwards25519,internal/scalar: apply some Go style touches <Filippo Valsorda>
+ 5e0c5c6 - internal/scalar: add scalar inversion <Henry de Valence>
+ 74fd625 - internal/ed25519: rearrange VartimeDoubleBaseMul args <Henry de Valence>
+ 81ae7ea - internal/ed25519: add benchmarks for scalar mul <Henry de Valence>
+ 9f1f939 - internal/ed25519: add variable-time multiscalar mul <Henry de Valence>
+ 7a96974 - internal/ed25519: add vartime double-base scmul <Henry de Valence>
+ 2bc256c - internal/ed25519: add precomputed NAF table for basepoint <Henry de Valence>
+ a0f0b96 - internal/ed25519: lower quickcheck size for point ops <Henry de Valence>
+ 2f385a1 - internal/ed25519: implement MultiscalarMul <Henry de Valence>
+ 8ae211b - internal/ed25519: implement BasepointMul <Henry de Valence>
+ 7b4858d - internal/ed25519: extract common test variables <Henry de Valence>
+ 16e7c48 - internal/ed25519: add a basepoint multiple table. <Henry de Valence>
+ 988e521 - internal/ed25519: add constant-time variable-base scmul. <Henry de Valence>
+ b695f6b - internal/ed25519: move basepoint constant & correct it <Henry de Valence>
+ ddd014e - internal/scalar: fix high bit check <Henry de Valence>
+ c88ea89 - internal/scalar: make casts clearer <Henry de Valence>
+ b75f989 - internal/scalar: add invariant checks on Scalar digits <Henry de Valence>
+ 36216ca - internal/scalar: use one scMulAdd for Sub <Henry de Valence>
+ 8bf40f3 - internal/scalar: fix constant-time signed radix 16 implementation <Henry de Valence>
+ e6d9ef6 - Update internal/radix51/fe_test.go <Filippo Valsorda>
+ 3aa63de - Update internal/radix51/fe_test.go <Filippo Valsorda>
+ 3e66ff0 - Update internal/radix51/fe_test.go <Filippo Valsorda>
+ 94e6c15 - internal/ed25519: add TODO note and doc ref <Henry de Valence>
+ 3647548 - internal/ed25519: rename twoD to D2 <Henry de Valence>
+ 1cf853c - internal/ed25519: add lookup tables for scalar mul. <Henry de Valence>
+ 3af304a - internal/radix51: add a conditional swap <Henry de Valence>
+ 4673217 - ristretto255: use multi-model arithmetic <Henry de Valence>
+ cca757a - internal/ed25519: remove single-model code <Henry de Valence>
+ d26e77b - internal/ed25519: add addition for Edwards points <Henry de Valence>
+ e0fbb35 - internal/ed25519: use twoD <Henry de Valence>
+ fd9b37b - internal/ed25519: add tests for multi-model point types. <Henry de Valence>
+ dacabb0 - internal/ed25519: add multi-model point types. <Henry de Valence>
+ dddc72e - internal/scalar: add constant-time signed radix 16 <Henry de Valence>
+ 92cdb35 - internal/scalar: add non-adjacent form <Henry de Valence>
+ d147963 - internal/scalar: don't zero memory that is about to be copied over <George Tankersley>
+ 8da186c - internal/scalar: add scalar field implementation <George Tankersley>
+ f38e583 - internal/radix51: add a "weird" testing/quick generation strategy <Filippo Valsorda>
+ 6454f61 - Move comment inside function <Henry de Valence>
+ 1983365 - implement Add, Sub, Neg for ed25519 and ristretto255 points. <Henry de Valence>
+ 9f25562 - internal/group: rename to internal/edwards25519 <Filippo Valsorda>
+ 48e66d3 - internal/group: restore ScalarMult code <Filippo Valsorda>
+ 0078d66 - internal/radix51: rename lightReduce to carryPropagate and touch up docs <Filippo Valsorda>
+ 05f4107 - internal/radix51: add benchmarks <Filippo Valsorda>
+ fd36334 - internal/radix51: test that operations don't exceed bounds <Filippo Valsorda>
+ 703421d - internal/radix51: make Generate produce random light-reduced elements <Filippo Valsorda>
+ f8d8297 - internal/radix51: simplify lightReduce <Filippo Valsorda>
+ 413120f - internal/radix51: minor tests cleanup <Filippo Valsorda>
+ abc8c5a - internal/radix51: make reduction an invariant and unexport Reduce <Filippo Valsorda>
+ 4fd198d - internal/radix51: actually apply go:noescape <Filippo Valsorda>
+ 18c803c - all: fix typos <Dimitris Apostolou>
+ bbfe059 - internal/radix51: test field encoding roundtrip with fixed vectors <George Tankersley>
+ c428b18 - internal/radix51: rename AppendBytes to Bytes <Filippo Valsorda>
+ c59bc1a - internal/radix51: rewrite FromBytes and AppendBytes with encoding/binary <Filippo Valsorda>
+ 57c0cd5 - internal/radix51: add docs and some light readability refactors <Filippo Valsorda>
+ cb1b734 - internal/radix51: remove unused (and a bit broken) SetInt <Filippo Valsorda>
+ beb8abd - internal/radix51: refactor ToBig and FromBig <Filippo Valsorda>
+ 87c0a53 - internal/radix51: replace ToBytes with AppendBytes <Filippo Valsorda>
+ b7e1e45 - internal/radix51: fix aliasing bug in CondNeg (gtank/ristretto255#21) <George Tankersley>
+ ed3748d - internal/radix51: actually, uhm, check the result of TestAliasing <Filippo Valsorda>
+ ec0e293 - radix51: change API of FromBytes and ToBytes to use slices <George Tankersley>
+ 29f6815 - internal/radix51: test all combinations of argument and receiver aliasing <Filippo Valsorda>
+ cd53d90 - internal/radix51: add property-based tests that multiplication distributes over addition <Henry de Valence>
+ c3bc45f - radix51: use go1.12 intrinsics for 128-bit multiplications <George Tankersley>
+ 7e7043e - internal/radix51: define a mask64Bits constant <Filippo Valsorda>
+ 4fdd06d - internal/group: set Z to 1, not 0 in FromAffine <Filippo Valsorda>
+ ffa7be7 - internal/group: fix typo <Filippo Valsorda>
+ 1f452ac - internal/group: derive twoD from D <Filippo Valsorda>
+ 2424c78 - internal/radix51: add MinusOne <Filippo Valsorda>
+ 76978fc - internal/group: make conversion APIs caller-allocated <Filippo Valsorda>
+ d17d202 - internal/group: rewrite DoubleZ1 because stack is cheaper than mental state <Filippo Valsorda>
+ 72b97c1 - internal: make all APIs chainable <Filippo Valsorda>
+ 993d979 - internal/radix51: make all APIs not consider the receiver an input <Filippo Valsorda>
+ b2a1d7d - all: refactor field API to be methods based <Filippo Valsorda>
+ cdf9b90 - internal/radix51: add constant time field operations <Filippo Valsorda>
+ e490a48 - internal/radix51: remove FeEqual <Filippo Valsorda>
+ 2de114c - internal/radix51: remove FeCSwap <Filippo Valsorda>
+ 08b80c1 - make things more generally presentable <George Tankersley>
+ 2178536 - Cache the field representation of d <George Tankersley>
+ 4135059 - Remove 32-bit code and update license. <George Tankersley>
+ 5d95cb3 - Use Bits() for FeToBig. <George Tankersley>
+ 146e33c - Implement ScalarMult using Montgomery pattern and dedicated extended-coordinates doubling. This will be slow. <George Tankersley>
+ 12a673a - use faster FeFromBig & a horrible assortment of other random changes <George Tankersley>
+ 901f40c - group logic WIP <George Tankersley>
+ a9c89cd - add equality for field elements <George Tankersley>
+ 214873b - Add radix51 FieldElement implementation <George Tankersley>
+ 8fd5cae - Implement an elliptic.Curve for ed25519 <George Tankersley>
Change-Id: Ifbcdd13e8b6304f9906c0ef2b73f1fdc493a7dfa
Co-authored-by: George Tankersley <george.tankersley@gmail.com>
Co-authored-by: Henry de Valence <hdevalence@hdevalence.ca>
Reviewed-on: https://go-review.googlesource.com/c/go/+/276272
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
Trust: Katie Hockman <katie@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
If no source argument is provided, test testdata/manual.go2
instead.
Remove testdata/check/tmp/go2 in favor of testdata/manual.go2.
These changes affect testing only.
Change-Id: I49aba4d8fc4cc5964911e38c55b4c5d013710aeb
Reviewed-on: https://go-review.googlesource.com/c/go/+/315769
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The Go 1.17 freeze has begun. This is a time to update all
golang.org/x/... module versions that contribute packages to the std
and cmd modules in the standard library to latest master versions.
updatestd --branch master --goroot=$HOME/development/goroot
> go version
go version devel go1.17-4c9791299d Wed May 5 09:00:06 2021 +0000 linux/amd64
> go env GOROOT
/home/rakoczy/development/goroot
> go version -m /home/rakoczy/go/bin/bundle
/home/rakoczy/go/bin/bundle: devel +c584f42dcf Tue Feb 23 18:39:53 2021 +0000
path golang.org/x/tools/cmd/bundle
mod golang.org/x/tools v0.1.0 h1:po9/4sTYwZU9lPhi1tOrb4hCv3qrhiQ77LZfGa2OjwY=
dep golang.org/x/mod v0.3.0 h1:RM4zey1++hCTbCVQfnWeKs9/IEsaBLA8vTkd0WVtmH4=
dep golang.org/x/sys v0.0.0-20210119212857-b64e53b001e4 h1:myAQVi0cGEoqQVR5POX+8RR2mrocKqNN1hmeMqhX27k=
dep golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
skipping github.com/chzyer/logex (out of scope, it's not a golang.org/x dependency)
skipping github.com/chzyer/readline (out of scope, it's not a golang.org/x dependency)
skipping github.com/chzyer/test (out of scope, it's not a golang.org/x dependency)
skipping github.com/google/pprof (out of scope, it's not a golang.org/x dependency)
skipping github.com/ianlancetaylor/demangle (out of scope, it's not a golang.org/x dependency)
skipping github.com/yuin/goldmark (out of scope, it's not a golang.org/x dependency)
skipping rsc.io/pdf (out of scope, it's not a golang.org/x dependency)
updating module cmd in /home/rakoczy/development/goroot/src/cmd
> go mod edit -go=1.17
> go get -d golang.org/x/arch@cbf565b21d1e6f86b3114f28f516032b201c97fa golang.org/x/crypto@e9a32991a82ef02a1e74f495dcc0785239782bfe golang.org/x/mod@67f1c1edc27ada9b0cffe84ccdd4db2d4ff56edf golang.org/x/net@0287a6fb4125c2b83c66560a2677a4ee69a13903 golang.org/x/sync@036812b2e83c0ddf193dd5a34e034151da389d09 golang.org/x/sys@0981d6026fa6241c75c6949829b5bd7a2574ad55 golang.org/x/term@a79de5458b56c188f4fc267a58014ac25fec956a golang.org/x/text@5c7c50ebbd4f5b0d53b9b2fcdbeb92ffb732a06e golang.org/x/tools@7cab0ef2e9a592f6a73e7a1969ba89d38515e143 golang.org/x/xerrors@5ec99f83aff198f5fbd629d6c8d8eb38a04218ca
go: downloading golang.org/x/mod v0.4.3-0.20210504181020-67f1c1edc27a
go: downloading golang.org/x/crypto v0.0.0-20210503195802-e9a32991a82e
go: downloading golang.org/x/net v0.0.0-20210505024714-0287a6fb4125
go: downloading golang.org/x/sys v0.0.0-20210503173754-0981d6026fa6
go: downloading golang.org/x/text v0.3.7-0.20210503195748-5c7c50ebbd4f
go: downloading golang.org/x/tools v0.1.1-0.20210505014545-7cab0ef2e9a5
go get: upgraded golang.org/x/net v0.0.0-20210405180319-a5a99cb37ef4 => v0.0.0-20210505024714-0287a6fb4125
go get: upgraded golang.org/x/sys v0.0.0-20210423082822-04245dca01da => v0.0.0-20210503173754-0981d6026fa6
go get: upgraded golang.org/x/text v0.3.3 => v0.3.7-0.20210503195748-5c7c50ebbd4f
go get: upgraded golang.org/x/tools v0.1.1-0.20210503200558-19b1717ea5eb => v0.1.1-0.20210505014545-7cab0ef2e9a5
> go mod tidy
> go mod vendor
updating module std in /home/rakoczy/development/goroot/src
> go mod edit -go=1.17
> go get -d golang.org/x/crypto@e9a32991a82ef02a1e74f495dcc0785239782bfe golang.org/x/net@0287a6fb4125c2b83c66560a2677a4ee69a13903 golang.org/x/sys@0981d6026fa6241c75c6949829b5bd7a2574ad55 golang.org/x/term@a79de5458b56c188f4fc267a58014ac25fec956a golang.org/x/text@5c7c50ebbd4f5b0d53b9b2fcdbeb92ffb732a06e golang.org/x/tools@7cab0ef2e9a592f6a73e7a1969ba89d38515e143
go get: upgraded golang.org/x/net v0.0.0-20210503060351-7fd8e65b6420 => v0.0.0-20210505024714-0287a6fb4125
go get: upgraded golang.org/x/sys v0.0.0-20210423082822-04245dca01da => v0.0.0-20210503173754-0981d6026fa6
go get: upgraded golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1 => v0.0.0-20210503060354-a79de5458b56
go get: upgraded golang.org/x/tools v0.0.0-20180917221912-90fa682c2a6e => v0.1.1-0.20210505014545-7cab0ef2e9a5
> go mod tidy
> go mod vendor
updating bundles in /home/rakoczy/development/goroot/src
> go generate -run=bundle std cmd
For #36905
Change-Id: Ie145bba93125f0b4212df94216e05ec08c4fe534
Reviewed-on: https://go-review.googlesource.com/c/go/+/315831
Trust: Alexander Rakoczy <alex@golang.org>
Run-TryBot: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The code that created DWARF debug var locations for input parameters
in the non-optimized case for regabi was not doing the right thing for
degenerate functions with infinite loops. Detect these cases and don't
try to emit the normal location data.
Fixes#45948.
Change-Id: I2717fc4bac2e03d5d850a6ec8a09ed05fed0c896
Reviewed-on: https://go-review.googlesource.com/c/go/+/316752
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
If the go command is executed on Linux in a deleted directory,
it fails. This behavior is reasonable for commands which depend on
the CWD, but it's unexpected for commands like `go version`.
This change delays initialization of a global CWD variable.
Fixed#34499
Change-Id: I7302fb84a3b7f5f149a123d277abd5b9b5bc95b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/268261
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
In a lazy module, it is important that tidyRoots does not add any new
roots because the dependencies of non-roots are pruned out.
In an eager module, that property is not important (and does not hold
in general) because no dependencies are ever pruned out.
Fixes#45952
Change-Id: I5c95b5696b7112b9219e38af04e0dece7fb6e202
Reviewed-on: https://go-review.googlesource.com/c/go/+/316754
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Currently if a signal lands on a non-Go thread that's handled by the Go
handler, Go will emit a message. However, unlike everywhere else in the
runtime, Go will not abort the process after, and the signal handler
will try to continue executing.
This leads to cascading failures and possibly even memory corruption.
For #45638.
Change-Id: I546f4e82f339d555bed295528d819ac883b92bc6
Reviewed-on: https://go-review.googlesource.com/c/go/+/316809
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When the expand_calls phase in the SSA backend lowers prolog OpArg
values into OpArgIntReg/OpArgFloatReg values, we don't always record
the assocation between the new lowered value and the parameter name.
This patch handles the simple case where a given parameter fits into
exactly one register; in this scenario it makes sense to manufacture a
new pseudo-slot for the value that points to the param, and install
the slot/value mapping in the NamedValues table for the function. More
work will be needed to deal with params that span multiple registers;
that will need to be addressed in a subsequent patch.
This change improves the parameter error rate "optargorder" benchmark
by about 7-8% (when run on the optargorder binary).
Updates #45945.
Change-Id: Ic9adbe20b6f91145d49651348818f0f5cba92b18
Reviewed-on: https://go-review.googlesource.com/c/go/+/316890
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This test deletes the running executable file, which is not safe
on Plan 9. The test was working by accident prior to commit 02ab8d1,
which must have changed the page reference ordering just enough to
cause a new demand page-in after deletion of the file.
Fixes#45941
Change-Id: Ic13d8032c21cee603e3afc3c5c4da6093fc37bf4
Reviewed-on: https://go-review.googlesource.com/c/go/+/316829
Reviewed-by: David du Colombier <0intro@gmail.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: David du Colombier <0intro@gmail.com>
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
All build environment validation sets Error except for the
GOEXPERIMENT parser, which panics. Change it to also set Error so that
a bad GOEXPERIMENT doesn't cause everything that imports
internal/buildcfg to panic on init.
Change-Id: Ie9a506ef0978ecb410f2dcd784638f2167354175
Reviewed-on: https://go-review.googlesource.com/c/go/+/310970
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TestSignalTrace can take a bit longer to run on some
ppc64{,le} machines. I was only able to reproduce the
timeout reliably on a POWER8/ppc64le ubuntu 16.04 host.
Bump the timeout to 5 seconds. This should be more than
sufficient for a test which occasionally takes a bit
longer to run on these builders.
Fixes#45773
Change-Id: I4177bb986561f714aabfa5b0ca44b1c90b1cd94f
Reviewed-on: https://go-review.googlesource.com/c/go/+/315049
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
If we're testing through dist, we're testing the implementation of Go,
so we're interested in any package failing with potential runtime
issues. In these cases, we'd like to have as much relevant detail as
possible, but currently runtime stack frames and goroutines are
suppressed due to the default GOTRACEBACK setting.
So, try to set GOTRACEBACK to system if it's unset. Check if it's unset
first so we don't override the user asking for a lower or higher level.
This change was brought up in the context of #45916, since there's an
apparent deadlock (or something!) in the runtime that appears when
running other code, but it's difficult to see exactly where it's
blocked. However, this change is very generally useful.
This change also runs scripted tests with GOTRACEBACK=system, upgrading
from GOTRACEBACK=all. Often, script tests can trigger failures deep in
the runtime in interesting ways because they start many individual Go
processes, so being able to identify points of interest in the runtime
is quite useful.
For #45916.
Change-Id: I3d50658d0d0090fb4c9182b87200d266c7f8f915
Reviewed-on: https://go-review.googlesource.com/c/go/+/316469
Trust: Michael Knyszek <mknyszek@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Since x/tools is now lazy, this removes a significant fraction of
otherwise-irrelevant dependencies from the go.sum file.
The remaining extraneous go.sum lines come from the dependency on
github.com/google/pprof. Since that module is outside of the Go
project proper, I do not plan to submit a PR to make it lazy until
after the Go 1.17 release.
For #36460
Updates #36905
Change-Id: I214492cf931fca797817124ecdcbccd4ebb7505b
Reviewed-on: https://go-review.googlesource.com/c/go/+/316452
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
The outdated comment in modfile.go was missed in CL 315409.
Upon a closer look at the test case in mod_go_version_vendor.txt, it
is almost completely redundant with the new test in
mod_vendor_goversion.txt. Make it completely redundant and remove it.
Updates #36876
Change-Id: Ibcd1f6b426460aaafbd6dc0be93078547904572b
Reviewed-on: https://go-review.googlesource.com/c/go/+/316209
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Because x/crypto is now lazy, this removes the remaining checksums for
older-than-selected dependencies from src/go.sum.
It also removes a significant fraction of the irrelevant checksums
from src/cmd/go.sum.
For #36460
Updates #36905
Change-Id: I33af5fc638aa1d1c66df3a1d86542912e95a7f50
Reviewed-on: https://go-review.googlesource.com/c/go/+/316451
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Even though x/mod is now lazy, this has no immediate effect on the
size of cmd/go.sum: all of the existing dependencies are still pulled
in via the dependency on x/tools, which is itself not yet lazy (that's
CL 315570).
For #36460
Updates #36905
Change-Id: I7bce5fe2596a2d71e4df08f5d5f4cb8dcdb8512c
Reviewed-on: https://go-review.googlesource.com/c/go/+/316489
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
We were already setting GIT_SSH_COMMAND (if unset) to explicitly
include 'ControlMaster=no' in order to disable connection pooling.
Now we also set 'BatchMode=yes' to suppress password prompts for
password-protected keys.
While we're here, we also set GCM_INTERACTIVE=never to suppress
similar prompts from the Git Credential Manager for Windows.
Fixes#44904
Change-Id: Iebb050079ff7dd54d5b944c459ae212e9e6f2579
Reviewed-on: https://go-review.googlesource.com/c/go/+/300157
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Lots of constant SSA values we put in the entry block so that
CSE can easily combine them. With -N, however, we don't run CSE, so
putting values in the entry block only serves to extend their lifetime
for no benefit.
Fixes#45897. The number of live SSA values per block goes from >5K to 22.
Memory use goes from ~3GB to ~400MB.
Change-Id: I620b423611790a900e0d4cd270eac5dbdddf2a2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/316369
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This is part of getting debugging into good shape
with the register ABI. (This may generate a backport
for 1.16, there was some regression there as well.)
This is not necessarily fully-baked yet; my goal is to
make it work "well enough" for actual debugging, then
revisit the metrics, which are currently ignorant
of registers used for passing parameters (currently,
rejects them as a valid option).
Updates #40724.
Change-Id: Ib649adf39f947b7b54895c5bf181cf48ca4d38a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/311689
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The functions SwapPointer and CompareAndSwapPointer can be used to
interact with unsafe.Pointer, however generally it is prefered to work
with Value, due to its safer interface. As such, they have been added
along with glue logic to maintain invariants Value guarantees.
To meet these guarantees, the current implementation duplicates much of
the Store function. Some of this is due to inexperience with concurrency
and desire for correctness, but the lack of generic programming
functionality does not help.
Fixes#39351
Change-Id: I1aa394b1e70944736ac1e19de49fe861e1e46fba
Reviewed-on: https://go-review.googlesource.com/c/go/+/241678
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Since we have int8 to int64 min max and uint8 to uint64 max constants,
we should probably have some for the word size types too. This change
also adds tests to validate the correctness of all integer limit
values.
Fixes#28538
Change-Id: Idd25782e98d16c2abedf39959b7b66e9c4c0c98b
Reviewed-on: https://go-review.googlesource.com/c/go/+/247058
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Robert Griesemer <gri@golang.org>
These new methods provide support for cases where performance is a
primary concern. For example, copying files from an existing zip to a
new zip without incurring the decompression and compression overhead.
Using an optimized, external compression method and writing the output
to a zip archive. And compressing file contents in parallel and then
sequentially writing the compressed bytes to a zip archive.
TestWriterCopy is copied verbatim from https://github.com/rsc/zipmergeFixes#34974
Change-Id: Iade5bc245ba34cdbb86364bf59f79f38bb9e2eb6
Reviewed-on: https://go-review.googlesource.com/c/go/+/312310
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Carlos Amedee <carlos@golang.org>
At this time, the golang.org/s/release process arranges such that the
api/go1.n.txt file is created when a Go 1.N Beta 1 release is being cut.
The API check is currently configured so that tests don't fail visibly
even if api/go1.n.txt becomes a subset of the actual API additions in
the upcoming Go 1.N release as long as 'go version' has "devel" in it.
The first time that 'go version' output drops the "devel" substring
during testing is after the release-branch.go1.N branch is created
as part of the process to cut a Go 1.N Release Candidate 1 release.
The month or so between Beta 1 and RC 1 is well into the freeze and
deliberate API changes are rare and very intentional. There seems to
be agreement that it's healthy to make the API check stricter during
that time period. Doing so will ensure that api/go1.n.txt cannot get
stale after creation without anyone noticing, and may catch CLs that
don't have the intended diff on the API.
This CL changes behavior to be simple and clear: from the moment
an api/go1.n.txt file corresponding to the current Go version in
development is added to the tree, silent API additions stop being
permitted.
This CL also moves the magical "override the value of -allow_new flag
if runtime.Version() contains 'devel' string" behavior from cmd/api
command to the run.go script that calls it, making the CLI of cmd/api
itself less surprising.
Fixes#43956.
Change-Id: I89468207573f7ccdbc9f12625dcdd3ef2bcf8f10
Reviewed-on: https://go-review.googlesource.com/c/go/+/315350
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
As a side effect, this also upgrades x/sys to the version currently
required by the latest x/net.
Because x/net is now lazy, it no longer requires checksums for
older-than-selected versions of x/sys, x/term, and x/text.
For #36460
Updates #36905
Change-Id: I242815e202aa7d482fc3983a6717bece10ea8111
Reviewed-on: https://go-review.googlesource.com/c/go/+/316251
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Even though x/term is now lazy, this has no overall effect (yet) on
the contents of cmd/go.sum, because the dependency that would be
pruned out (an old version of x/sys) is still transitively required
through x/crypto, x/sys, and/or x/tools.
Once those modules are also lazy (CL 316109, CL 316111, and CL 315570
respectively), the extra go.sum entries for x/sys will drop out.
For #36460
Updates #36905
Change-Id: I79e715328f7c417ea20ae8fe4f8e0e3eb71ee6c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/316250
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Assignment between input parameters causes them to have more than
one "Name", and running this backwards from names to values can end
up confusing (conflating) parameter spill slots.
Around 105a6e9518, this cases a stack overflow running
go test -race encoding/pem
because two slice parameters spill (incorrectly) into the same
stack slots (in the AB?I-defined parameter spill area).
This also tickles a failure in cue, which turned out to be
easier to isolate.
Fixes#45851.
Updates #40724.
Change-Id: I39c56815bd6abb652f1ccbe83c47f4f373a125c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/313212
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
If the cleaned path did not match the requested path, ServeMux.Handler
would return a Location header which reflected the hostname in the
request, possibly leading to an incorrect redirect. Instead the
Location header should be relative, like the other cases in
ServeMux.Handler.
Change-Id: I2c220d925e708061bc128f0bdc96cca7a32764d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/313950
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>
When regabi is used sorting by stack offset will not preserve the order
of function arguments. Trust that variables are already ordered
correctly when creating debug_info entries.
Fixes#45720
Change-Id: I1dbdd185975273f70244a23302d34f082347603d
Reviewed-on: https://go-review.googlesource.com/c/go/+/315280
Reviewed-by: Than McIntosh <thanm@google.com>
Trust: Jeremy Faller <jeremy@golang.org>
Fix up a slightly stale comment in the part of ssa generation that
zeros ambiguously live variables: with the advent of the register ABI,
the ir.Func "Dcl" slice is no longer entirely sorted by frame offset,
although this is still the case for the local vars in Dcl.
Change-Id: I633f43d16f0d4e0b444193a6edb6b2aa1154eea7
Reviewed-on: https://go-review.googlesource.com/c/go/+/316309
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This edge can happen when forcegchelper() calls
goparkunlock(&forcegc.lock, ...) while holding the forcegc lock.
goparkunlock() eventually calls park_m(). In park_m(), traceGoPark()
(which leads to (*traceStackTable).put() and acquires the traceStackTab
lock) can be called before the forcegc lock is released.
Fixes#45774
Change-Id: If0fceab596712eb9ec0b9b47326778bc0ff80913
Reviewed-on: https://go-review.googlesource.com/c/go/+/316029
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Carlos Amedee <carlos@golang.org>
Currently we have two code paths of writing the text segment. They
are semantically the same:
- if we split text sections, we write all ".text" sections as
text and the the rest as data.
- if we do not split text sections, we write the first section
as text and the rest as data. The first section is named ".text"
and is the only one in this case.
Unify the code.
Change-Id: Ic639eed625615be3c8a8d41f5b47e901552f587a
Reviewed-on: https://go-review.googlesource.com/c/go/+/316049
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
For ABI0 assembly functions that have Go declarations, generate
traceback argument info and attach it to the assembly functions.
So we can print argument in tracebacks if e.g. assembly function
panics.
Only do this for ABI0 functions, as for ABIInternal assembly
functions it is likely that they never spill arguments to memory.
Change-Id: I7e601ccd9aded5e6af2f02be975bf81ff9948f4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/315870
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Currently, when "..." argument is passed to non-variadic function, the
compiler may skip that check, but continue checking whether the number
of arguments matches the function signature.
That causes the sanity check which was added in CL 255241 trigger.
Instead, we should report an invalid use of "...", which matches the
behavior of new type checker and go/types.
Fixes#45913
Change-Id: Icbb254052cbcd756bbd41f966c2c8e316c44420f
Reviewed-on: https://go-review.googlesource.com/c/go/+/315796
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
When creating programs with large text sections on ppc64le,
trampolines are needed for calls that are too far; however
they are not created if the code is generated such that the TOC
register r2 is initialized and maintained in the code because
then the external linker can create the trampolines. Previously
the function DynlinkingGo was used to determine this but in the
case where plugins are used, this could return true even though
r2 is not valid.
To fix this problem I've added a new function r2Valid which returns
true when the build options indicate that the r2 is
initialized and maintained. Because of the ways that
DynlinkingGo is used I wanted to maintain its previous
behavior.
Fixes#45850
Change-Id: I6d902eba6ad41757aa6474948b79acdbd479cb38
Reviewed-on: https://go-review.googlesource.com/c/go/+/315289
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
A while back in this release the sanitizer tests were enabled
for ppc64le, where previously they were never run. This
uncovered some errors in these tests on ppc64le. One linker
fix was made but there are still bugs in how tsan is made to
work within the code, especially in how signals are enabled
with cgo.
Some attempts were made to make this work but intermittent
failures continue to happen with the Trybots so I am just
going to disable this test for ppc64le within cmd/dist.
Updates #45040
Change-Id: I5392368ccecd4079ef568d0c645c9f7c94016d99
Reviewed-on: https://go-review.googlesource.com/c/go/+/315430
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Zhang <cherryyz@google.com>
Because x/arch is now lazy, this removes the checksum for rsc.io/pdf
from the go.sum file: the requirements of rsc.io/pdf are known not to
be relevant to any package imported within the cmd packages.
For #36460
Updates #36905
Change-Id: I3abb6a8029cd0c9099b592ccb01ca5606c93edec
Reviewed-on: https://go-review.googlesource.com/c/go/+/316110
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Previously calling fmt.Sprintf("%#v", t) on a time.Time value would
yield a result like:
time.Time{wall:0x0, ext:63724924180, loc:(*time.Location)(nil)}
which does not compile when embedded in a Go program, and does not
tell you what value is represented at a glance.
This change adds a GoString method that returns much more legible
output:
"time.Date(2009, time.February, 5, 5, 0, 57, 12345600, time.UTC)"
which gives you more information about the time.Time and also can be
usefully embedded in a Go program without additional work.
Update Quote() to hex escape non-ASCII characters (copying logic
from strconv), which makes it safer to embed them in the output of
GoString().
Fixes#39034.
Change-Id: Ic985bafe4e556f64e82223c643f65143c9a45c3b
Reviewed-on: https://go-review.googlesource.com/c/go/+/267017
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
Currently, when ABI wrappers are used, we don't use ABI aliases.
One exception is shared linkage. When loading a shared library, if
a symbol has only one ABI, and the name is not mangled, we don't
know what ABI it is, so we have to use ABI aliases.
This CL makes it always mangle ABIInternal function name in shared
linkage, so we know what ABI to choose when loading a shared
library. And we now can fully stop using ABI aliases when ABI
wrappers are used.
Change-Id: Id15d9cd72a59f391f54574710ebba7dc44cb6e23
Reviewed-on: https://go-review.googlesource.com/c/go/+/315869
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This is a port of CL 315169 to go/types. It uses a slightly different
mechanism for evaluating the convertibility error message, to be
consistent with operand.assignableTo.
Change-Id: Iea2e2a9fbb4cf17d472b2b7392786118e079528a
Reviewed-on: https://go-review.googlesource.com/c/go/+/315809
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>
If something "huge" is allocated, and the zeroing is trivial (no pointers
involved) then zero it by chunks in a loop so that preemption can occur,
not all in a single non-preemptible call.
Benchmarking suggests that 256K is the best chunk size.
Updates #42642.
Change-Id: I94015e467eaa098c59870e479d6d83bc88efbfb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/270943
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
In Cl 302071 we changed the compiler to use a different recipe for
selecting the DWARF frame offset for output parameters, to reflect the
fact that registerized output params don't have a stack memory
location on entry to the function. In the process, however, we
switched from using an abbrev pf DW_ABRV_PARAM to an abbrev of
DW_ABRV_AUTO, which means that Delve can't recognize them correctly.
To fix the problem, switch back to picking the correct abbrev entry,
while leaving the new offset recipe intact.
Updates #40724.
Updates #45720.
Change-Id: If721c9255bcd030177806576cde3450563f7a235
Reviewed-on: https://go-review.googlesource.com/c/go/+/315610
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When constructing multi-piece DWARF location expressions for
struct-typed parameters using the register ABI, make sure that the
location expressions generated properly reflect padding between
elements (this is required by debuggers). Example:
type small struct { x uint16 ; y uint8 ; z int32 }
func ABC(p1 int, p2 small, f1 float32) {
...
In the DWARF location expression for "p2" on entry to the routine, we
need pieces for each field, but for debuggers (such as GDB) to work
properly, we also need to describe the padding between elements. Thus
instead of
<rbx> DW_OP_piece 2 <rcx> DW_OP_piece 1 <rdi> DW_OP_piece 4
we need to emit
<rbx> DW_OP_piece 2 <rcx> DW_OP_piece 1 DW_OP_piece 1 <rdi> DW_OP_piece 4
This patch adds a new helper routine in abiutils to compute the
correct padding amounts for a struct type, a unit test for the helper,
and updates the debug generation code to call the helper and insert
apadding "piece" ops in the right spots.
Updates #40724.
Updates #45720.
Change-Id: Ie208bee25776b9eb70642041869e65e4fa65a005
Reviewed-on: https://go-review.googlesource.com/c/go/+/315071
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Revise the code that generates DWARF location expressions for input
parameters to get it to work properly with the new register ABI when
optimization is turned off.
The previously implementation assumed stack locations for all
input+output parameters when -N (disable optimization) was in effect.
In the new implementation, a register-resident input parameter is
given a 2-element location list, the first list element pointing to
the ABI register(s) containing the param, and the second element
pointing to the stack home once it has been spilled.
NB, this change fixes a bunch of the Delve pkg/proc unit tests (maybe
about half of the outstanding failures). Still a good number that need
to be investigated, however.
Updates #40724.
Updates #45720.
Change-Id: I743bbb9af187bcdebeb8e690fdd6db58094ca415
Reviewed-on: https://go-review.googlesource.com/c/go/+/314431
Trust: Than McIntosh <thanm@google.com>
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Include a NOP with the SP in order to disable/bypass vet asmdecl checks
for runtime.mstart_stub on openbsd/386. Without this we get:
runtime/sys_openbsd_386.s:33:1: [386] mstart_stub: use of 32(SP) points beyond argument frame
Change-Id: I834ae3dbceffcb5776481b076ec2afe3700671cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/315789
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
The SSA code for debug variable location analysis (for DWARF) has two
special 'sentinel' values that it uses to handshake with the
debugInfo.GetPC callback when capturing the PC values of debug
variable ranges after prog generatoin: "BlockStart" and "BlockEnd".
"BlockStart" has the expected semantics: it means "the PC value of the
first instruction of block B", but "BlockEnd" does not mean "PC value
of the last instruction of block B", but rather it is implemented as
"the PC value of the last instruction of the function". This causes
confusion when reading the code, and seems to to result in implementation
flaws in the past, leading to incorrect ranges in some cases.
To help with this, add a new sentinel "FuncEnd" (which has the "last
inst in the function" semantics) and change the implementation of
"BlockEnd" to actually mean what its name implies (last inst in
block).
Updates #45720.
Change-Id: Ic3497fb60413e898d2bfe27805c3db56483d12a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/314930
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
The comment for this special case claims:
> There's no directory for import "C" or import "unsafe".
However, there clearly is a directory for "unsafe" in
GOROOT/src/unsafe, and all of our integration tests seem to pass
without this special case. As far as I can tell, it's just confusing.
Also note that the internal/goroot package explicitly considers
package "unsafe" to be in the standard library; see CL 137435.
For #36460
Change-Id: Ib857d18f731a7f3c911c1bd116a34e3a9b3d74a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/315412
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
GODEBUG=lazymod=log causes the go command to log a stack dump whenever
the full module graph is loaded in a lazy module.
GODEBUG=lazymod=strict does the same, but also terminates the command
with a nonzero exit code.
For #36460
Change-Id: Ia5a4c46069044bcc157b285f64c2392990d70bd0
Reviewed-on: https://go-review.googlesource.com/c/go/+/315411
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
This change adds two possible upgrade paths for lazy loading:
1. Run 'go mod tidy -go=1.17'.
2. Starting in a module with no existing 'go' directive,
run any 'go' command that updates the go.mod file.
In the latter case, commands other than 'go mod tidy'
may leave the go.mod file *very* untidy if it had non-trivial
dependencies. (The 'go' invocation will promote all
implicit eager dependencies to explicit lazy ones,
which preserves the original module graph — most of which is
not actually relevant.)
'go mod tidy -go=1.17' can be used to enable lazy loading without
accidentally downgrading existing transitive dependencies.
'go mod tidy -go=1.16' can be used to disable lazy loading and clear
away redundant roots in a single step (if reducing the go version), or
to prune away dependencies of tests-of-external-tests (if increasing
the go version).
'go mod tidy -go=1.15' can be used to add dependencies of
tests-of-external-tests, although there isn't much point to that.
DO NOT MERGE
This change still needs an explicit test and a release note.
Fixes#45094
For #36460
Change-Id: I68f057e39489dfd6a667cd11dc1e320c1ee1aec1
Reviewed-on: https://go-review.googlesource.com/c/go/+/315210
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
This change activates the dormant “lazy loading” codepaths added in CL
265777 and its predecessors. Dependencies of modules that declare 'go
1.17' or higher are loaded lazily, and the dependencies in the go.mod
file maintain additional invariants to support more efficient lazy
loading for downstream dependent modules.
See https://golang.org/design/36460-lazy-module-loading for the
detailed design.
For #36460
Change-Id: Ic12ee7842aef9580357fcf8909d87654fcb2ad12
Reviewed-on: https://go-review.googlesource.com/c/go/+/314634
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
TestManual is used for debugging; in this case we usually want to
see error messages reported rather than checked against ERROR comments
in the provided files. Make this the default. Use the new -verify
flag to verify reported errors against ERROR comments.
With this change we cannot get an error list for the non-manual
tests, but that is usually not useful anyway because there are
usually many errors in those test files. Run those tests manually
instead.
Also, corrected -lang flag synopsys: it applies to all tests, not
just TestManual.
Change-Id: I56e0ea0583840fc3ea150d9ccfc330370b66191c
Reviewed-on: https://go-review.googlesource.com/c/go/+/315729
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Running the TestManual test (for manual debugging) requires
user-provided files as input. Rather than using another flag
(-files) to provide these files, just use the (remaining)
command line arguments.
Change-Id: I9b20d9f1a6a7ce839bbd690c311ce3f0d0a10496
Reviewed-on: https://go-review.googlesource.com/c/go/+/315689
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The Go object file format can change from version to version.
Tools like cmd/objdump and cmd/nm only onderstand the current
version of the object file. Currently, when it encounters an
object built with a different version of the toolchain, it emits
a generic error "unrecognized object file", which is not very
helpful for users. This CL makes it emit a clearer error. Now it
emits
objdump: open go116.o: go object of a different version: go116ld
Change-Id: I063c6078ed1da78f97cea65796779ae093a1a8cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/315609
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
golang.org/cl/284138 introduced a regression: running "gofmt foo" would
silently ignore the file due to its lack of a ".go" extension, whereas
the tool is documented otherwise:
Given a file, it operates on that file; given a directory, it
operates on all .go files in that directory, recursively.
This wasn't caught as there were no tests for these edge cases. gofmt's
own tests are regular Go tests, so it's hard to test it properly without
adding an abstraction layer on top of func main.
Luckily, this kind of test is a great fit for cmd/go's own script tests,
and it just takes a few straightforward lines.
Finally, add the relevant logic back, with documentation to clarify its
intentional purpose.
Fixes#45859.
Change-Id: Ic5bf5937b8f95fcdad2b6933227c8b504ef38a82
Reviewed-on: https://go-review.googlesource.com/c/go/+/315270
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
Trust: Robert Griesemer <gri@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
There's no reason not to, and it'll help me test an upcoming fix
for #43956. The API additions look reasonable to me, and they'll
go through a more comprehensive API audit during the freeze.
Change-Id: I0daa6e978b199d69568f5100fdfc1b4bcfaeaef2
Reviewed-on: https://go-review.googlesource.com/c/go/+/315349
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The original value was rounded too early, which lead to the
surprising behavior that float64(math.SmallestNonzeroFloat64 / 2)
wasn't 0. That is, the exact compile-time computation of
math.SmallestNonzeroFloat64 / 2 resulted in a value that was
rounded up when converting to float64. To address this, added 3
more digits to the mantissa, ending in a 0.
While at it, also slightly increased the precision of MaxFloat64
to end in a 0.
Computed exact values via https://play.golang.org/p/yt4KTpIx_wP.
Added a test to verify expected behavior.
In contrast to the other (irrational) constants, expanding these
extreme values to more digits is unlikely to be important as they
are not going to appear in numeric computations except for tests
verifying their correctness (as is the case here).
Re-enabled a disabled test in go/types and types2.
Updates #44057.
Fixes#44058.
Change-Id: I8f363155e02331354e929beabe993c8d8de75646
Reviewed-on: https://go-review.googlesource.com/c/go/+/315170
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently, for stack objects, the compiler emits metadata that
includes the offset and type descriptor for each object. The type
descriptor symbol has many fields, and it references many other
symbols, e.g. field/element types, equality functions, names.
Observe that what we actually need at runtime is only the GC
metadata that are needed to scan the object, and the GC metadata
are "leaf" symbols (which doesn't reference other symbols). Emit
only the GC data instead. This avoids bringing live the type
descriptor as well as things referenced by it (if it is not
otherwise live).
This reduces binary sizes:
old new
hello (println) 1187776 1133856 (-4.5%)
hello (fmt) 1902448 1844416 (-3.1%)
cmd/compile 22670432 22438576 (-1.0%)
cmd/link 6346272 6225408 (-1.9%)
No significant change in compiler speed.
name old time/op new time/op delta
Template 184ms ± 2% 186ms ± 5% ~ (p=0.905 n=9+10)
Unicode 78.4ms ± 5% 76.3ms ± 3% -2.60% (p=0.009 n=10+10)
GoTypes 1.09s ± 1% 1.08s ± 1% -0.73% (p=0.027 n=10+8)
Compiler 85.6ms ± 3% 84.6ms ± 4% ~ (p=0.143 n=10+10)
SSA 7.23s ± 1% 7.25s ± 1% ~ (p=0.780 n=10+9)
Flate 116ms ± 5% 115ms ± 6% ~ (p=0.912 n=10+10)
GoParser 201ms ± 4% 195ms ± 1% ~ (p=0.089 n=10+10)
Reflect 455ms ± 1% 458ms ± 2% ~ (p=0.050 n=9+9)
Tar 155ms ± 2% 155ms ± 3% ~ (p=0.436 n=10+10)
XML 202ms ± 2% 200ms ± 2% ~ (p=0.053 n=10+9)
Change-Id: I33a7f383d79afba1a482cac6da0cf5b7de9c0ec4
Reviewed-on: https://go-review.googlesource.com/c/go/+/313514
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Add missing version check. Even though this is a new types2 error
we separate between the compiler and the types2 error message: we
have the compiler error message to match the compiler style, and
we have a types2-specific error message to match the types2 style
for these kinds of errors (for now).
Eventually we need to decide which style we like better and clean
this up.
Follow-up on https://golang.org/cl/301650.
Updates #395.
Change-Id: I5b779f345994c66b1f4a4db466466f98b7d3c491
Reviewed-on: https://go-review.googlesource.com/c/go/+/315169
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This change adds four additional metrics to the runtime/metrics package
to fill in a few gaps with runtime.MemStats that were overlooked. The
biggest one is TotalAlloc, which is impossible to find with the
runtime/metrics package, but also add a few others for convenience and
clarity. For instance, the total number of objects allocated and freed
are technically available via allocs-by-size and frees-by-size, but it's
onerous to get them (one needs to sum the sample counts in the
histograms).
The four additional metrics are:
- /gc/heap/allocs:bytes -- total bytes allocated (TotalAlloc)
- /gc/heap/allocs:objects -- total objects allocated (Mallocs - [tiny])
- /gc/heap/frees:bytes -- total bytes frees (TotalAlloc-HeapAlloc)
- /gc/heap/frees:objects -- total objects freed (Frees - [tiny])
This change also updates the descriptions of allocs-by-size and
frees-by-size to be more precise.
Change-Id: Iec8c1797a584491e3484b198f2e7f325b68954a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/312431
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Add a little more detail to the ssa README relating to GOSSAFUNC.
Update the -d=ssa help section to give a little more detail on what
to expect with applying the /debug=X qualifier to a phase.
Change-Id: I7027735f1f2955dbb5b9be36d9a648e8dc655048
Reviewed-on: https://go-review.googlesource.com/c/go/+/315229
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Store the precomputed P-256 basepoint table in source rather than
computing it at runtime, saving ~88kB from the heap. The flip side
is that this increases binary sizes by ~77kB.
Fixes#44992
Change-Id: Ia5421eae87b41522b0d8cecba051cba1d2ed73db
Reviewed-on: https://go-review.googlesource.com/c/go/+/315189
Run-TryBot: Roland Shoemaker <roland@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
This enables a consumer of a CSV to find out the position
of a CSV field without implementing an intermediate buffer.
This is useful to produce good higher level error messages when
the CSV syntax is OK but the field values don't match expectations.
This also changes the existing semantics of the `ParseError.Column`
field to bring it in line with precedent elsewhere in the Go
standard library (notably go/token.Position) - the column is
now 1-based and indicates a byte count rather than a rune count,
and the error position reporting at the end of a last line without
a newline is now fixed.
This change has some impact on performance:
```
name old time/op new time/op delta
Read-8 2.14µs ± 0% 2.15µs ± 0% ~ (p=0.056 n=5+5)
ReadWithFieldsPerRecord-8 2.15µs ± 2% 2.15µs ± 1% ~ (p=0.151 n=5+5)
ReadWithoutFieldsPerRecord-8 2.15µs ± 0% 2.15µs ± 0% +0.37% (p=0.024 n=5+5)
ReadLargeFields-8 3.55µs ± 2% 3.59µs ± 0% ~ (p=0.206 n=5+5)
ReadReuseRecord-8 1.18µs ± 1% 1.22µs ± 1% +2.93% (p=0.008 n=5+5)
ReadReuseRecordWithFieldsPerRecord-8 1.18µs ± 0% 1.21µs ± 0% +2.54% (p=0.008 n=5+5)
ReadReuseRecordWithoutFieldsPerRecord-8 1.18µs ± 0% 1.22µs ± 1% +3.66% (p=0.008 n=5+5)
ReadReuseRecordLargeFields-8 2.53µs ± 1% 2.57µs ± 1% +1.70% (p=0.008 n=5+5)
Write-8 1.02µs ± 1% 1.01µs ± 0% -1.18% (p=0.016 n=5+4)
```
Fixes#44221.
Change-Id: Id37c50fc396024eef406c5bad45380ecd414f5ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/291290
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Paul Jolly <paul@myitcv.org.uk>
Top align allocations in tinyalloc buckets when in race mode.
This will make checkptr checks more reliable, because any code
that modifies a pointer past the end of the object will trigger
a checkptr error.
No test, because we need -race for this to actually kick in. We could
add it to the race detector tests, but the race detector tests are all
geared towards race detector reports, not checkptr reports. Mucking
with parsing reports is more than a test is worth.
Fixes#38872
Change-Id: Ie56f0fbd1a9385539f6631fd1ac40c3de5600154
Reviewed-on: https://go-review.googlesource.com/c/go/+/315029
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
iOS arm64 is a 64-bit platform but with a strictly 32-bit address space
(technically 33 bits, but the bottom half is unavailable to the
application). Since address space is limited, use 4 MiB arenas instead
of 64 MiB arenas. No changes are needed to the arena index because it's
still relatively small; this change just brings iOS more in line with
32-bit platforms.
Change-Id: I484e2d273d896fd0a57cd5c25012df0aef160290
Reviewed-on: https://go-review.googlesource.com/c/go/+/270538
Trust: Michael Knyszek <mknyszek@google.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Add some test data files that were not included in go/types.
- Issue 43125 only pertained to types2 because go/ast differentiates
StarExpr, UnaryExpr, and BinaryExpr, so typexpr.go was already
catching the invalid type expressions.
- Issues 42987 and 43190 are handled differently by go/parser.
- main.go2 was not added when ported to go/types, because this work
happened on the dev.regabi branch, which didn't support generics.
Test files are modified to adjust errors messages and positions, and to
update the copyright year.
Change-Id: Ia737eaab9afb2b59600b661ccf3eec3cbbb2d66c
Reviewed-on: https://go-review.googlesource.com/c/go/+/315070
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>
When internal linking with C objects, some C object relocations
may be turned into a CALL via PLT. For very large programs, the
PLT stub may be laid too far.
PLT stubs are generated late in the linker, and laid out after
the end of the text section. So if the text section is big, the
PLT stubs are likely too far.
To avoid this situation, add trampolines for PLT calls in the
trampoline pass. Only do this when the program is known too large
(i.e. the second pass of the two-pass algorithm).
Updates #40492.
Change-Id: I21f65d6cbc6bde84e3cf9c2ae05f5233df6cfa72
Reviewed-on: https://go-review.googlesource.com/c/go/+/314452
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Compared to ARM32 or PPC64, ARM64 has larger range for direct jumps.
But for very large programs it can still go over the limit. Add
trampoline insertion for ARM64.
Updates #40492.
Change-Id: Id97301dbc35fb577ba3f8d5f3316a8424d4f53c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/314451
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Currently in the linker, for trampoline insertion it does a one-pass
approach, where it assigns addresses for each function and inserts
trampolines on the go. For this to work and not to emit too many
unnecessary trampolines, the functions need to be laid out in
dependency order, so a direct call's target is always as a known
address (or known to be not too far).
This mostly works, but there are a few exceptions:
- linkname can break dependency tree and cause cycles.
- in internal linking mode, on some platforms, some calls are turned
into calls via PLT, but the PLT stubs are inserted rather late.
Also, this is expensive in that it has to investigate all CALL
relocations.
This CL changes it to use a two-pass approach. The first pass is
just to assign addresses without inserting any trampolines, assuming
the program is not too big. If this succeeds, no extra work needs to
be done. If this fails, start over and insert trampolines for too-
far targets as well as targets with unknown addresses. This should
make it faster for small programs (most cases) and generate fewer
conservative trampolines.
Change-Id: Ib13e01f38ec6dfbef1cd446b06da33ee17bded5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/314450
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Over this cycle some error code values have changed due to codes being
added/removed. This is probably OK to do once more before we export
error codes in a later Go version, but for now let's keep them stable.
Move things around to correct the changes, and update comments in
errorcodes.go to make it clearer that new codes should be added at the
end.
Change-Id: Id32827ef1a72cfd876ccc039da11d0a1be7470e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/314830
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>
Having multiple subdirectories of go/types containing test data is
slightly problematic:
- If ever we were to include a .go file in one of these directories,
we'd inadvertently create a visible package.
- It's difficult to add other content in testdata/, since TestTestdata
scans the entire directory.
Move everything down a level, into testdata/{fixedbugs,examples,check},
and update tests accordingly.
Change-Id: Idd074c94b7b261d678934330539e41a48c2a9dc9
Reviewed-on: https://go-review.googlesource.com/c/go/+/314829
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>
There was only one meaningful caller, which changes to call time_now.
This clearly separates systems that use walltime1 to be just those
that use the stub version of time_now. That is to say, those that do
not provide an assembler version of time_now.
Change-Id: I14c06cc402070bd705f953af6f9966785015e2a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/314769
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This is a port of CL 312170 to go/types, adjusted to use go/ast and to
add error codes. go/parser already emits errors for non-identifiers on
the LHS of a short var decl, so a TODO is added to reconsider this
redundancy.
A new error code is added for repeated identifiers in short var decls.
This is a bit specific, but I considered it to be a unique kind of
error.
The x/tools tests for this port turned up a bug: the new logic failed to
call recordDef for blank identifiers. Patchset #2 contains the fix for
this bug, both in go/types and cmd/compile/internal/types2.
Change-Id: Ibdc40b8b4ad0e0696111d431682e1f1056fd5eeb
Reviewed-on: https://go-review.googlesource.com/c/go/+/314629
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>
Build other definitions with the !faketime build tag.
This makes it easy for us to add new assembly implementations of time.now.
Change-Id: I4e48e41a4a04ab001030e6d1cdd9cebfa0161b0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/314274
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
1. The existing prose implied that a switch expression type must
be comparable because it is tested for equality against all case
expressions. But for an empty switch (no case expressions), it
was not clear if the switch expression needed to be comparable.
Require it to match the behavior of compiler and type checkers.
2. While making this change, remove redundant language explaining
what happens with untyped boolean switch expression values: the
default type of an untyped boolean value is bool, this is already
covered by the first part of the relevant sentence.
Fixes#43200.
Change-Id: Id8e0f29cfa8722b57cd2b7b58cba85b58c5f842b
Reviewed-on: https://go-review.googlesource.com/c/go/+/314411
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rob Pike <r@golang.org>
This is a modified port of the https://golang.org/cl/313909
change for go/types.
- add catch-all cases for unexpected expression lists
- add Checker.singleIndex function to check single indices
- better syntax error handling in parser for invalid type
instantiations that are missing a type argument
Change-Id: I6f0f396d637ad66b79f803d886fdc20ee55a98b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/314409
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
First, we can use flag.Args instead of flag.NArg and flag.Arg.
Second, just call filepath.WalkDir directly on each argument. We don't
need to check if each argument is a directory or not, since the function
will still work on regular files as expected.
To continue giving an error in the "gofmt does-not-exist.go" case, we
now need to return and handle errors from filepath.WalkDir, too.
Arguably, that should have always been the case.
While at it, I noticed that the printinf of the "diff" command did not
obey the "out" parameter. Fix that.
Finally, remove the code to ignore IsNotExist errors. It was added in CL
19301, though it didn't include tests and its reasoning is dubious.
Using gofmt on a directory treewhile another program is concurrently
editing or removing files is inherently racy. Hiding errors can hide
valid problems from the user, and such racy usages aren't supported.
Change-Id: I2e74cc04c53eeefb25231d804752b53562b97371
Reviewed-on: https://go-review.googlesource.com/c/go/+/284138
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
If an error occurs in loading the module graph (such as a missing
checksum for a relevant go.mod file), that error should be terminal
and we should not look elsewhere to try to resolve the import. An
ImportMissingError instructs the caller to do exactly that, so don't
use that error type for this case.
(This behavior is tested incidentally in a later CL in this stack.)
For #36460
Change-Id: I963e39cc7fbc457c12a626c1402c0be29203d23b
Reviewed-on: https://go-review.googlesource.com/c/go/+/314633
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
This is a port of CL 308371 to go/types. The only meaningful change from
that CL is to use explicit return values in Checker.indexExpr, which I
felt was more readable. I made the same change in types2 to keep them in
sync
Change-Id: I3380c03fe49d3bf4167cadad305abe942785af19
Reviewed-on: https://go-review.googlesource.com/c/go/+/314432
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>
In the register allocator, if possible, we allocate a value to its
desired register (the ideal register for its next use). In some
cases the desired register does not satisfies the value's output
register mask. We should not use the register in this case.
In the following example, v33 is going to be returned as a
function result, so it is allocated to its desired register AX.
However, its Op cannot use AX as output, causing miscompilation.
v33 = CMOVQEQF <int> v24 v28 v29 : AX (~R0[int])
v35 = MakeResult <int,int,mem> v33 v26 v18
Ret v35
Change-Id: Id0f4f27c4b233ee297e83077e3c8494fe193e664
Reviewed-on: https://go-review.googlesource.com/c/go/+/314630
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
This CL adds a new flag to the testing package and the go test command
which randomizes the execution order for tests and benchmarks.
This can be useful for identifying unwanted dependencies
between test or benchmark functions.
The flag is off by default. If `-shuffle` is set to `on` then the system
clock will be used as the seed value. If `-shuffle` is set to an integer
N, then N will be used as the seed value. In both cases, the seed will
be reported for failed runs so that they can reproduced later on.
Fixes#28592
Change-Id: I62e7dfae5f63f97a0cbd7830ea844d9f7beac335
Reviewed-on: https://go-review.googlesource.com/c/go/+/310033
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Bryan C. Mills <bcmills@google.com>
As with -rdynamic, clang will pass -Wl,--dynamic-linker to the linker
even when linking statically. When using lld this will produce a statically
linked executable with a dynamic interpreter, which will crash at runtime.
This CL changes the linker to drop -Wl,--dynamic-linker when using -static,
as it already does with -rdynamic.
This has become more important since CL 310349, which changes the linker
to always pass a -Wl,--dynamic-linker option if the Go linker is invoked
with a -I option.
Change-Id: I68ed431064f02c70018bc0547585e5b0ebd20a41
Reviewed-on: https://go-review.googlesource.com/c/go/+/314412
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Add the printGoEnv function to print the go environment variables, using
the envcmd package instead of invoking go env.
Add the PrintEnv function to the envcmd package, to avoid duplicating
code.
Updates #45803
Change-Id: I38d5b936c0ebb16e741ffbee4309b95d6d0ecc6c
Reviewed-on: https://go-review.googlesource.com/c/go/+/314230
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The external linker uses R12. Do the same. We previously use R11,
the temp register in Go ABI. This does not really matter if the
caller is Go code, because all registers are clobbered at call.
But it the caller is C code, it may assume R11 live across a call.
Using R11 may clobber live value. On the callee side, R12 is not
an argument register in both Go and C calling convention.
Change-Id: I958c5dad52aa51bb282a7ad420f5423863e69c14
Reviewed-on: https://go-review.googlesource.com/c/go/+/314454
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
In external linking mode the external linker may insert
trampolines, which use R12 as a scratch register. So a call could
potentially clobber R12 if the target is laid out too far. Mark
R12 clobbered.
Also, we will use R12 for trampolines in the Go linker as well.
CL 310731 updated the generated rewrite files so imports are
grouped, but the generator was not updated to do so. Grouped
imports are nice. But as those are generated files, for
simplicity and my laziness, just regenerate with the current
generator (which makes imports not grouped).
Change-Id: Iddb741ff7314a291ade5fbffc7d315f555808409
Reviewed-on: https://go-review.googlesource.com/c/go/+/314453
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
TOOLEXEC_IMPORTPATH is useful for the toolexec program to know what
package is currently being built. This is otherwise tricky to figure out.
Unfortunately, for test packages it was lacking. In the added test case,
we have a total of four packages in 'go list -test':
test/main
test/main.test
test/main [test/main.test]
test/main_test [test/main.test]
And, when running with -toolexec, one would get the following values:
# test/main_test [test/main.test]
compile TOOLEXEC_IMPORTPATH="test/main_test"
# test/main [test/main.test]
compile TOOLEXEC_IMPORTPATH="test/main"
# test/main.test
compile TOOLEXEC_IMPORTPATH="test/main.test"
Note how the " [test/main.test]" suffixes are missing. Because of that,
when one sees TOOLEXEC_IMPORTPATH="test/main", it is ambiguous whether
the regular "test/main" package is meant, or its test variant, otherwise
known as "test/main [test/main.test]" and including foo_test.go
To fix this, we need unambiguous strings to identify the packages
involved, just like one can do with "go list -test". "go list" already
has such a field, ImportPath, which is also used when printing output
from each build "action" as seen above.
That string is not really an import path - internally, it's
load.Package.Desc, and called a "description". However, it makes sense
to be consistent with "go list -json", because it's the source of truth
for practically all tools interacting with the Go toolchain.
To keep cmd/go more consistent, "go list -f {{.ImportPath}}" now calls
Package.Desc as well, instead of having its own copy of the string
concatenation for ForTest.
Fixes#44963.
Change-Id: Ibce7fbb5549209dac50526043c0c7daa0beebc08
Reviewed-on: https://go-review.googlesource.com/c/go/+/313770
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>
The current code lacks a check on whether the register and shift/extension
combination is valid, for example the follow instructions also compiles.
ADD F1<<1, R1, R3
ADD V1<<1, R1, R3
MOVW (R9)(F8.SXTW<<2), R19
VST1 R4.D[1], (R0)
Actually only general registers can perform shift operations, and element
and arrangement extensions are only applicable to vector registers. This
CL adds a check for the register and shift/extension combination on arm64.
Change-Id: I93dd9343e92a66899cba8eaf4e0ac5430e94692b
Reviewed-on: https://go-review.googlesource.com/c/go/+/312571
Trust: eric fang <eric.fang@arm.com>
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
In CL 255899, we added code to make clearer error when non-bool used
as operand to logical operators. The code is safe, because node type
is guaranteed to be non-nil.
In CL 279442, we refactored typechecking arith, including moving
typechecking logical operators to separate case. Now we have to
explicitly check if operand type is not nil, because calling Expr can
set operand type nil for non-bool operands.
Fixes#45804
Change-Id: Ie2b6e18f65c0614a803b343f60e78ee1d660bbeb
Reviewed-on: https://go-review.googlesource.com/c/go/+/314209
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Functional plugin support requires cgo to be enabled. Disable
it if the environment has disabled cgo.
This prevents unexpected linker failures when linking large
binaries with cgo disabled which use the plugin package.
Fixes#45564
Change-Id: Ib71f0e089f7373b7b3e3cd53da3612291e7bc473
Reviewed-on: https://go-review.googlesource.com/c/go/+/314449
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
This is a port of CL 308370 to go/types. There are some differences in
the index checking code, but the methodology for moving the code was the
same: replace `goto Error` with `x.mode = invalid; return`.
Change-Id: I880f577a7720e6ad8a5b096207001fcf7620396d
Reviewed-on: https://go-review.googlesource.com/c/go/+/312095
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>
Ensure that formal parameter Names are correctly copied and marked
with the correct Curfn. We need to ensure this even when the underlying
closure has no type parameters.
(Aside: it is strange that the types of things contain formal
parameter names that need to be copied. Maybe that's an underlying
larger problem that needs to be fixed.)
Fixes#45738
Change-Id: Ia13d69eea992ff7080bd44065115bc52eb624e73
Reviewed-on: https://go-review.googlesource.com/c/go/+/313652
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
For some reason, the go.mod file added to this test in CL 147281 lists
'go 1.20' instead of the version that was actually current when the
go.mod file was added.
That causes the test's behavior to change under lazy loading, because
1.20 is above the threshold to trigger lazy-loading invariants (1.17).
For #36460
Change-Id: I92400996cb051ab30e99bfffafd91ff32a1e7087
Reviewed-on: https://go-review.googlesource.com/c/go/+/314049
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
That way the skip takes effect.
Also ignore the result of calling TIOCSPGRP when cleaing up TestForeground.
It has started to fail for some reason, and the result doesn't matter.
Also call TIOCSPGRP to clean up in TestForegroundSignal.
For #37217
Change-Id: I2e4282d7d91ad9a198eeb12cef01c2214c2a98c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/314271
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Block profiles were biased towards infrequent long events over frequent
short events. This fix corrects the bias by aggregating shorter events
as longer but less frequent in the profiles. As a result their
cumulative duration will be accurately represented in the profile
without skewing their sample mean (duration/count).
Credit to @dvyukov for suggesting to adjust the count in the
saveblockevent function.
Fixes#44192.
Change-Id: I71a99d7f6ebdb2d484d44890a2517863cceb4004
Reviewed-on: https://go-review.googlesource.com/c/go/+/299991
Trust: Michael Pratt <mpratt@google.com>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
If a package declares 'package main' but for some reason we fail to
read its name (for example, due to a permission or checksum error),
we may be tempted to drop the package from the output of
mainPackagesOnly. However, that leads to a confusing
"no packages loaded from …" error message.
Instead, we will treat packages with errors as potentially-main
packages, and print the error. At least if we print why the package is
broken, the user will understand that the weird behavior is due to the
broken package rather than, say, a typo on their part in the command
arguments.
Updates #42088
For #36460
Change-Id: I033c0d28ac7d105d9df3ba5f9327e5c0c2a29954
Reviewed-on: https://go-review.googlesource.com/c/go/+/314050
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Go commands show a warning message any time a pattern is expanded and a
symlink to a directory is encountered. For monorepo with non Go projects
using symlinks underneath, the output of go commands could be spammed by
this warning.
This commit includes the behavior change to only print this warning when
there's a pattern containing ... .
Fixes#35941
Change-Id: I094da2628bcd47b86fee8c6529d1066aa013a43b
Reviewed-on: https://go-review.googlesource.com/c/go/+/311890
Run-TryBot: Caleb Spare <cespare@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Trust: Michael Matloob <matloob@golang.org>
ptrace1 must be nosplit because it is called from
forAndExecInChild. It was marked nosplit in the generated code
but not in the generator. CL 313230 regenerated the code and lost
the nosplit mark. This CL restores it.
Change-Id: I4645d83650f1818bed3cb650328bba97074b6b2d
Reviewed-on: https://go-review.googlesource.com/c/go/+/314249
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
While profiling parsing, I noticed that scanIdentifier was extremely
hot, and could be optimized: it is responsible for a significant
fraction of scanning and had a lot of unnecessary branching, bounds
checks, and function calls.
This CL implements some of those optimizations, while trying to strike a
balance between optimization and readability. It achieves this by
optimizing for the common case of ASCII identifiers, falling back on the
slower scan when encountering the first non-ASCII character.
Benchmark results:
name old time/op new time/op delta
Scan-12 16.9µs ± 4% 15.8µs ± 5% -6.92% (p=0.000 n=20+18)
ScanFiles/go/types/expr.go-12 793µs ± 4% 672µs ± 6% -15.23% (p=0.000 n=20+20)
ScanFiles/go/parser/parser.go-12 1.08ms ± 6% 0.90ms ± 4% -16.68% (p=0.000 n=20+20)
ScanFiles/net/http/server.go-12 1.44ms ± 4% 1.23ms ± 5% -14.58% (p=0.000 n=18+20)
ScanFiles/go/scanner/errors.go-12 40.7µs ± 2% 32.6µs ± 3% -20.01% (p=0.000 n=19+20)
Change-Id: If78380004248e3ea75cfc78eb7f38f528124dced
Reviewed-on: https://go-review.googlesource.com/c/go/+/308611
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>
The transform functions (specifically transformArgs, which is used from
transformCall/transformReturn) require that ir.CurFunc is set correctly.
Since transformCall() is used on the call of an instantiated generic
function, we need to set ir.CurFunc correctly in stencil(). Also,
correctly save/restore ir.CurFunc in genericSubst().
Without this fix, ir.CurFunc can be nil when we call TransformCall()
from stencil(), which leads to some temp variables being added
incorrectly to ir.TodoFunc (which leads to the fatal panic in the
issue).
Fixes#45722
Change-Id: Iddf4a67d28f2100dde8cde5dbc9ca1e00dad6089
Reviewed-on: https://go-review.googlesource.com/c/go/+/313869
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
BenchmarkScanFile was scanning scanner.go, which makes comparison
difficult for a CL modifying that file. That file is also is not
necessarily representative syntax.
Add a few additional files as subtests to provide a larger variety of
metrics.
Change-Id: Ib78303c2546debd84a0b5478ae438ba891d9e6e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/308610
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>
Currently tiny allocations are not represented in either MemStats or
runtime/metrics, but they're represented in MemStats (indirectly) via
Mallocs. Add them to runtime/metrics by first merging
memstats.tinyallocs into consistentHeapStats (just for simplicity; it's
monotonic so metrics would still be self-consistent if we just read it
atomically) and then adding /gc/heap/tiny/allocs:objects to the list of
supported metrics.
Change-Id: Ie478006ab942a3e877b4a79065ffa43569722f3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/312909
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
As an alternative to CL 312149, add a catch-all error message in
exprInternal when encountering a ListExpr, rather than panicking.
We still might want something like CL 312149 to improve the error
message or recovery from bad indexing.
Change-Id: I865f7cc4eefa4a3b7bd8f3100df96d0144e1712f
Reviewed-on: https://go-review.googlesource.com/c/go/+/313909
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>
When laying out, we lazily increase the alignment for text sections
as symbols are found requiring more. This works if the start of
the virtual address (VA) for the section is greater than or equal
to the alignment required by any symbols placed in this section.
The minimum alignment of the section is only known after all
symbols are placed. The starting VA of this section is adjusted
upwards in ld.(*Link).address to meet the requested alignment.
This is a problem if the starting VA of the text section is not
already aligned. This can happen when the final symbol placed
into the previous section results in an insufficiently aligned
start VA of the next text section.
To workaround this, additional text sections are split, and both
the starting VA, and alignment of the section are aligned up to
match the known worst case alignment.
64B is chosen as the worst case alignment for all ppc64 targets,
as it will respect PCALIGN and eventually prefixed instructions
which will be introduced in the future.
Likewise, the xcoff size calculations need to be improved to
handle padding bytes when function symbols have been aligned.
This is done by tracking the largest valid VA offset encountered
when placing symbols.
Change-Id: Iefef09a1ee7c963fb8dfce2288a084a95cb77fca
Reviewed-on: https://go-review.googlesource.com/c/go/+/307431
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
The code for generating a long constant versus generating an address
(either via a relocation, or known offset) should be handled in the
same place.
Resolve this by classifying memory arguments as C_LACON (a long
address constant) instead of C_LCON (a long constant).
Likewise, reorder AMOVD/AMOVW optab entries to keep similar
classifications near each other. An extra optab entry for
DWORD is also added to continue handling C_LACON arguments
correctly.
Change-Id: I5ce28400492a071f615125a9b8d260826f1600d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/312296
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Trust: Carlos Eduardo Seo <carlos.seo@linaro.org>
While debugging issue #45638, I discovered that some tests were using
--buildmode command line parameter instead of -buildmode.
The --buildmode parameter is handled properly by the flag package - it
is read as -buildmode. But we should correct code anyway.
Updates #45638
Change-Id: I75cf95c7d11dcdf4aeccf568b2dea77bd8942352
Reviewed-on: https://go-review.googlesource.com/c/go/+/313351
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
CL 211139 added TestLibraryCtrlHandler. But the CL left out import "C"
line in the test file that is supposed to be build with Cgo.
While debugging issue #45638, I discovered that the DLL built during
TestLibraryCtrlHandler does not have Dummy function. Adding import "C"
makes Dummy function appear in DLL function list.
TestLibraryCtrlHandler does not actually calls Dummy function. So I
don't see how this change affects issue #45638, but still let's make
this code correct.
Updates #45638
Change-Id: Ibab8fed29ef2ae446d0815842cf0bd040a5fb943
Reviewed-on: https://go-review.googlesource.com/c/go/+/313350
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
• Consolidate 'if ld.AllowErrors' conditions into an 'ld.errorf'
method.
• Rename SilenceErrors to SilencePackageErrors and clarify its
documentation. (There is currently no way to silence errors in the
module graph. Perhaps we should add one, but for now let's at least
clarify the existing behavior.)
• Move 'tidy -v' verbose logging into LoadPackages, where other
logging happens.
• Make checkMultiplePaths a loader method (since it only matters
during package loading anyway).
• Check package and module-graph errors in loadFromRoots instead of
LoadPackages. These checks were previously omitted on the
ImportFromFiles path, which seems likely to be a bug. (We now
suppress package errors explicitly in ImportFromFiles, which at
least makes the bug more explicit.)
This somewhat simplifies the code structure in preparation for
the lazy-mode tidy implementation.
For #36460
Change-Id: I3ce3586c6934989d5194f00f99e7cc4423cf767f
Reviewed-on: https://go-review.googlesource.com/c/go/+/313229
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
CL 209578 disambiguated paths among imported packages, but as
demonstrated in #43119, formatted types may reference packages that are
not directly imported.
Fix this by recursively walking all imports to determine whether there
is any ambiguity in the import graph. This might result in
over-qualification of names, but it is straightforward and should
eliminate any ambiguity.
In general this should be fine, but might introduce risk of infinite
recursion in the case of an importer bug, or performance problems for
very large import graphs. Mitigate the former by tracking seen packages,
and the latter by only walking the import graph once an error has been
produced.
Fixes#43119
Change-Id: If874f050ad0e808db8e354c2ffc88bc6d64fd277
Reviewed-on: https://go-review.googlesource.com/c/go/+/313035
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>
Within clovar, n.Defn can also be *ir.TypeSwitchGuard. The proper fix
here would be to populate m.Defn and have it filled in too, but we
already leave it nil in inlvar. So for consistency, this CL does the
same in clovar too.
Eventually inl.go should be rewritten to fully respect IR invariants.
Fixes#45743.
Change-Id: I8b38e5d8b2329ad242de97670f2141f713954d28
Reviewed-on: https://go-review.googlesource.com/c/go/+/313289
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The (*loadPkg).mod field normally indicates the module from which the
package was loaded. However, if the package was missing, we previously
used the mod field to instead store the module from which we intend to
load the package next time around.
That sort of dual use makes the semantics (and synchronization) of the
mod field much more complex to reason about. For example, it would be
nice to have the invariant that the mod field is always one of the
modules in the overall build list, or one of the modules selected in
the overall module graph. Similarly, it would be nice to have the
invariant that the version indicated by the mod field can coexist with
(without upgrading) all of the other versions indicated in the mod
fields of other packages.
This repurposing of the mod field appears to be solely in the service
of storing the module when resolving missing imports. To keep
conceptually-separate fields separate, I have changed
resolveMissingImports to store a slice of package–module pairs,
instead of just packages that need to be revisited.
This may increase allocation pressure slightly if we have many
unresolved packages, but most packages are not unresolved, and it
seems worth the cost to use a little extra memory if it means we can
reason more clearly about the (quite complex) behaviors of the module
loader.
For #36460
Change-Id: Ic434df0f38185c6e9e892c5e9ba9ff53b3efe01f
Reviewed-on: https://go-review.googlesource.com/c/go/+/312930
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
In CL 288092 we made Darwin syscall wrappers as ABIInternal, so
their addresses taken from Go using funcPC are the actual function
entries, not the wrappers.
As we introduced internal/abi.FuncPCABIxxx intrinsics, use that.
And change the assembly functions back to ABI0.
Change-Id: I50645af74883e2d5dfcd67a5e8c739222c6f645b
Reviewed-on: https://go-review.googlesource.com/c/go/+/313250
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Currently there's a minor bug where the constant for the min fraction of
time spent scavenging is rounded down to zero. I don't think this
affects anything in practice because this case is exceedingly rare and
extreme, but currently it doesn't properly prevent the pacing parameters
from getting out of hand in these extreme cases.
Fixes#44036.
Change-Id: I7de644ab0ecac33765c337a736482a0966882780
Reviewed-on: https://go-review.googlesource.com/c/go/+/313249
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This CL provide abilty to randomly select P to steal object from its
shared queue. In order to provide such ability randomOrder structure
was copied from runtime/proc.go.
It should reduce contention in firsts Ps and improve balance of object
stealing across all Ps. Also, the patch provides new benchmark
PoolStarvation which force Ps to steal objects.
Benchmarks:
name old time/op new time/op delta
Pool-8 2.16ns ±14% 2.14ns ±16% ~ (p=0.425 n=10+10)
PoolOverflow-8 489ns ± 0% 489ns ± 0% ~ (p=0.719 n=9+10)
PoolStarvation-8 7.00µs ± 4% 6.59µs ± 2% -5.86% (p=0.000 n=10+10)
PoolSTW-8 15.1µs ± 1% 15.2µs ± 1% +0.99% (p=0.001 n=10+10)
PoolExpensiveNew-8 1.25ms ±10% 1.31ms ± 9% ~ (p=0.143 n=10+10)
[Geo mean] 2.68µs 2.68µs -0.28%
name old p50-ns/STW new p50-ns/STW delta
PoolSTW-8 15.0k ± 1% 15.1k ± 1% +0.92% (p=0.000 n=10+10)
name old p95-ns/STW new p95-ns/STW delta
PoolSTW-8 16.2k ± 3% 16.4k ± 2% ~ (p=0.143 n=10+10)
name old GCs/op new GCs/op delta
PoolExpensiveNew-8 0.29 ± 2% 0.30 ± 1% +2.84% (p=0.000 n=8+10)
name old New/op new New/op delta
PoolExpensiveNew-8 8.07 ±11% 8.49 ±10% ~ (p=0.123 n=10+10)
Change-Id: I3ca1d0bf1f358b1148c58e64740fb2d5bfc0bc02
Reviewed-on: https://go-review.googlesource.com/c/go/+/303949
Reviewed-by: David Chase <drchase@google.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
In CL 288092 we made Darwin syscall wrappers as ABIInternal, so
their addresses taken from Go using funcPC are the actual function
entries, not the wrappers.
As we introduced internal/abi.FuncPCABIxxx intrinsics, use that.
And change the assembly functions back to ABI0.
Do it on OpenBSD as well, as OpenBSD and Darwin share code
generator.
Change-Id: I408120795f7fc826637c867394248f8f373906bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/313230
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
With the new register ABI, the compiler sometimes introduces spills of
argument registers in function prologs; depending on the positions
assigned to these spills and whether they have the IsStmt flag set,
this can degrade the debugging experience. For example, in this
function from one of the Delve regression tests:
L13: func foo((eface interface{}) {
L14: if eface != nil {
L15: n++
L16: }
L17 }
we wind up with a prolog containing two spill instructions, the first
with line 14, the second with line 13. The end result for the user
is that if you set a breakpoint in foo and run to it, then do "step",
execution will initially stop at L14, then jump "backwards" to L13.
The root of the problem in this case is that an ArgIntReg pseudo-op is
introduced during expand calls, then promoted (due to lowering) to a
first-class statement (IsStmt flag set), which in turn causes
downstream handling to propagate its position to the first of the register
spills in the prolog.
To help improve things, this patch changes the rewriter to avoid
moving an "IsStmt" flag from a deleted/replaced instruction to an
Arg{Int,Float}Reg value, and adds Arg{Int,Float}Reg to the list of
opcodes not suitable for selection as statement boundaries, and
suppresses generation of additional register spills in defframe() when
optimization is disabled (since in that case things will get spilled
in any case).
This is not a comprehensive/complete fix; there are still cases where
we get less-than-ideal source position markers (ex: issue 45680).
Updates #40724.
Change-Id: Ica8bba4940b2291bef6b5d95ff0cfd84412a2d40
Reviewed-on: https://go-review.googlesource.com/c/go/+/312989
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Currently this test attempts to trigger a concurrent GC in a very
indirect way, but the way it does so is extremely error-prone. This test
is virtually always prone to flaking based on test order. For example if
the test that executed immediately before this one made a big heap but
didn't clean it up, then this test could easily fail to trigger a GC.
I was able to prove this with a small reproducer.
This roundabout way of triggering a GC is also way overkill for this
test. It just wants to get goroutines in a select and shrink their
stacks. Every GC will schedule a stack for shrinking if it can.
Replace all the complicated machinery with a single runtime.GC call.
I've confirmed that the test consistently triggers a stack shrink,
noting that both shrinkstack's copystack call is made and that
syncadjustsudogs (the relevant function that's being indirectly tested)
are both called.
Fixes#44610.
Change-Id: Ib1c091e0d1475bf6c596f56dc9b85eaea366fc73
Reviewed-on: https://go-review.googlesource.com/c/go/+/313109
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
At least in mingw-clang it is not permitted to just name a .dll
on the command line. You must name the corresponding import
library instead, even though the dll is used when the executable
is run.
This fixes misc/cgo/testso and misc/cgo/testsovar on windows/arm64.
Change-Id: I516b6ccba2fe3a9ee2c01e710a71850c4df8522f
Reviewed-on: https://go-review.googlesource.com/c/go/+/312046
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Fixes the previously failing TestStdcallAndCDeclCallbacks
for the 9+ argument case.
The last time this code passed, the invisible frame pointer
below SP was apparently not enabled on windows/arm64.
Change-Id: Ifc3064e894b2f39d6410f3be51c17309ebab08a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/312042
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
llvm-mingw's lld produces an invalid windows/arm64 executable
when presented with relocations that are out of order
(the relocation for each function is emitted for two different
locations, so we end up with two sorted streams roughly
interlaced, not one sorted stream).
Sorting should not break other systems, so sort always.
Change-Id: Ic9a95e7145881db5984cbda442f27b0cc24748fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/312033
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The clang-mingw toolchain on windows/arm64 expects
.text to NOT be listed as containing initialized data and
.dwarf* to be listed as containing initialized data.
Neither is true today, resulting in the go .text and .dwarf*
not being merged with the system .text and .dwarf*.
Having multiple .text and .dwarf* sections confuses all
kinds of tools.
Change-Id: I1b9832804c5f5d594bf19e8ee0a5ed31bc1d381d
Reviewed-on: https://go-review.googlesource.com/c/go/+/312032
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
DWARF sections generated by mingw-clang seem to include these
(not often - only one out of many in the binary that I am looking at).
Skipping over them, everything parses correctly.
This makes TestDefaultLinkerDWARF pass on windows/arm64.
Change-Id: Ie4a7daa1423f51cbc8c4aac88b1d27c3b52ee880
Reviewed-on: https://go-review.googlesource.com/c/go/+/312031
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The cmd/link check of the objabi header was a bit lax because
historically the assembler has not included the full version string.
And the assembler didn't do that because it didn't have access to it:
that was buried inside the compiler.
But now that we have cmd/internal/objabi, all the tools have full
access to the expected string, and they can use it, which simplifies
the cmd/link consistency check.
Do that.
Change-Id: I33bd2f9d36c373cc3c32ff02ec6368365088b011
Reviewed-on: https://go-review.googlesource.com/c/go/+/312030
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
An exported Go function like
//export F
func F() {}
gets declared in _cgo_export.h as something like
extern void F(void);
The exact declaration varies by operating system.
In particular, Windows adds __declspec(dllimport).
Clang on Windows/ARM64 rejects code that contains
conflicting declarations for F, like:
extern void F(void);
extern void __declspec(dllimport) F(void);
This means that F must not be declared separately from _cgo_export.h:
any code that wants to refer to F must use #include "_cgo_export.h".
Unfortunately, the cgo prologue itself (the commented code before import "C")
cannot include "_cgo_export.h", because that file is itself produced from the
cgo Go sources and therefore cannot be a dependency of the cgo Go sources.
This CL rewrites misc/cgo/test to avoid redeclaring exported functions.
Most of the time, this is not a significant problem: just move the code
that needs the header into a .c file, perhaps with a wrapper exposed
to the cgo Go sources.
The one case that is potentially problematic is f7665, which is part of
the test for golang.org/issue/7665. That bug report explicitly identified
a bug in referring to the C name for an exported function in the same
Go source file as it was exported function. That is now impossible,
at least on Windows/ARM64, so the test is modified a bit and possibly
does not test what the original bug was. But the original bug should
be long gone: that part of the compiler has been rewritten.
Change-Id: I0d14d9336632f0e5e3db4273d9d32ef2cca0298d
Reviewed-on: https://go-review.googlesource.com/c/go/+/312029
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When ABI wrappers are used, there are cases where in Go code we
need the PC of the defined function instead of the ABI wrapper.
Currently we work around this by define such functions as
ABIInternal, even if they do not actually follow the internal ABI.
This CL introduces internal/abi.FuncPCABIxxx functions as compiler
intrinsics, which return the underlying defined function's entry
PC if the argument is a direct reference of a function of the
expected ABI, and reject it if it is of a different ABI.
As a proof of concept, change runtime.goexit back to ABI0 and use
internal/abi.FuncPCABI0 to retrieve its PC.
Updates #44065.
Change-Id: I02286f0f9d99e6a3090f9e8169dbafc6804a2da6
Reviewed-on: https://go-review.googlesource.com/c/go/+/304232
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
The previous fix to ensure early evaluation of lvalue-init statements
(CL 312632) added it after we'd already peeled away any array-OINDEX
expressions. But those might have init statements too, so we need to
do this earlier actually and perhaps more than once.
Longer term, lvalue expressions shouldn't have init statements anyway.
But rsc and I both spent a while looking into this earlier in the dev
cycle and couldn't come up with anything reasonable.
Fixes#45706.
Change-Id: I2d19c5ba421b3f019c62eec45774c84cf04b30ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/313011
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
At one point this map checked for infinite loops during package iteration.
The last write to the map was mistakenly removed in CL 251445.
However, looking at the code before that change, the map-based
termination strategy was never quite right to begin with: it checked
whether we had ever added any module for the given package, not
whether we had already added the module being proposed right now. (For
packages within nested modules, we could try adding multiple different
modules for a given package without looping.)
Moreover, the "looping trying to add package" failure message was only
marginally helpful. Users are capable of noticing that an invocation
of the 'go' command is taking too long, and will report a bug for an
infinite loop just as readily as a "looping trying to add package"
error.
We could try to add this tracking back in, but it's no substitute for
a proper proof of convergence, and the code is simpler without it.
Instead I'm going to add a proper proof of convergence — or, barring
that, a more accurate and useful check for failure to converge. In the
meantime, this invariantly-empty map isn't doing anybody any good.
For #36460
Change-Id: I2c111d4b4bf59159af0d7e62d1c0ef4ce0a43a71
Reviewed-on: https://go-review.googlesource.com/c/go/+/312929
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
This change adds a metric to track scheduling latencies, defined as the
cumulative amount of time a goroutine spends being runnable before
running again. The metric is an approximations and samples instead of
trying to record every goroutine scheduling latency.
This change was primarily authored by mknyszek@google.com.
Change-Id: Ie0be7e6e7be421572eb2317d3dd8dd6f3d6aa152
Reviewed-on: https://go-review.googlesource.com/c/go/+/308933
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Currently, when copying definition node of an inlined var, we do not
update var Defn field to point to new copied node. That causes all
inlined vars point to the same Defn, and ir.StaticValue can not find
inlined var in the lhs of its definition.
clovar creates new ONAME node for local variables or params of closure
inside inlined function, by copying most of the old node fields. So the
new Node.Defn is not modified, its lhs still refer to old node
instead of new one.
To fix this, we need to do two things:
- In subst.clovar, set a dummy Defn node for inlvar
- During subst.node, when seeing OAS/OAS2 nodes, after substituting, we
check if any node in lhs has the dummy Defn, then set it to the current
OAS/OAS2 node.
Fixes#45606
Change-Id: Ib517b753a7643756dcd61d36deae60f1a0fc53c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/312630
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
For go statement, the wrapper closure needs to esacpe because it
runs asynchronously. Currently, it is not allowed for closures to
escape in the runtime. We have worked around this in the runtime,
so it doesn't "go" any function with arguments and so doesn't
need wrapping. If it ever does, it is not that we can have the
closure not escape, which may lead to miscompilation. Instead,
make the closure escape (which will fail the compilation). In the
future we may allow go'd closure to escape in the runtime.
Change-Id: I5bbe47b524371d2270c242f6c275013cd52abfc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/312889
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
The defer wrapping feature added to the compiler's "order" phase
creates temporaries into which it copies defer arguments. If one of
these temps is large enough that we place it into the defer closure by
address (as opposed to by value), then the temp in question can't be
reused later on in the order phase, nor do we want a VARKILL
annotation for it at the end of the current block scope.
Test written by Cherry.
Updates #40724.
Change-Id: Iec7efd87ec5a3e3d7de41cdcc7f39c093ed1e815
Reviewed-on: https://go-review.googlesource.com/c/go/+/312869
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Currently Readlink gets linked into the binary even when Executable is
not needed.
This reduces a simple "os.Stdout.Write([]byte("hello"))" by ~10KiB.
Previously the executable path was read during init time, because
deleting the executable would make "Readlink" return "(deleted)" suffix.
There's probably a slight chance that the init time reading would return
it anyways.
Updates #6853
Change-Id: Ic76190c5b64d9320ceb489cd6a553108614653d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/311790
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
When an M transitions from spinning to non-spinning state, it must
recheck most sources of work to avoid missing work submitted between its
initial check and decrementing sched.nmspinning (see "delicate dance"
comment).
Ever since the scheduler rewrite in Go 1.1 (golang.org/cl/7314062), we
have performed this recheck on all Ms before stopping, regardless of
whether or not they were spinning.
Unfortunately, there is a problem with this approach: non-spinning Ms
are not eligible to steal work (note the skip over the stealWork block),
but can detect work during the recheck. If there is work available, this
non-spinning M will jump to top, skip stealing, land in recheck again,
and repeat. i.e., it will spin uselessly.
The spin is bounded. This can only occur if there is another spinning M,
which will either take the work, allowing this M to stop, or take some
other work, allowing this M to upgrade to spinning. But the spinning is
ultimately just a fancy spin-wait.
golang.org/issue/43997 discusses several ways to address this. This CL
takes the simplest approach: skipping the recheck on non-spinning Ms and
allowing them to go to stop.
Results for scheduler-relevant runtime and time benchmarks can be found
at https://perf.golang.org/search?q=upload:20210420.5.
The new BenchmarkCreateGoroutinesSingle is a characteristic example
workload that hits this issue hard. A single M readies lots of work
without itself parking. Other Ms must spin to steal work, which is very
short-lived, forcing those Ms to spin again. Some of the Ms will be
non-spinning and hit the above bug.
With this fixed, that benchmark drops in CPU usage by a massive 68%, and
wall time 24%. BenchmarkNetpollBreak shows similar drops because it is
unintentionally almost the same benchmark (create short-living Gs in a
loop). Typical well-behaved programs show little change.
We also measure scheduling latency (time from goready to execute). Note
that many of these benchmarks are very noisy because they don't involve
much scheduling. Those that do, like CreateGoroutinesSingle, are
expected to increase as we are replacing unintentional spin waiting with
a real park.
Fixes#43997
Change-Id: Ie1d1e1800f393cee1792455412caaa5865d13562
Reviewed-on: https://go-review.googlesource.com/c/go/+/310850
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This situation is analogous to CL 309334: the test expects 'go mod
tidy' to fail due to a module used for more than one path in the build
list, but doesn't actually contain any packages or imports — so no
module is necessarily used at all, and the error only occurs if we
report it prematurely.
For #36460
Change-Id: I5ccecf30f280895eba913a8d62571872b75e710d
Reviewed-on: https://go-review.googlesource.com/c/go/+/312098
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Currently, when the runtime printing a stack track (at panic, or
when runtime.Stack is called), it prints the function arguments
as words in memory. With a register-based calling convention,
the layout of argument area of the memory changes, so the
printing also needs to change. In particular, the memory order
and the syntax order of the arguments may differ. To address
that, this CL lets the compiler to emit some metadata about the
memory layout of the arguments, and the runtime will use this
information to print arguments in syntax order.
Previously we print the memory contents of the results along with
the arguments. The results are likely uninitialized when the
traceback is taken, so that information is rarely useful. Also,
with a register-based calling convention the results may not
have corresponding locations in memory. This CL changes it to not
print results.
Previously the runtime simply prints the memory contents as
pointer-sized words. With a register-based calling convention,
as the layout changes, arguments that were packed in one word
may no longer be in one word. Also, as the spill slots are not
always initialized, it is possible that some part of a word
contains useful informationwhile the rest contains garbage.
Instead of letting the runtime recreating the ABI0 layout and
print them as words, we now print each component separately.
Aggregate-typed argument/component is surrounded by "{}".
For example, for a function
F(int, [3]byte, byte) int
when called as F(1, [3]byte{2, 3, 4}, 5), it used to print
F(0x1, 0x5040302, 0xXXXXXXXX) // assuming little endian, 0xXXXXXXXX is uninitilized result
Now prints
F(0x1, {0x2, 0x3, 0x4}, 0x5).
Note: the liveness tracking of the spill splots has not been
implemented in this CL. Currently the runtime just assumes all
the slots are live and print them all.
Increase binary sizes by ~1.5%.
old new
hello (println) 1171328 1187712 (+1.4%)
hello (fmt) 1877024 1901600 (+1.3%)
cmd/compile 22326928 22662800 (+1.5%)
cmd/go 13505024 13726208 (+1.6%)
Updates #40724.
Change-Id: I351e0bf497f99bdbb3f91df2fb17e3c2c5c316dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/304470
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The extended opcode field (XO) is generated incorrectly. OPVCC
assumes an X-form like layout for the XO field. MD-form insns
also have an XO field, but it is both smaller and in a different
bit position.
This hasn't been noticed since const1 == 0 matches as a register
argument instead of a constant, thus it is unlikely anyone has
attempted to assemble this instruction with a non-zero shift
argument.
Likewise, update all other MD-form instructions using OPVCC
to use the new OPMD function.
Change-Id: Id81fa2727fb701431911a05492c2038415ad0a4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/310851
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
cgocallback calls cgocallbackg after switching the stack. Call it
indirectly to bypass the linker's nosplit check.
Apparently (at least on Windows) cgocallbackg can use quite a bit
stack space in a nosplit chain. We have been running over the
nosplit limit, or very close to the limit. Since it switches
stack in cgocallback, it is not meaningful to count frames above
cgocallback and below cgocallbackg together. Bypass the check.
For #45658.
Change-Id: Ie22017e3f82d2c1fcc37336696f2d02757856399
Reviewed-on: https://go-review.googlesource.com/c/go/+/312669
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
These tests match the corresponding tests for go/types
which have been reviewed.
This CL simply removes the UNREVIEWED disclaimer.
Change-Id: I4dfe2aedc1341ebb9ba206aac1a072f32cbe1f78
Reviewed-on: https://go-review.googlesource.com/c/go/+/312569
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
For arm64 constant shift instructions, e.g., LSL(immediate), they use
only the low 6 bits. To conform the semantics of the hardware instructions,
this CL comments in ARM64OPS.go about restricted AuxInt ranges for the
various instructions involved.
Change-Id: I2b6560d6580e22ba7cbfa744a02b046dd5714b8a
Reviewed-on: https://go-review.googlesource.com/c/go/+/303569
Trust: fannie zhang <Fannie.Zhang@arm.com>
Reviewed-by: Keith Randall <khr@golang.org>
It sometimes seems to time out on slow systems, perhaps due to
being run at the same time as a lot of other work.
Also move the code to testdata/testprog, so that we don't have to
build it separately.
I hope that this
Fixes#35356
Change-Id: I875b858fa23836513ae14d3116461e22fffd5352
Reviewed-on: https://go-review.googlesource.com/c/go/+/312510
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is a port of CL 306170 to go/types, adjusted for the different
positioning API.
Some of the error positions in tests had to be adjusted, but I think the
new locations are better.
Change-Id: Ib157fbb47d7483e3c6302bd57f5070bd74602a36
Reviewed-on: https://go-review.googlesource.com/c/go/+/312191
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>
Currently we call runtimeQPC as ABIInternal because it shaves off 24
bytes by not having an extra wrapper, and at the time we were exceeding
the nosplit stack limit in some cases.
However, this code was written before we had the regabiargs GOEXPERIMENT
flag, and wasn't properly flagged. Naturally, with regabiargs enabled,
it leads to garbage being returned, because it needs to store
runtimeQPC's result to the stack.
We didn't notice this because today runtimeQPC is only used in Wine, not
on any native Windows platform.
Back when I wrote this code, it appeared to be necessary on even native
Windows, but it turns out that's not true anymore. Turn it back into a
native call through a wrapper.
For #40724.
Change-Id: Ia2e5901965ef46c5f299daccef49952026854fe6
Reviewed-on: https://go-review.googlesource.com/c/go/+/312429
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The runtime support for syscall.AllThreadsSyscall() functions had
some corner case deadlock issues when signal handling was in use.
This was observed in at least 3 build test failures on ppc64 and
amd64 architecture CGO_ENABLED=0 builds over the last few months.
The fixes involve more controlled handling of signals while the
AllThreads mechanism is being executed. Further details are
discussed in bug #44193.
The all-threads syscall support is new in go1.16, so earlier
releases are not affected by this bug.
Fixes#44193
Change-Id: I01ba8508a6e1bb2d872751f50da86dd07911a41d
Reviewed-on: https://go-review.googlesource.com/c/go/+/305149
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Pratt <mpratt@google.com>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This adds a power9 version of the bytes.Index function
for little endian.
Here is the improvement on power9 for some of the Index
benchmarks:
Index/10 -0.14%
Index/32 -3.19%
Index/4K -12.66%
Index/4M -13.34%
Index/64M -13.17%
Count/10 -0.59%
Count/32 -2.88%
Count/4K -12.63%
Count/4M -13.35%
Count/64M -13.17%
IndexHard1 -23.03%
IndexHard2 -13.01%
IndexHard3 -22.12%
IndexHard4 +0.16%
CountHard1 -23.02%
CountHard2 -13.01%
CountHard3 -22.12%
IndexPeriodic/IndexPeriodic2 -22.85%
IndexPeriodic/IndexPeriodic4 -23.15%
Change-Id: Id72353e2771eba2efbb1544d5f0be65f8a9f0433
Reviewed-on: https://go-review.googlesource.com/c/go/+/311380
Run-TryBot: Carlos Eduardo Seo <carlos.seo@linaro.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Now that we can set experiments at build time instead of make.bash time,
we can actually write a test for field tracking!
Update #20014
This CL contains a test for the functionality fixed in CL 312069.
Change-Id: I7569a7057bbc7c88ae25ae7bf974b0c8a4e35be8
Reviewed-on: https://go-review.googlesource.com/c/go/+/312217
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently, in expand_calls, for each appearance of a named
variables's component, we add the named slot to f.Names list. If
a variable appears many times, we add it to f.Names many times.
Furthure, for each duplicated named slot, its entry in
f.NamedValues is a slice that contains all Values associated with
that name. This leads to quadratic behavior when iterating named
values like
for _, name := range f.Names {
for _, v := range f.NamedValues[name] {
...
}
}
This CL makes it not to add duplicated entries to f.Names.
Change-Id: I82a8d009db81ecf48b4577e0bca501feff677cdf
Reviewed-on: https://go-review.googlesource.com/c/go/+/312093
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
When rechecking for work after transitioning from a spinning to
non-spinning M, checking timers before GC isn't useful. That is, if
there is GC work available, it will run immediately and the updated
pollUntil is unused.
Move this check to just before netpoll, where pollUntil is used. While
this technically improves efficiency in the (rare) case that we find
GC work in this block, the primary motivation is simply to improve
clarity by moving the update closer to use.
For #43997
Change-Id: Ibc7fb308ac4a582875c200659c9e272121a89f3b
Reviewed-on: https://go-review.googlesource.com/c/go/+/308654
Trust: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
editRequirements does a lot of work in order to respect the upper
bounds of mustSelect, and as a result it doesn't provide many promises
about conserving other things (like root dependencies).
When we add modules for missing packages, we aren't dealing with upper
bounds at all, so we would rather avoid the upper-bound overhead and
preserve the root-dependency invariants instead.
(*loader).updateRequirements does exactly that; it just needs to be
told about the additional dependencies to add.
For #36460
Change-Id: Ie0f2bc0dde18026bbd23e51357bb1d725d201680
Reviewed-on: https://go-review.googlesource.com/c/go/+/310791
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The comment for the Requirements.rootModules field requires that it be
"sorted and capped to length". I noticed that we were not capping it
correctly — we were capping the local variable (the rorotModules
argument itself) but not the struct field. That prompted me to
question whether we were also at some point failing to sort it
correctly, so I decided to add an explicit check.
With the explicit check, all tests continue to pass.
For #36460
Change-Id: I6687de8ef8ecc5129fa8810d678e5673752fd27b
Reviewed-on: https://go-review.googlesource.com/c/go/+/310790
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
In CL 293689, I fused the mvs.Reqs calls that were formerly in MinReqs
and TidyBuildList into a single function, updateRoots, in the hope
that it expressed a fundamental operation. As I have been working on
the lazy equivalents, I have come to realize that these functions are
deeply related but fundamentally different.
In order to help me reason about the two different roles, I am making
the two functions separate once more, but leaving them colocated in
the code.
For #36460
Change-Id: I851d6d81fbfd84f39411e0d076ee72a9909c60ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/310629
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
This eliminates some awkwardly-stateful outside calls to
modload.{Disallow,Allow,}WriteGoMod.
Perhaps more importantly, it gives the loader the opportunity to
reload packages and revise dependencies after the tidied requirements
are computed. With lazy loading, dropping an irrelevant requirement
from the main module's go.mod file may (rarely) cause other test
dependencies for packages outside the main module to become
unresolved, which may require the loader to re-resolve those
dependencies, which may in turn add new roots and increase the
selected versions of modules providing other packages.
This refactoring allows the loader to iterate between tidying the
build list and reloading packages as needed, making the exact
sequencing of loading and tidying an implementation detail of the
modload package.
For #36460
For #40775
Change-Id: Ib6da3672f32153d5bd7d653d85e3672ab96cbe36
Reviewed-on: https://go-review.googlesource.com/c/go/+/310181
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Signals can be delivered on a different thread. There is no necessary
happens-before relationship between setting sig.inuse in signal_enable
and checking it in sigsend. It is theoretically possible, if unlikely,
that sig.inuse is set by thread 1, thread 2 receives a signal, does not
see that sig.inuse is set, and discards the signal. This could happen
if the signal is received immediately after the first call to signal_enable.
For #33174
Change-Id: Idb0f1c77847b7d4d418bd139e801c0c4460531d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/312131
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Don't let type parameters that are not filled in with concrete
type arguments escape from constraint type inference - such
inferred types are not "real".
While at it, implement a tparamsList.String method for debugging.
Fixes#45548.
Change-Id: I40f13ff7af08d0357a5c66234bfcdd0b7ed5fdd6
Reviewed-on: https://go-review.googlesource.com/c/go/+/311651
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Note that this removes an invariant:
v.Type().ConvertibleTo(t) might return true,
yet v.Convert(t) might panic nevertheless.
This is a fairly unavoidable consequence of the decision
to add the first-ever conversion that can panic.
ConvertibleTo describes a relationship between types,
but whether the conversion panics now depends on the value,
not just the type.
If this turns out to be a problem, we can add v.ConvertibleTo(t),
or something similar, to allow callers to avoid the panic.
This is the last of the changes needed to complete the implementation.
Fixes#395
Change-Id: I79b7e4dd87a67a47723e00a65d0b1ac6090371b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/301652
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Break the main components of the findrunnable spinning -> non-spinning
recheck out into their own functions, which simplifies both findrunnable
and the new functions, which can make use of fancy features like early
returns.
This CL should have no functional changes.
For #43997
For #44313
Change-Id: I6d3060fcecda9920a3471ff338f73d53b1d848a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/307914
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The code that does partially live in-register arg spilling is
currently guarded with GOEXPERIMENT=regabiargs. But on platforms
where GOEXPERIMENT=regabiargs is not enabled there are still tests
that use register args. Guard it with actual number of registers
used, so it covers both.
Should fix the freeBSD builder.
Change-Id: I0d3c49d7a2389096cb6b17ca35b9b4ce567bc91e
Reviewed-on: https://go-review.googlesource.com/c/go/+/311830
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
findrunnable has grown very large and hard to follow over the years.
Parts we can split out into logical chunks should help make it more
understandable and easier to change in the future.
The work stealing loop is one such big chunk that is fairly trivial to
split out into its own function, and even has the advantage of
simplifying control flow by removing a goto around work stealing.
This CL should have no functional changes.
For #43997.
For #44313.
Change-Id: Ie69670c7bc60bd6c114e860184918717829adb22
Reviewed-on: https://go-review.googlesource.com/c/go/+/307913
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Chris Hines <chris.cs.guy@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Add handling for TypeParams in NewMethodSet, to bring it in sync with
lookupFieldOrMethod. Also add a test, since we had none. I wanted this
fix to get gopls completion working with type params, but due to the
subtlety of lookupFieldOrMethod, I left a TODO to confirm that there are
no behavioral differences between the APIs.
Updates #45639
Change-Id: I16723e16d4d944ca4ecb4d87fc196815abb6fcff
Reviewed-on: https://go-review.googlesource.com/c/go/+/311455
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>
When creating the temporary for map functions, if the key
contains pointer, we need to create pointer-typed temporary. So
if the temporary is live across a function call, the pointer is
live.
Change-Id: Id6e14ec9def8bc7987f0f8ce8423caf1e3754fcb
Reviewed-on: https://go-review.googlesource.com/c/go/+/311379
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
When -clobberdead compiler flag is set, the compiler inserts
instructions that set dead slots a specific value. If the GC sees
this value as a live pointer, something is probably wrong. Crash.
Only do this on AMD64 for now, as it is the only platform where
compiler's clobberdead mode is implemented. And on AMD64 the
clobberdead address can never be a valid address.
Change-Id: Ica687b132b5d3ba2a062500d13264fa730405d11
Reviewed-on: https://go-review.googlesource.com/c/go/+/310330
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
reflect.callReflect and reflect.callMethod are called from special
functions makeFuncStub and methodValueCall. The runtime expects
that it can find the first argument (ctxt) at 0(SP) in
makeFuncStub and methodValueCall's frame. Normally callReflect and
callMethod already do not modify the argument, and keep it alive.
But the compiler-generated ABI wrappers don't do that. Special
case the wrappers to not clobber its arguments.
Change-Id: I1769f49b81c38eabe452d561001c418352814d86
Reviewed-on: https://go-review.googlesource.com/c/go/+/310889
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Checker.finals and the corresponding atEnd were added in CL 191418 as a
mechanism to postpone interface type comparison until after all
interfaces were complete. In the intervening CL 195837 we've adopted a
convention of ensuring that interfaces are complete before comparing
them. Since then we've also added the additional case of expansion for
lazily resolving syntax.
Checker.later defers resolution of types until points in the checking
pass where all reachable types can be fully type checked, so the concept
of finals should no longer be necessary.
Change-Id: I58818c1a6b605dccc9b0ecb3a1f6859c138175d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/299590
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>
As mentioned in #42765, calling "recvmsg" syscall on Linux should come
with "MSG_CMSG_CLOEXEC" flag.
For other systems which not supports "MSG_CMSG_CLOEXEC". ReadMsgUnix()
would check the header. If the header type is "syscall.SCM_RIGHTS",
then ReadMsgUnix() would parse the SocketControlMessage and call each
fd with "syscall.CloseOnExec"
Fixes#42765
Change-Id: I74347db72b465685d7684bf0f32415d285845ebb
GitHub-Last-Rev: ca59e2c9e0
GitHub-Pull-Request: golang/go#42768
Reviewed-on: https://go-review.googlesource.com/c/go/+/272226
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
mcall calls fn with an argument. Currently, in the regabi version
of mcall it does not reserve space for that argument's spill slot.
If the callee spills its argument, it may clobber things on the
g0 stack at 0(SP) (e.g. the old SP saved in cgocallback).
Reserve the space.
Change-Id: I85a314273cd996c7fac8fd0b03cd9033faae9c5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/311489
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Currently, if we have AX=a and BX=b, and we want to make a call
F(1, a, b), to move arguments into the desired registers it emits
MOVQ AX, CX
MOVL $1, AX // AX=1
MOVQ BX, DX
MOVQ CX, BX // BX=a
MOVQ DX, CX // CX=b
This has a few redundant moves.
This is because we process inputs in order. First, allocate 1 to
AX, which kicks out a (in AX) to CX (a free register at the
moment). Then, allocate a to BX, which kicks out b (in BX) to DX.
Finally, put b to CX.
Notice that if we start with allocating CX=b, then BX=a, AX=1,
we will not have redundant moves. This CL reduces redundant moves
by allocating them in different order: First, for inpouts that are
already in place, keep them there. Then allocate free registers.
Then everything else.
before after
cmd/compile binary size 23703888 23609680
text size 8565899 8533291
(with regabiargs enabled.)
Change-Id: I69e1bdf745f2c90bb791f6d7c45b37384af1e874
Reviewed-on: https://go-review.googlesource.com/c/go/+/311371
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
With defer/go wrapping and register arguments, some liveness info
changed and live.go test was disabled for regabi. This CL adds a
new one for regabi.
Change-Id: I65f03a6ef156366d8b76c62a16251c3e818f4b02
Reviewed-on: https://go-review.googlesource.com/c/go/+/311369
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
CL 256798 added compiler ability to retain only used interface methods,
by generating a mark relocation whenever an interface method is used. To
do that, the compiler needs the current function linker object.
However, for unnamed function "func _()", its linker object is nil,
causes the compiler crashes for code in #45258.
CL 283313 fixed the code in #45258 unintentionally, since when the
compiler now does not walk unnamed functions anymore.
This CL fixes the root issue, by making reflectdata.MarkUsedIfaceMethod
skips unnamed functions, and also adding regression test.
Fixes#45258
Change-Id: I4cbefb0a89d9928f70c00dc8a271cb61cd20a49c
Reviewed-on: https://go-review.googlesource.com/c/go/+/311130
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
TestScript sets the GOEXPERIMENT environment variable to the value of
buildcfg.GOEXPERIMENT() with the intent that tests can use this to
inspect the value of buildcfg.GOEXPERIMENT. This has the unfortunate
side-effect of also affecting the experiments enabled for all builds
done by TestScript. For the most part this is harmless, but
GOEXPERIMENT can be GOOS/GOARCH-sensitive, so if a test changes GOOS
or GOARCH, it will continue to use the GOEXPERIMENT from the host
GOOS/GOARCH rather than what makes sense (or is even allowed) in the
test's GOOS/GOARCH. In fact, prior to CL 307819, TestScript set
GOEXPSTRING instead of GOEXPERIMENT because it previously captured
objabi.Expstring(), so the captured value didn't affect the build.
There's only one experiment that actually uses TestScript's
GOEXPERIMENT and there's a much better way to write that test now such
that it doesn't need to read GOEXPERIMENT at all. Hence, this CL
rewrites this test and drops GOEXPERIMENT from TestScript.
This should fix the *-regabi builders.
Change-Id: I3fcbf1f21e1b471ebc0e953c31333645553ea24c
Reviewed-on: https://go-review.googlesource.com/c/go/+/310969
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Currently, specifying GOEXPERIMENT=regabi will turn on all regabi
sub-experiments, but GOEXPERIMENT=noregabi won't turn anything off.
Regabi also isn't a "real" experiment in the sense that nothing in the
code base should depend on it as an experiment flag (it should depend
on the appropriate sub-experiments).
Hence, drop Regabi from goexperiment.Flags and make "regabi" in
GOEXPERIMENT be a real alias for all of the sub-flags, so regabi will
turn on all of the sub-flags and noregabi will turn off all of the
sub-flags.
This way, once we enable the sub-experiments in the baseline
configuration, it will be easy to turn off with "noregabi".
For #40724.
Change-Id: I0fb95be42f756d412e729a396be607d629ae2bab
Reviewed-on: https://go-review.googlesource.com/c/go/+/310609
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
CL 310731 moved cmd/internal/objabi.defaultGOROOT to
internal/buildcfg.defaultGOROOT, but didn't update the place in the
linker that sets its value.
Fixes the failing reboot test on the GOEXPERIMENT builders.
Change-Id: I135b6bfc0fdadbe6cfc144d7aa55ca13519ba004
Reviewed-on: https://go-review.googlesource.com/c/go/+/310869
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Parser object resolution is an auxiliary feature in which the parser
attempts to resolve identifiers to their declarations. In functionality,
it significantly overlaps with go/types and in fact cannot be correctly
computed at parse-time without type information (for example, it is
generally not possible to resolve k in the composite lit c{k: v}). Due
to these limitations, it is of limited utility and rarely used.
Now that object resolution is isolated as a post-processing pass, it is
trivial to offer a parser mode that skips it entirely. This CL adds that
mode.
Fixes#45104
Change-Id: I5a2c05437e298964ad2039e1ff98e63d6efbd1af
Reviewed-on: https://go-review.googlesource.com/c/go/+/306149
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>
Type parameter resolution is a bit tricky: type parameters are in the
function scope, but unlike ordinary parameters may reference eachother.
When resolving the function scope, we must be careful about the order in
which objects are resolved and declared.
Using ordering allows us to avoid passing around temporary scopes for
field declarations.
Add a bunch of tests for this behavior, and skip "_" in resolution tests
as it just adds noise.
For #45221
Change-Id: Id080cddce3fd76396bf86ba5aba856aedf64a458
Reviewed-on: https://go-review.googlesource.com/c/go/+/304456
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>
The overview comments discuss readying goroutines, which is the most
common source of work, but timers and idle-priority GC work also require
the same synchronization w.r.t. spinning Ms.
This CL should have no functional changes.
For #43997
Updates #44313
Change-Id: I7910a7f93764dde07c3ed63666277eb832bf8299
Reviewed-on: https://go-review.googlesource.com/c/go/+/307912
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
findrunnable has a couple places where delta is recomputed from a new
pollUntil value. This proves to be a pain in refactoring, as it is easy
to forget to do properly.
Move computation of delta closer to its use, where it is more logical
anyways.
This CL should have no functional changes.
For #43997.
For #44313.
Change-Id: I89980fd7f40f8a4c56c7540cae03ff99e12e1422
Reviewed-on: https://go-review.googlesource.com/c/go/+/307910
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
In makeFuncStub and methodValueCall, it stores ctxt (DX) as an
argument of moveMakeFuncArgPtrs, and assumes it does not change
by the call. This is not guaranteed, and it does happen if
-clobberdead compiler flag is used. Store it somewhere else and
reload after the call.
Change-Id: I9307e3cf94db4b38305ab35494088386dfcbaae8
Reviewed-on: https://go-review.googlesource.com/c/go/+/310409
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
There was a race condition that could lead to child.serveRequest
removing the request ID before child.handleRequest had read the empty
FCGI_STDIN message that indicates end-of-stream which in turn could
lead to child.serveRequest blocking while trying to consume the
request body.
Now, we remove the request ID from within child.handleRequest after
the end of stdin has been detected, eliminating the race condition.
Since there are no more concurrent modifications/accesses
to child.requests, we remove the accompanying sync.Mutex.
Change-Id: I80c68e65904a988dfa9e3cceec1829496628ff34
GitHub-Last-Rev: b3976111ae
GitHub-Pull-Request: golang/go#42840
Reviewed-on: https://go-review.googlesource.com/c/go/+/273366
Trust: Damien Neil <dneil@google.com>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Simplified both tests significantly by removing logic for writing
the client/server side messages. The flake was likely because of a
race between the closing of the local pipe from inside the test
and closing of the pipe from within the handshakeContext goroutine.
Wait to close the local pipe in the test until after the test
has finished running.
Fixes#45106Fixes#45299
Change-Id: If7ca75aeff7df70cda03c934fa9d8513276d465d
Reviewed-on: https://go-review.googlesource.com/c/go/+/305250
Trust: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
Trust: Katie Hockman <katie@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
The build.Default context really needs to accurately describe
the default build context. The goexperiment tags being a special
case in the go command violates that rule and is the root cause
of the various try-bot failures blocking the enabling of regabi.
(The cleanups I made in golang.org/x/tools were long overdue
but are not strictly necessary for making regabi work; this CL is.)
Having moved the GOEXPERIMENT parsing into internal/buildcfg,
go/build can now use it to set up build.Default, in the new field
ToolTags, meant to hold toolchain-determined tags (for now,
just the experiments). And at the same time we can remove the
duplication of GOOS and GOARCH defaults.
And then once build.Default is set up accurately, the special case
code in cmd/go itself can be removed, and the special case code
in test/run.go is at least a bit less special.
Change-Id: Ib7394e10aa018e492cb9a83fb8fb9a5011a8c25b
Reviewed-on: https://go-review.googlesource.com/c/go/+/310732
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Austin Clements <austin@google.com>
mainPackagesOnly now includes non-main packages matched by literal
arguments in the returned slice, since their errors must be reported.
GoFilesPackages attaches the same error to its package if
opts.MainOnly is true. This changes the error output of 'go run'
slightly, but it seems like an imporovement.
For #42088
Change-Id: I8f2942470383af5d4c9763022bc94338f5314b07
Reviewed-on: https://go-review.googlesource.com/c/go/+/310829
Trust: Jay Conrod <jayconrod@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 xcoff writer has several "ldr.SymVersion(s) != 0" checks. The
intent of these is to check for file-local (or static) symbols. Prior
to the introduction of symbol ABIs, this was indeed equivalent since
only file-local symbols has non-zero versions, but ABIs also use the
symbol version space. This still happened to work until much more
recently because we were only ever cgo-exporting version 0 symbols,
but CL 309341 changed this, causing these checks to fail on symbols
that were okay to export.
Replace these checks with ldr.IsFileLocal(s).
This should fix the AIX builder.
(Originally based on CL 309772.)
Fixes#45553.
Updates #40724.
Change-Id: I0a3a7f621ad8f9fe078d34e667286275257691ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/310729
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Currently, when we about to emit code that sets the function
results and returns, it emits a VarDef. But in some cases, the
result node is actually live and holding useful data. VarDef
means that we are about to (re)initialize it so all previous
data are dead, but that is not true. Don't insert that.
Also don't add VarDef for register results. We are not going to
store anything (currently it doesn't cause problem, just
unnecessary).
Change-Id: I9dd3b70b4a3f5035af028b143fde8fafa2f11fa0
Reviewed-on: https://go-review.googlesource.com/c/go/+/310589
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
These functions take the address of an argument and expect to be able
to reach later arguments from that pointer. This means they must be
laid out sequentially in memory (using ABI0) and all arguments must be
live even though they don't all appear to be referenced. This is
exactly what go:cgo_unsafe_args does.
Without this, GOEXPERIMENT=regabi,regabiargs on windows/amd64 crashes
on runtime startup because the stdcall functions are called with their
arguments in registers, so taking the address of one of them has no
bearing on the memory locations of the following arguments.
With this, GOEXPERIMENT=regabi,regabiargs on windows/amd64 passes
all.bash.
For #40724.
Change-Id: I4a4d6a913f85799b43f61c234d21ebb113a9b527
Reviewed-on: https://go-review.googlesource.com/c/go/+/310733
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
PackageOpts is a new struct type accepted by package loading
functions. It initially has two fields: IgnoreImports, and
ModResolveTests. Previously, these were global variables set by
clients. We'll add more to this in the future.
For #40775
Change-Id: I6956e56502de836d3815ce788bdf16fc5f3e5338
Reviewed-on: https://go-review.googlesource.com/c/go/+/310669
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Currently, run.go sets GOEXPERIMENT build tags based on the
*difference* from the baseline experiment configuration, rather than
the absolute experiment configuration. This differs from cmd/go. As a
result, if we set a baseline configuration and don't override it with
a GOEXPERIMENT setting, run.go won't set any GOEXPERIMENT build tags,
instead of setting the tags corresponding to the baseline
configuration.
Fix this by making compile -V=goexperiment produce the full
GOEXPERIMENT configuration, which run.go can then use to set exactly
the right set of build tags.
For #40724.
Change-Id: Ieda6ea62f1a1fabbe8d749d6d09c198fd5ca8377
Reviewed-on: https://go-review.googlesource.com/c/go/+/310171
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This requires consolidating the register move operations into a
single case entry in asmout. These moves are also used to
sign/zero-extend register values.
Combine the three asmout cases for register moves. This allows
AMOVWZ and AMOVW to be handled with the same optab entries.
Likewise, remove the diagnostic error for non-zero constant
loads into R0 using the register move operations, it is not
possible to match this asmout case with a non-zero constant.
Finally, fix the load constant 0 via "MOV[BHW]{,Z} $0, Rx".
These now generate "li Rx, $0" instead of a zero/sign-extend
of the contents of R0.
Change-Id: Ia4a263661582f10feda27ee21cb121e05ea931dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/308190
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Trust: Carlos Eduardo Seo <carlos.seo@linaro.org>
The previous CL introduced macros for transitions from the Windows ABI
to the Go ABI. This CL does the same for SysV and uses them in almost
all places where we transition from the C ABI to the Go ABI.
Compared to Windows, this transition is much simpler and I didn't find
any places that were getting it wrong. But this does let us unify a
lot of code nicely and introduces some degree of abstraction around
these ABI transitions.
Change-Id: Ib6bdecafce587ce18fca4c8300fcf401284a2bcd
Reviewed-on: https://go-review.googlesource.com/c/go/+/309930
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
There are several assembly functions that transition from the Windows
ABI to the Go ABI. These all need to save all registers that are
callee-save in the Windows ABI and caller-save in the Go ABI and
prepare the register state for Go. However, they all do this slightly
differently and most of them don't save the necessary XMM registers
for this transition (which could corrupt them in the C caller).
Furthermore, now that we have a carefully specified Go ABI, it's clear
that none of these actually get all of the details 100% right.
So, unify this code into two macros in a shared header in
runtime/cgo/abi_amd64.h that handle all necessary registers and setup
and use these macros everywhere on Windows that handles transitions
from C to Go.
Change-Id: I62f41345a507aad1ca383814ac8b7e2a9ffb821e
Reviewed-on: https://go-review.googlesource.com/c/go/+/309769
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This function bounces between the C and Go ABIs a few times. This CL
narrows the scope of the Go -> C transition to just around the branch
that calls C. This lets us take advantage of C callee-save registers
to simplify the code a little.
Change-Id: I1ffa0b9e50325425c5ec66596978aeb6450a6b57
Reviewed-on: https://go-review.googlesource.com/c/go/+/309929
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
CL 308931 ported several runtime assembly functions to ABIInternal so
that compiler-generated ABIInternal calls don't go through ABI
wrappers, but it missed the runtime assembly functions that are
actually defined in internal/bytealg.
This eliminates the cost of wrappers for the BleveQuery and
GopherLuaKNucleotide benchmarks, but there's still more to do for
Tile38.
0-base 1-wrappers
sec/op sec/op vs base
BleveQuery 6.507 ± 0% 6.477 ± 0% -0.46% (p=0.004 n=20)
GopherLuaKNucleotide 30.39 ± 1% 30.34 ± 0% ~ (p=0.301 n=20)
Tile38IntersectsCircle100kmRequest 1.038m ± 1% 1.080m ± 2% +4.03% (p=0.000 n=20)
For #40724.
Change-Id: I0b722443f684fcb997b1d70802c5ed4b8d8f9829
Reviewed-on: https://go-review.googlesource.com/c/go/+/310184
Trust: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
According the armv8-a specification, the destination register of the ADDS/ADDSW/
SUBS/SUBSW instructions can not be RSP, the current implementation does not
check this and encodes this wrong instruction format as a CMN instruction. This
CL adds a check and test cases for this situation.
Change-Id: I92cc2f8e17dbda70f0dce8fddf1ca6d5d7730589
Reviewed-on: https://go-review.googlesource.com/c/go/+/309989
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: eric fang <eric.fang@arm.com>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Add in some missing global assignment ops to the list of globals ops
that should be traversed to look for generic function instantiations.
The most common other one for global assigments (and the relevant one
for this bug) is OAS2FUNC, but also look at global assigments with
OAS2DOTTYPE, OAS2MAPR, OAS2RECV, and OASOP.
Bonus small fix: get rid of -G=3 case in ir.IsAddressable. Now that we
don't call the old typechecker from noder2, we don't need this -G-3
check anymore.
Fixes#45547.
Change-Id: I75fecec55ea0d6f62e1c2294d4d77447ed9be6ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/310210
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This test expects 'go mod tidy' to fail if the existing module graph
has a bad checksum. However, there is no intrinsic reason why 'go mod
tidy' should fail in that case: the module contains no packages, and
thus no imports, so 'go mod tidy' can justifiably remove all
requirements without regard to any errors that may have already been
present in the module graph.
Adding a source file that imports a package from the module with the
bad checksum should guarantee that 'go mod tidy' reports the checksum
eror.
For #36460
Change-Id: I59734ac524031288bc03a11f58eed5abe2db76b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/309334
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
In CL 307909 we generate code that spills pointer-typed argument
registers if it is part of an SSA-able aggregate. The current
code spill the register unconditionally. Sometimes it is
unnecessary, because it is already spilled, or it is never live.
This CL reworks the spill generation. We move it to the end of
compilation, after liveness analysis, so we have information about
if a spill is necessary, and only generate spills for the
necessary ones.
Change-Id: I8d60be9b2c47651aeda14f5e2d1bbd207c134b26
Reviewed-on: https://go-review.googlesource.com/c/go/+/309331
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
The debug call tests currently assume that the target Go function is
ABI0; this is clearly no longer true when we switch to the new ABI, so
make the tests set up argument register state in the debug call handler
and copy back results returned in registers.
A small snag in calling a Go function that follows the new ABI is that
the debug call protocol depends on the AX register being set to a
specific value as it bounces in and out of the handler, but this
register is part of the new register ABI, so results end up being
clobbered. Use R12 instead.
Next, the new desugaring behavior for "go" statements means that
newosproc1 must always call a function with no frame; if it takes any
arguments, it closes over them and they're passed in the context
register. Currently when debugCallWrap creates a new goroutine, it uses
newosproc1 directly and passes a non-zero-sized frame, so that needs to
be updated. To fix this, briefly use the g's param field which is
otherwise only used for channels to pass an explicitly allocated object
containing the "closed over" variables. While we could manually do the
desugaring ourselves (we cannot do so automatically because the Go
compiler prevents heap-allocated closures in the runtime), that bakes in
more ABI details in a place that really doesn't need to care about them.
Finally, there's an old bug here where the context register was set up
in CX, so technically closure calls never worked. Oops. It was otherwise
harmless for other types of calls before, but now CX is an argument
register, so now that interferes with regular calls, too.
For #40724.
Change-Id: I652c25ed56a25741bb04c24cfb603063c099edde
Reviewed-on: https://go-review.googlesource.com/c/go/+/309169
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Alessandro Arzilli <alessandro.arzilli@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Named.SetTParams sets the type parameters for a named type.
Named.Orig returns the original generic type an instantiated
type is derived from. Added a new field orig for that purpose
and renamed the already existing orig field to fromRHS.
Finally, updated various comments.
Change-Id: Ic9d173e42740422d195713d8bdc62a54dc8c5f54
Reviewed-on: https://go-review.googlesource.com/c/go/+/309832
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Now that go/ast changes have been guarded behind the typeparams build
tag, we no longer have coverage for tests involving generic code.
Add a new testing step to cmd/dist to run go/... and cmd/gofmt tests
using -tags=typeparams.
Comment out parser object resolution assertions that currently fail, and
which will be fixed by CL 304456.
Fixes#44933
Change-Id: I481dd4246a016f410307865b6c6c2bb3c8e6e3bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/310071
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>
My rebase of https://golang.org/cl/300649 before submitting broke the
build (and tests) when using the typeparams build constraint. In a
subsequent CL I add test coverage back to cmd/dist.
This time, I've tested by running:
- go test -tags=typeparams go/...
- go test -tags=typeparams cmd/gofmt
All tests pass except for the new TestResolution/typeparams.go2, which I
will fix in a follow-up CL.
For #44933
Change-Id: I439d387841604cf43a90e2ce41dbe6bbbdb0306d
Reviewed-on: https://go-review.googlesource.com/c/go/+/310070
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>
Fixes this failure:
go test cmd/compile/internal/ssa -run TestStmtLines -v
=== RUN TestStmtLines
stmtlines_test.go:115: Saw too many (amd64, > 1%) lines without
statement marks, total=88263, nostmt=1930
('-run TestStmtLines -v' lists failing lines)
The failure has two causes.
One is that the first-line adjuster in code generation was relocating
"first lines" to instructions that would either not have any code generated,
or would have the statment marker removed by a different believed-good heuristic.
The other was that statement boundaries were getting attached to register
values (that with the old ABI were loads from the stack, hence real instructions).
The register values disappear at code generation.
The fixes are to (1) note that certain instructions are not good choices for
"first value" and skip them, and (2) in an expandCalls post-pass, look for
register valued instructions and under appropriate conditions move their
statement marker to a compatible use.
Also updates TestStmtLines to always log the score, for easier comparison of
minor compiler changes.
Updates #40724.
Change-Id: I485573ce900e292d7c44574adb7629cdb4695c3f
Reviewed-on: https://go-review.googlesource.com/c/go/+/309649
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The compiler currently emits an "*.args_stackmap" symbol for all
bodyless functions, so that asm functions will have the proper stack
map. At the moment the code in the compiler that emits args_stackmap
assumes ABI0; to avoid misleading stackmaps, turn off args_stackmap
generation for non-ABI0 asm functions.
Updates #40724.
Change-Id: Ia5e3528d56da5fb107e799bd658e52496ba4a331
Reviewed-on: https://go-review.googlesource.com/c/go/+/309790
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Change the assembler to enforce the requirement that ABIInternal
functions need to be NOSPLIT. At the moment all of the assembly
routines in the runtime that are defined as ABIInternal also
happen to be NOSPLIT, but this CL makes it mandatory.
Updates #40724.
Change-Id: Ief80d22de1782edb44b798fcde9aab8a93548722
Reviewed-on: https://go-review.googlesource.com/c/go/+/309789
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When callMethod calls the underlying method, after reflectcall
it gets the result registers in "Ints" slots but not in "Ptrs"
slots. If the GC runs at this point, it may lose track of those
pointers and free the memory they point to.
To make sure the GC sees the pointer results, copy "Ints" to
"Ptrs", and keep them alive until we return to the caller.
This fixes test/fixedbugs/issue27695.go with register ABI.
Change-Id: I4092c91bcbd6954683740a12d91d689900446875
Reviewed-on: https://go-review.googlesource.com/c/go/+/309909
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This change moves next_gc and last_next_gc into gcControllerState under
the names heapGoal and lastHeapGoal respectively. These are
fundamentally GC pacer related values, and so it makes sense for them to
live here.
Partially generated by
rf '
ex . {
memstats.next_gc -> gcController.heapGoal
memstats.last_next_gc -> gcController.lastHeapGoal
}
'
except for updates to comments and gcControllerState methods, where
they're accessed through the receiver, and trace-related renames of
NextGC -> HeapGoal, while we're here.
For #44167.
Change-Id: I1e871ad78a57b01be8d9f71bd662530c84853bed
Reviewed-on: https://go-review.googlesource.com/c/go/+/306603
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
This patch provides changes according to Austin's TODO. It just moves
calculation of base indexes of each root type from markroot function
to gcMarkRootPrepare.
Change-Id: Ib231de34e7f81e922762fc3ee2b1830921c0c7cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/279461
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
These variables are core to the pacer, and will be need to be non-global
for testing later.
Partially generated via
rf '
ex . {
gcPercent -> gcController.gcPercent
heapMinimum -> gcController.heapMinimum
}
'
The only exception to this generation is usage of these variables
in gcControllerState methods.
For #44167.
Change-Id: I8b620b3061114f3a3c4b65006f715fd977b180a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/306600
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
gcSetTriggerRatio's purpose is to set a bunch of downstream values when
we choose to commit to a new trigger ratio computed by the gcController.
Now that almost all the inputs it uses to compute the downstream values
are in gcControllerState anyway, make it a method of gcControllerState.
For #44167.
Change-Id: I1b7ea709e8378566f812ae3450ab169d7fb66aea
Reviewed-on: https://go-review.googlesource.com/c/go/+/306599
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
For the new export/import of node types, we were just missing setting
the types of the closure variables (which have the same types as the
captured variables) and the OCLOSURE node itself (which has the same
type as the Func node).
Re-enabled inlining of functions with closures.
Change-Id: I687149b061f3ffeec3244ff02dc6e946659077a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/308974
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This avoids a dependency on a *Checker when we create type parameters
outside the type checker proper, e.g. in an importer. There may be
better solutions but this does the trick for now.
Change-Id: Icf22c934970cb04c88c2729555ae6a79ef5a2245
Reviewed-on: https://go-review.googlesource.com/c/go/+/309830
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This change moves certain important but internal-only GC statistics from
memstats into gcController. These statistics are mainly used in pacing
the GC, so it makes sense to keep them in the pacer's state.
This CL was mostly generated via
rf '
ex . {
memstats.gc_trigger -> gcController.trigger
memstats.triggerRatio -> gcController.triggerRatio
memstats.heap_marked -> gcController.heapMarked
memstats.heap_live -> gcController.heapLive
memstats.heap_scan -> gcController.heapScan
}
'
except for a few special cases, like updating names in comments and when
these fields are used within gcControllerState methods (at which point
they're accessed through the reciever).
For #44167.
Change-Id: I6bd1602585aeeb80818ded24c07d8e6fec992b93
Reviewed-on: https://go-review.googlesource.com/c/go/+/306598
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
As we are taking its address, always zero it. In many cases the
temporary will be optimized out. But in case it does not (e.g. -N,
-race), this ensures it has the right liveness information.
May fix the noopt builder.
Change-Id: I3d5d617c276d2a1a1aaebff813b4cd60bc691592
Reviewed-on: https://go-review.googlesource.com/c/go/+/309771
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
This CL changes our approach to guarding type parameter functionality
and API. Previously, we guarded type parameter functionality with the
parser.parseTypeParams parser mode, and were in the process of hiding
the type parameter API behind the go1.18 build constraint.
These mechanisms had several limitations:
+ Requiring the parser.parseTypeParams mode to be set meant that
existing tooling would have to opt-in to type parameters in all
places where it parses Go files.
+ The parseTypeParams mode value had to be copied in several places.
+ go1.18 is not specific to typeparams, making it difficult to set up
the builders to run typeparams tests.
This CL addresses the above limitations, and completes the task of
hiding the AST API, by switching to a new 'typeparams' build constraint
and adding a new go/internal/typeparams helper package.
The typeparams build constraint is used to conditionally compile the new
AST changes. The typeparams package provides utilities for accessing and
writing the new AST data, so that we don't have to fragment our parser
or type checker logic across build constraints. The typeparams.Enabled
const is used to guard tests that require type parameter support.
The parseTypeParams parser mode is gone, replaced by a new
typeparams.DisableParsing mode with the opposite sense. Now, type
parameters are only parsed if go/parser is compiled with the typeparams
build constraint set AND typeparams.DisableParsing not set. This new
parser mode allows opting out of type parameter parsing for tests.
How exactly to run tests on builders is left to a follow-up CL.
Updates #44933
Change-Id: I3091e42a2e5e2f23e8b2ae584f415a784b9fbd65
Reviewed-on: https://go-review.googlesource.com/c/go/+/300649
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 change breaks out the GC pacer into its own file so that it'll be
easier to see the full implementation and change it. It also suggests an
obvious place to put tests (mgcpacer_test.go).
This includes all of gcControllerState, gcSetTriggerRatio, anything
related to GOGC, and all related globals and constants.
This is almost a clean move, except that globals and constants are
formatted into blocks instead of having a separate "var" declaration for
each one.
For #44167.
Change-Id: I85aa84ce85c6cfbe0b33e8a3c91cbe9dc41de8cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/306596
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Following CL 309029, this CL does the same thing for map
functions (mapaccess, mapassign, mapdelete).
For simplicity, always wrap "defer delete(m, k)". With
regabidefers enabled, this call is wrapped in a closure and the
rewriting happens automatically. Without regabidefers, it may not
be wrapped for certain key types, and then we'd need special
handling of the delete (because earlier the order pass does not
handle it). And we will turn on defer wrapping by default anyway.
Change-Id: I30663b1aa8e1d6f98e1fb81bf8c0c0ce607ab80b
Reviewed-on: https://go-review.googlesource.com/c/go/+/309510
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
This function is no longer used.
Eliminating this actually fixes several problems:
- It made assumptions about what registers memclrNoHeapPointers would
preserve. Besides being an abstraction violation and lurking
maintenance issue, this actively became a problem for regabi because
the call to memclrNoHeapPointers now happens through an ABI wrapper,
which is generated by the compiler and hence we can't easily control
what registers it clobbers.
- The amd64 implementation (at least), does not interact with the host
ABI correctly. Notably, it doesn't save many of the registers that
are callee-save in the host ABI but caller-save in the Go ABI.
- It interacts strangely with the NOSPLIT checker because it allocates
an entire M and G on its stack. It worked around this on arm64, and
happened to do things the NOSPLIT checker couldn't track on 386 and
amd64, and happened to be *4 bytes* below the limit on arm (so any
addition to the m or g structs would cause a NOSPLIT failure). See
CL 309031 for a more complete explanation.
Fixes#45530.
Updates #40724.
Change-Id: Ic70d4d7e1c17f1d796575b3377b8529449e93576
Reviewed-on: https://go-review.googlesource.com/c/go/+/309634
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Currently, Go functions exported to cgo have some confusion around
ABIs that leads to crashes. The cmd/cgo-generated C code references an
exported Go wrapper function (which calls the underlying exported user
function). The linker resolves this reference to the ABI0 entry-point
to that Go wrapper function because all host object references are
currently assumed to be to version 0 of a symbol. This gets passed via
crosscall2 and winds its way to cgocallbackg1, which puts this ABI0
entry-point into a function value and calls it. Unfortunately,
function values always use the ABIInternal calling convention, so
calling this ABI0 entry-point goes poorly.
Fix this by threading definition ABIs through the cgo export mechanism
so the linker can resolve host object references (which have no
concept of multiple ABIs) to the correct Go symbol. This involves a
few pieces:
- The compiler extends the cgo_export_{static,dynamic} directives that
get passed on to the linker with symbol definition ABIs.
- The linker parses the ABIs in the cgo_export_{static,dynamic}
directives to look up the right symbol to apply export attributes to
and put in the dynexp list.
- For internal linking, the linker's Loader structure tracks the right
symbol (in particular the right ABI) to resolve host object
references to, and we use this in all of the host object loaders.
- For external linking, we mangle only the non-ABIInternal symbols
now, so the external linker is able to resolve the correct reference
from host objects to Go symbols.
Updates #40724.
Change-Id: I70a0b1610596768c3f473745fa1a3e630afbf1a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/309341
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Currently, setCgoAttr populates the cgo_export_{static,dynamic} maps
with symbol names of exported symbols, which are then re-looked-up by
deadcode and setupdynexp, which in turn puts the re-looked-up symbols
in ctxt.dynexp. setCgoAttr already looked up the Syms, so simplify all
of this by making setCgoAttr populate ctxt.dynexp directly and
eliminating the cgo_export_{static,dynamic} maps. Recording Syms
directly also sets us up to use correct symbol versions for these
exports, rather than just assuming version 0 for all lookups.
Since setupdynexp doesn't really do any "setting up" of dynexp any
more with this change, we fold the remaining logic from setupdynexp
directly into addexport, where it has better context anyway. This also
eliminates a sorting step, since we no longer do a non-deterministic
map iteration to build the dynexp slice.
For #40724.
Change-Id: I3e1a65165268da8c2bf50d7485f2624133433260
Reviewed-on: https://go-review.googlesource.com/c/go/+/309340
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Currently, both loadcgo and setCgoAttr do some processing of
cgo_export_static and cgo_export_dynamic cgo directives, which means
they both have to parse them. There's no reason to do this in loadcgo,
so move all directive processing to setCgoAttr.
For #40724.
Change-Id: Icb3cdf7ef3517e866dd220e40a5f5dec7fd47e2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/309339
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
setCgoAttr takes a lookup function, but there's only a single call and
setCgoAttr already has access to the lookup function passed at that
call. Simplify setCgoAttr by eliminating the lookup parameter and
calling the lookup function directly.
For #40724.
Change-Id: Ib27c0fa2b88c387e30423365f7757e3ba02cf7d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/309338
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Both OpArgXXXReg and LoweredGetClosurePtr must come very early,
because they carry registers that are technically live on entry.
But no need to impose ordering requirement between them.
Change-Id: Iee1db6239a75e5b381e0ad25ba5503169333217b
Reviewed-on: https://go-review.googlesource.com/c/go/+/309629
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
When using the GCC thread sanitizer, it links in additional
code which uses TLS, which causes us to exceed the range of
the 16 bit TLS relocation used by statically compiled go
code.
Rewrite objabi.R_POWER_TLS_LE to handle 32b offsets when
linking internally or externally into an ELF binary. The
elf relocation translation is changed to generate a pair
of R_PPC64_TPREL16_HA/LO relocations instead of a single
R_PPC64_TPREL16.
Likewise, updating the above exposed some behavioral differences
in gnu ld which can rewrite TLS sequences. It expects the
sequence to generate a valid TLS address, not offset. This was
exposed when compiling PIC code. The proper fix is to generate
the full TLS address in the destination register of the
"MOVD tlsaddr, $Rx" pseudo-op. This removes the need to insert
special objabi.R_POWER_TLS relocations elsewhere.
Unfortunately, XCOFF (used by aix) doesn't appear to support 32
bit offsets, so we rewrite this back into a 16b relocation when
externally linking a static binary.
Fixes#45040
Change-Id: I1ee9afd0b427cd79888032aa1f60d3e265073e1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/302209
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Before register ABI, we always pass argument in memory, and the
compiler chooses interface conversion functions solely based on
the memory layout. As long as the two types have identical memory
layout, it is fine to mix and match, e.g. convT64 takes a uint64
argument, but it can be used for things like float64 or
struct { x [4]struct{}; y int64 }.
With register ABI, those types may be passed differently, e.g.
uint64 is passed in an integer register, float64 is passed in a
floating point register, the struct above is passed in memory.
I made a few attempts in the previous CLs to try to choose the
right function based on the argument type, but none of them is
really correct.
Instead, this CL changes it to always pass the argument in the
same type the runtime expects, and do conversion before the call
in the compiler. The conversion can be no-op (e.g. a named type
to its underlying type), direct (e.g. int64 to uint64), or
through memory (e.g. *(*uint64)(unsafe.Pointer(&arg))). This way,
the front end does not need to know the ABI. (It only needs to
know how to convert types, and it already does.)
TODO: do something similar for map functions.
Change-Id: I33fc780a47c3f332b765e09b5e527f52ea1d6b5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/309029
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Some codegen tests were written with the assumption that
arguments and results are in memory, and with a specific stack
layout. With the register ABI, the assumption is no longer true.
Adjust the tests to work with both cases.
- For tests expecting in memory arguments/results, change to use
global variables or memory-assigned argument/results.
- Allow more registers. E.g. some tests expecting register names
contain only letters (e.g. AX), but it can also contain numbers
(e.g. R10).
- Some instruction selection changes when operate on register vs.
memory, e.g. ADDQ vs. LEAQ, MOVB vs. MOVL. Accept both.
TODO: mathbits.go and memops.go still need fix.
Change-Id: Ic5932b4b5dd3f5d30ed078d296476b641420c4c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/309335
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This is a follow-up to golang.org/cl/301369, which made the same change
in Frames.Next. The same logic applies here: a profile stack may have
been truncated at an invalid PC provided by cgoTraceback.
expandFinalInlineFrame will then try to lookup the inline tree and
crash.
The same fix applies as well: upon encountering a bad PC, simply leave
it as-is and move on.
Fixes#44971Fixes#45480
Change-Id: I2823c67a1f3425466b05384cc6d30f5fc8ee6ddc
Reviewed-on: https://go-review.googlesource.com/c/go/+/309109
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Michael Pratt <mpratt@google.com>
DragonFly BSD and OpenBSD do not implement mapping IPv4 addresses to
the IPv6 address space, and a runtime check can be avoided.
As the IP stack capabilities probe was only being called from
supportsIPv4map to check for this support, the OS-specific handling
can be added to this function rather than continuing to run the probe.
Change-Id: I5800c197b1be502a6efa79e3edd6356bde8637fb
GitHub-Last-Rev: 7eb67189cd
GitHub-Pull-Request: golang/go#45243
Reviewed-on: https://go-review.googlesource.com/c/go/+/304870
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
This adds support for reading the FreeDesktop Shared MIME-info Database on Unix systems, if it exists.
It should make lookups work on systems where the mime.types files are not present and
should lead to better mimetype lookup in general. If the shared mimetype database does not exist,
we will fall back to reading mime.types files in common locations.
Related to a bug on Solus bugtracker: https://dev.getsol.us/T9394
This change makes the mime package work on Solus.
Change-Id: If330c22ffe523bf31f7f10807a54fc8858517055
GitHub-Last-Rev: d5fbe8c41a
GitHub-Pull-Request: golang/go#45271
Reviewed-on: https://go-review.googlesource.com/c/go/+/305230
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
The runtime currently has two different notions of sweep completion:
1. All spans are either swept or have begun sweeping.
2. The sweeper has *finished* sweeping all spans.
Having both is confusing (it doesn't help that the documentation is
often unclear or wrong). Condition 2 is stronger and the theoretical
slight optimization that condition 1 could impact is never actually
useful. Hence, this CL consolidates both conditions down to condition 2.
Updates #45315.
Change-Id: I55c84d767d74eb31a004a5619eaba2e351162332
Reviewed-on: https://go-review.googlesource.com/c/go/+/307916
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
The runtime currently has two different notions of sweep completion:
1. All spans are either swept or have begun sweeping.
2. The sweeper has *finished* sweeping all spans.
Most things depend on condition 1. Notably, GC correctness depends on
condition 1, but since all sweep operations a non-preemptible, the STW
at the beginning of GC forces condition 1 to become condition 2.
runtime.GC(), however, depends on condition 2, since the intent is to
complete a complete GC cycle, and also update the heap profile (which
can only be done after sweeping is complete).
However, the way we compute condition 2 is racy right now and may in
fact only indicate condition 1. Specifically, sweepone blocks
condition 2 until all sweepone calls are done, but there are many
other ways to enter the sweeper that don't block this. Hence, sweepone
may see that there are no more spans in the sweep list and see that
it's the last sweepone and declare sweeping done, while there's some
other sweeper still working on a span.
Fix this by making sure every entry to the sweeper participates in the
protocol that blocks condition 2. To make sure we get this right, this
CL introduces a type to track sweep blocking and (lightly) enforces
span sweep ownership via the type system. This has the nice
side-effect of abstracting the pattern of acquiring sweep ownership
that's currently repeated in many different places.
Fixes#45315.
Change-Id: I7fab30170c5ae14c8b2f10998628735b8be6d901
Reviewed-on: https://go-review.googlesource.com/c/go/+/307915
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
For function results, if in register, we allocate spill slots
within the frame like locals. Currently, even if we never spill
to it the slot is still allocated. This CL makes it not allocate
the slot if it is never used.
Change-Id: Idbd4e3096cfac6d2bdfb501d8efde48ee2191d7b
Reviewed-on: https://go-review.googlesource.com/c/go/+/309150
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
If we are assigning a global address to an object that is
immediately returned from runtime.newobject, we omit the write
barrier because we know that both the source (static address) and
the destination (zeroed memory) do not need to be tracked by the
GC. Currently, the code that matches runtime.newobject's result
is specific to ABI0 layout. Update the code to work with register
ABI as well.
Change-Id: I7ab0833c6f745329271881ee4169956928a3a948
Reviewed-on: https://go-review.googlesource.com/c/go/+/308709
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
If v is a Copy of x, we will rewrite v to x. If v has a name
associated to it, let the name associate to x.
Under register ABI, this helps associate in-register Arg values
to the parameters' names. (But does not address all cases.)
Change-Id: I47c779e56c9d0823a88890497e32326bc0290f82
Reviewed-on: https://go-review.googlesource.com/c/go/+/309330
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
deferreturn has a dummy argument, that is only used for getting
the caller's SP. When generating deferreturn calls, the compiler
does not pass an actual argument or reserve its stack space.
Also, the current code is written with the assumption about where
the argument's address is on the stack. Currently this is correct
for both ABI0 and the register ABI, but it may change in the
future (e.g. if we remove dedicated spill slots). Remove the
argument.
Also remove the argument for getargp.
Change-Id: I96d07efa79a9c1a53ef3fc5adbecc11877e99dc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/309329
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Previously when the module cache specified by GOMODCACHE could not be
created an unhelpful message would be printed multiple times.
This happened because we were fetching several things in parallel then
failing to write them because we can't create the module cache.
We now check if the module cache can be created before fetching.
If not, the following message is printed:
go: could not create module cache
Fixes#45113
Change-Id: Ic9cec787411335edc7f4d0614fde7eaa8a957fb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/304571
Trust: Julie Qiu <julie@golang.org>
Run-TryBot: Julie Qiu <julie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
ExampleFrames with -trimpath failed since the content of Frame's File
changed when -trimpath is specified.
This CL fixes the issue by adding a new field OrigImportPath to
PackageInternal, which represents the original import path before adding
'_test' suffix for an external test package, and always using it to
create paths for the build tools.
Fixesgolang/go#43380
Change-Id: Ibbc947eb3ae08a7ba81f13f03af67c8745b5c69f
Reviewed-on: https://go-review.googlesource.com/c/go/+/279440
Run-TryBot: Hajime Hoshi <hajimehoshi@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Hajime Hoshi <hajimehoshi@gmail.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This patch provides a better long-term fix for the compiler's
zerorange() helper function to make it generate code friendly to the
register ABI.
CL 305829 did part of the work, but didn't properly handle the case
where the compiler emits a REP.STOSQ sequence; this patch changes the
REP code to make sure it doesn't clobber any incoming register
parameter values.
Also included is a test that is specifically written to trigger
the REP emit code in the compiler (prior to this, this code was
not being hit on linux/amd64 all.bash).
Updates #45372.
Updates #40724.
Change-Id: Iaf1c4e709e98eda45cd6f3aeebda0fe9160f1f42
Reviewed-on: https://go-review.googlesource.com/c/go/+/307829
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
If GOEXPERIMENT=regabidefer is enabled, newproc currently checks that
the call frame for new goroutines is empty. But there's one place in
the runtime (debugCallWrap), where we call newproc1, and it happens to
pass a non-empty frame. The current check didn't catch that. Move the
empty call frame check from newproc to newproc1 to catch this.
Updates #40724.
Change-Id: I9998faf1e07e7b7af88e06a8177127f998c40252
Reviewed-on: https://go-review.googlesource.com/c/go/+/309034
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Also, factor out recording of type/value information after
evaluating an expression into an operand, so that we can
use it when handling instantiation expressions manually.
Change-Id: I6776e6cc243558079d6a203f2fe0a6ae0ecc33de
Reviewed-on: https://go-review.googlesource.com/c/go/+/308371
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
First step towards lightening the load of Checker.exprInternal by
factoring out the code for index and slice expressions; incl. moving
a couple of related methods (Checker.index, Checker.indexedElts).
The code for handling index/slice expressions is copied 1:1 but
occurrences of "goto Error" are replaced by "x.mode = invalid"
followed by a "return".
Change-Id: I44048dcc4851dc5e24f5f169c17f536a37a6a676
Reviewed-on: https://go-review.googlesource.com/c/go/+/308370
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Include type information on exported function bodies, so that the
importer does not have to re-typecheck the body. This involves
including type information in the encoded output, as well as
avoiding some of the opcode rewriting and other changes that the
old exporter did assuming there would be a re-typechecking pass.
This CL could be considered a cleanup, but is more important than that
because it is an enabling change for generics. Without this CL, we'd
have to upgrade the current typechecker to understand generics. With
this CL, the current typechecker can mostly go away in favor of the
types2 typechecker.
For now, inlining of functions that contain closures is turned off.
We will hopefully resolve this before freeze.
Object files are only 0.07% bigger.
Change-Id: I85c9da09f66bfdc910dc3e26abb2613a1831634d
Reviewed-on: https://go-review.googlesource.com/c/go/+/301291
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Dan Scales <danscales@google.com>
Now that we are no longer calling the old typechecker at all during the
noder2 pass, we don't need to create and set an Ntype node ((which is
just a node representation of the type which we already know) for the
Name and Closure nodes. This should reduce memory usage a bit for -G=3.
Change-Id: I6b1345007ce067a89ee64955a53f25645c303f4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/308909
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
CL 307819 made GOEXPERIMENT=none mean "restore baseline experiment
configuration". This is arguably what you want because any deviation
from the baseline configuration is an "experiment". However, cmd/dist
requires this to mean "disable all experiment flags", even if some
flags are enabled in the baseline configuration, because its build
system doesn't know how to deal with any enabled experiment flags.
Hence, make GOEXPERIMENT=none mean "disable all experiment flags"
again.
Change-Id: I1e282177c3f62a55eb9c36566c75672808dae9b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/309010
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The mvsReqs implementation has always been a bit ambivalent about
whether the root requirements return the full build list, just the
direct requirements, or some hybrid of the two.
However, a full build list always requires the Target module as the
first entry, and it's easer to remove a redundant leading element from
a slice than to add one. Changing the mvsReqs field to contain
arbitrary roots instead of a full build list eliminates the need to
add redundant elements, at the cost of needing to remove redundant
elements in more places.
For #36460
Change-Id: Idd4c2d6bc7b66f67680037dab1fb9c2d1b40ab93
Reviewed-on: https://go-review.googlesource.com/c/go/+/308811
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
A module is deprecated if its author adds a comment containing a
paragraph starting with "Deprecated:" to its go.mod file. The comment
must appear immediately before the "module" directive or as a suffix
on the same line. The deprecation message runs from just after
"Deprecated:" to the end of the paragraph. This is implemented in
CL 301089.
'go list -m -u' loads deprecation messages from the latest version of
each module, not considering retractions (i.e., deprecations and
retractions are loaded from the same version). By default, deprecated
modules are printed with a "(deprecated)" suffix. The full deprecation
message is available in the -f and -json output.
'go get' prints deprecation warnings for modules named on the command
line. It also prints warnings for modules needed to build packages
named on the command line if those modules are direct dependencies of
the main module.
For #40357
Change-Id: Id81fb2b24710681b025becd6cd74f746f4378e78
Reviewed-on: https://go-review.googlesource.com/c/go/+/306334
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Currently, we allow R14, the current goroutine pointer, to be
clobbered in function bodies as long as the function restores it. This
is unnecessary complexity and could lead to confusing inconsistencies
with other architectures that can't simply restore it from TLS.
Updates #40724.
Change-Id: I4c052f0dd0b31d31afeb0c5aff05c314d7a852f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/309009
Trust: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
X15 must be zero at function calls and returns, but can be used as
scratch in the middle of a function. This allows things like memmove
and the hashing functions to use X15 temporarily, as long as they set
it back to 0 before returning.
This CL also clarifies the distinction between register meanings on
function call versus function return, since some of them have fixed
meanings at both call and return, while others only have a fixed
meaning at calls.
Updates #40724.
Change-Id: I9dad3abde42cd4d2788e8435cde6d55073dd75a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/308929
Trust: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
With the register ABI, it's important to inject sigpanic0 instead of
sigpanic so we can set up function entry registers. This was already
happening on most OSes. This CL gets the remaining ones.
Change-Id: I6bc4d912b6497e03ed54d0a9c1eae8fd099d2cea
Reviewed-on: https://go-review.googlesource.com/c/go/+/308930
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Changed RParams in types.Type to be a pointer to a slice, rather than a
slice itself, in order to reduce it from three words to one words, since
the large majority of types will not be generic or instantiated from a
generic type.
Additional cleanup: remove operation OTYPEINST, which we don't have need
of, since all type instantiations are either handled by types2 or happen
automatically during some form of stenciling.
Both of these are useful cleanups before the Go 1.17 freeze.
Change-Id: I61ad56b3c698b30d2cb5a2cdd12263202c54f49c
Reviewed-on: https://go-review.googlesource.com/c/go/+/308770
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Softfloat mode with register ABI is not implemented yet. In
particular, we did not rewrite the float types in AuxCalls to
integer types, so arguments are still passed in floating point
registers, which do not exist in softfloat mode. To make it work
I think we may want to reorder softfloat pass with expand_calls
pass. We also need to rewrite the OpArgFloatRegs for the spilling
of non-SSA-able arguments, which may involve renumbering interger
arguments. Maybe in softfloat mode we want to just define the
ABI with 0 float registers. They are not fundamentally hard, but
may be not worth doing for the moment, as we don't use softfloat
mode on AMD64 anyway.
Run the test with noregabiargs. Also in the compiler reject
-d=softfloat if regabiargs is enabled.
Change-Id: I8cc0c2cfa88a138bc1338ed8710670245f1bd2cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/308710
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
With register ABI, the disassembly of the function may not
contain a "movq" instruction (which used to be e.g. storing
arguments to stack). Look for "jmp" instruction instead. This is
also in consistent with the test for Go assembly syntax.
Change-Id: Ifc9e48bbc4f85c4e4aace5981b3a0f8ae925f6d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/308652
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
0-sized fields do not affect how arguments are passed under the
register ABI. But it does affect the size and alignment of the
type, and may affect the choice of interface conversion function.
Specifically, struct { a [0]int32; b [4]byte } should be passed in
memory, therefore should not use convT32.
Change-Id: Idfa21af79b81c196b50253b0be1fa4edecd12b45
Reviewed-on: https://go-review.googlesource.com/c/go/+/308651
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Under register ABI, aggregates like [2]uint32 is passed
differently than a uint64. For now, don't use the fast version
of the map functions for non-trivial aggregates.
GOEXPERIMENT=regabi,regabiargs can now pass make.bash, modulo
staleness checks.
TODO: maybe find some way to use the fast functions. Maybe
unsafe-cast to uint32/64 then call the map function. But need to
make the type checker happy.
Change-Id: If42717280dde12636fb970798cf1ca8fb29a3d06
Reviewed-on: https://go-review.googlesource.com/c/go/+/308650
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
The helper function used by the compiler's walk phase to determine
whether a param can be passed in a single float register wasn't quite
correct (didn't allow for the possibility of struct with two fields,
first zero size and second float). Fix up the helper to take this
case into account.
Updates #40724.
Change-Id: I55b42a1b17ea86de1d696788f029ad3aae4a179c
Reviewed-on: https://go-review.googlesource.com/c/go/+/308689
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The go command salts cache hashes using runtime.Version() (the Go
version the go command was built with) in order to separate objects
built with different versions of Go.
CL 307820 added the active GOEXPERIMENTs to the result of
runtime.Version, which affected cmd/go's hash salt. Since dist builds
go_bootstrap with all GOEXPERIMENTs disabled, but then go_bootstrap
builds the final go binary with the GOEXPERIMENTs passed to make.bash,
if any GOEXPERIMENTs were passed, go_bootstrap and the final go binary
produce different cache hashes. At the very end of dist, it uses the
final go binary to check the hashes of all packages, but these hashes
were produced by go_bootstrap, so it concludes everything is stale.
This should fix the builders that enable GOEXPERIMENTs, including the
regabi and staticlockranking builders.
Change-Id: Ie389929dff6f7b6eff2b19a2f43507e72be5f32e
Reviewed-on: https://go-review.googlesource.com/c/go/+/308591
Trust: Austin Clements <austin@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Recent we changed from using gFromTLS to using gFromSP, which apparently
sometimes returns nil. This causes crashes when dereferenced. Fix that
by not checking for preemption in the case that gFromSP returns nil.
Fixes#44679.
Change-Id: I0199ebe7cd113379c5fa35c27932d913df79092a
Reviewed-on: https://go-review.googlesource.com/c/go/+/297390
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Create transformCompLit, which does the transformations done by
tcCompLit without the typechecking. This removes the final use of the
old typechecker in the noder2 pass.
Other changes:
- Used the transformCompLit in stringstorunelit(), which creates an
OCOMPLIT that needs transformation as well.
- Fixed one place in transformIndex where we were still using
typecheck.AssignConv, when we should be using its equivalent
noder.assignconvfn.
The go/test tests always run with -G=3, and I also tested that the "go
test" tests continue to run correctly with -G=3.
Change-Id: I4a976534ab7311cf2a5f43841026dbf7401e62b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/308529
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
This change adds the depth constants 'lazy' and 'eager', but leaves
the go117EnableLazyLoading constant set to false so that the depth in
effect is still always 'eager'.
The go117EnableLazyLoading constant can be toggled to true once the
module loader has been updated to maintain the lazy-loading invariants
in the go.mod file. In the meantime, this will allow me to
progressively replace uses of go117LazyTODO with real conditions and
locally toggle lazy-mode on to see which tests are still failing
(or which behaviors are missing test coverage).
For #36460
Change-Id: Ifd358265a3903a5000003c2072f28171f336e15c
Reviewed-on: https://go-review.googlesource.com/c/go/+/308515
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
runtime.panicIndex*/panicSlice* functions move the arguments in
the right place then tail calls goPanicIndex*/Slice* using
internal ABI. (It uses internal ABI to avoid wrappers, because
the callee needs to get the caller's PC, to know whether it panics
in the runtime.) This CL makes it to use the register ABI if it
is enabled.
Change-Id: Id2ebb51b4bfb3e9aa7cb66d0a9aee63fccee5ecd
Reviewed-on: https://go-review.googlesource.com/c/go/+/308649
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The function runtime.convT64 accepts a single uint64 argument, but the
compiler's rules in the walk phase for determining whether is it ok to
pass a value of type T to a call to runtime.convT64 were slightly off.
In particular the test was allowing a type T with size less than eight
bytes but with more than one internal element (e.g. a struct). This
patch tightens up the rules somewhat to prevent this from happening.
Updates #40724.
Change-Id: I3b909267534db59429b0aa73a3d73333e1bd6432
Reviewed-on: https://go-review.googlesource.com/c/go/+/308069
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
"Not found" and "no matching version" errors usually indicate the user
is offline or the proxy doesn't have a version of go.mod that could
provide retractions. 'go list -m -u' should still succeed.
We should still report unclassified errors though. Previously, we
reported most errors loading retractions but did not report errors
loading updates. This change makes those operations more consistent.
Fixes#45305
Change-Id: I2f23a566c9481bc7ff229a177f39d78f6a8aae77
Reviewed-on: https://go-review.googlesource.com/c/go/+/306572
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
However, still only trigger -mod=vendor automatically (and only apply
the more stringent Go 1.14 vendor consistency checks) if the 'go'
version is explicit. This provides maximal compatibility with Go 1.16
and earlier: Go 1.11 modules will continue not to fail vendor
consistency checks, but scripts that assume semantics up to Go 1.16
for unversioned modules will continue to work unmodified.
Fixes#44976
For #36460
Change-Id: Idb05ca320023f57249c71fc8079218e8991d1ff9
Reviewed-on: https://go-review.googlesource.com/c/go/+/308509
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
On Windows, TLS is uninitialized for C threads calling into Go code.
In this path, before calling into user Go code, we call into needm which
runs without an m, but whose purpose is to pick one up. While in Go
code, we may occasionally restore the G register from TLS for a number
of reasons. Rather than try to flag all these cases, given that needm
(and its callees) are already somewhat special, just set up a dummy TLS
space for it that's read-only. If it ever actually tries to write to
this space (it shouldn't), it will fail loudly. Otherwise, code that
restores the G register will simply load a zero value, but that's OK
since needm is careful never to require the G at any point, because it
doesn't yet have a valid G. Furthermore, by the time needm returns, it
will have set up TLS properly for a Windows C thread, so there's no need
to do anything extra afterwards.
For #40724.
Change-Id: I34e8095059817e4ee663505e89cda8785b634b98
Reviewed-on: https://go-review.googlesource.com/c/go/+/307872
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In expand_calls, OpSelectN occurs both before and after the rewriting.
Attempting to rewrite a post-expansion OpSelectN is bad.
(The only ones rewritten in place are the ones returning mem;
others are synthesized to replace other selection chains with
register references.)
Updates #40724.
Updates #44816#issuecomment-815258897.
Change-Id: I7b6022cfb47f808d3ce6cc796c067245f36047f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/308309
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
CL 307818 added a package that the runtime depends on, but didn't
update the list of runtime dependencies in this test.
This should fix the longtest builder failures.
Change-Id: I5f3be31b069652e05ac3db9b1ce84dd5dfe0f66f
Reviewed-on: https://go-review.googlesource.com/c/go/+/308469
Trust: Austin Clements <austin@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
t is the type of the function that was called
tv is the type of the result
This fixes the failures for
GOEXPERIMENT=regabi,regabiargs go test go test text/template
GOEXPERIMENT=regabi,regabiargs go test go test html/template
Updates #40724.
Change-Id: Ic9b02d72d18ff48c9de1209987cc39da619c2241
Reviewed-on: https://go-review.googlesource.com/c/go/+/308189
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Currently objabi.Experiments is set via side-effect from an init
function, which makes their initialization process somewhat unclear
(indeed, I've messed this up before) and opens the possibility of
accessing them from another init function before it's initialized.
Originally, this init function set several variables, but at this
point it sets only objabi.Experiments, so switch to just using a
variable initializer to make the initialization process clear.
Change-Id: Id0d2ac76ae463824bbf37a9305e8643a275f1365
Reviewed-on: https://go-review.googlesource.com/c/go/+/307821
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This adds the set of GOEXPERIMENTs to the build version if it differs
from the default set of experiments. This exposes the experiment
settings via runtime.Version() and "go version <binary>".
Change-Id: I143dbbc50f66a4cf175469199974e18848075af6
Reviewed-on: https://go-review.googlesource.com/c/go/+/307820
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Right now the rules around handling default-on experiments are
complicated and a bit inconsistent. Notably, objabi.GOEXPERIMENT is
set to a comma-separated list of enabled experiments, but this may not
be the string a user should set the GOEXPERIMENT environment variable
to get that list of experiments: if an experiment is enabled by
default but gets turned off by GOEXPERIMENT, then the string we report
needs to include "no"+experiment to capture that default override.
This complication also seeps into the version string we print for "go
tool compile -V", etc. This logic is further complicated by the fact
that it only wants to include an experiment string if the set of
experiments varies from the default.
This CL rethinks how we handle default-on experiments. Now that
experiment state is all captured in a struct, we can simplify a lot of
this logic. objabi.GOEXPERIMENT will be set based on the delta from
the default set of experiments, which reflects what a user would
actually need to pass on the command line. Likewise, we include this
delta in the "-V" output, which simplifies this logic because if
there's nothing to show in the version string, the delta will be
empty.
Change-Id: I7ed307329541fc2c9f90edd463fbaf8e0cc9e8ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/307819
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently there's knowledge about the list of GOEXPERIMENTs in a few
different places. This CL introduces a new package and consolidates
the list into one place: the internal/goexperiment.Flags struct type.
This package gives us a central place to document the experiments as
well as the GOEXPERIMENT environment variable itself. It will also
give us a place to put built-time constants derived from the enabled
experiments.
Now the objabi package constructs experiment names by reflecting over
this struct type rather than having a separate list of these names
(this is similar to how the compiler handles command-line flags and
debug options). We also expose a better-typed API to the toolchain for
propagating enabled experiments.
Change-Id: I06e026712b59fe2bd7cd11a869aedb48ffe5a4b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/307817
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently, the objabi.Experiment fields use Go-standard CamelCase, the
GOEXPERIMENT environment variable flags and build tags use all
lowercase, and the asm macros use upper-case with underscores.
This CL makes asm use the lowercase names for macros so there is one
less spelling, e.g., GOEXPERIMENT_regabiargs. This also makes them
consistent with the GOOS_* and GOARCH_* macros, which also use lower
case.
Change-Id: I305cd89af5e8cd1a89cc148746c034bcfd76db3c
Reviewed-on: https://go-review.googlesource.com/c/go/+/307816
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
These are privileged instructions, and thus will never work with
usermode code. I don't think there is a case where this isn't
true. The motivation is to simplify handling of MOV* opcodes.
Assembler support for recognizing the MSR as a register is
retained.
Change-Id: Ic33f021a20057b64e69df8ea125e23dd8937e38d
Reviewed-on: https://go-review.googlesource.com/c/go/+/307814
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Trust: Carlos Eduardo Seo <carlos.seo@linaro.org>
update comment cause gc/reflect.go has been moved to reflectdata/reflect.go
In the commit (attach below), gc/reflect.go is moved to reflectdata/reflect.go
So the comment referring gc/reflect.go should be updated to reflectdata/reflect.go
There maybe other places that refers gc/reflect.go that should be updated.
I would work around it soon.
commit:
de65151e50e4895ab4c0
Change-Id: Ieed5c48049ffe6889c08e164972fc7825653ac05
GitHub-Last-Rev: eec9c2328d
GitHub-Pull-Request: golang/go#45421
Reviewed-on: https://go-review.googlesource.com/c/go/+/307930
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
When the write barrier pass emits typedmemmove/typedmemclr calls,
even the arguments are in registers, we still need to leave space
for the spill slots. Count that space. Otherwise when the callee
spills arguments it may clobber locals on the caller's frame.
Change-Id: I5326943427feaf66cab7658a5bef55b3baf5d345
Reviewed-on: https://go-review.googlesource.com/c/go/+/307824
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
Type parameters for methods are not part of the accepted language,
but maintaining the code for type-checking them ensures regularity
of the type checker implementation. For now, keep the flag internally,
disabled by default. The flag is set when running tests.
Change-Id: Ic99934bd00bd2608dc1178e4131f46dd1507f0f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/307214
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Constraint type inference is part of the proposed language.
Use an internal flag to control the feayure for debugging.
Change-Id: I7a9eaee92b5ffc23c25d9e68a729acc0d705e879
Reviewed-on: https://go-review.googlesource.com/c/go/+/306770
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Rather than splitting up type inference into function argument
and constraint type inference, provide a single Checker.infer
that accepts type parameters, type arguments, value parameters,
and value arguments, if any. Checker.infer returns the completed
list of type arguments, or nil.
Updated (and simplified) call sites.
Change-Id: I9200a44b9c4ab7f2d21eed824abfffaab68ff766
Reviewed-on: https://go-review.googlesource.com/c/go/+/306170
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
There's a problem in liveness, where liveness of any
part of an aggregate keeps the whole aggregate alive,
but the not-live parts don't get spilled. The GC
can observe those live-but-not-spilled slots, which
can contain junk.
A better fix is to change liveness to work
pointer-by-pointer, but that is also a riskier,
trickier fix.
To avoid this, in the case of
(1) an aggregate input parameter
(2) containing pointers
(3) passed in registers
pre-spill the pointers.
Updates #40724.
Change-Id: I6beb8e0a353b1ae3c68c16072f56698061922c04
Reviewed-on: https://go-review.googlesource.com/c/go/+/307909
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
CL 302231 added some optimization rules with instructions CSETM, CSINC,
CSINV, and CSNEG, but did not deal with the situation where flag is
constant, resulting in some cases that could be more optimized cannot
be optimized, and the FlagConstant value is passed to codegen pass. This
CL adds these missing rules.
Fixes#45359
Change-Id: I700608cfb9a6a768a18d1fd5d374d7e92aa6f838
Reviewed-on: https://go-review.googlesource.com/c/go/+/307650
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: eric fang <eric.fang@arm.com>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
A non-trivial Cgo program may need to use callbacks and interact with
go objects per goroutine. Because of the rules for passing pointers
between Go and C, such a program needs to store handles to associated
Go values. This often causes much extra effort to figure out a way to
correctly deal with: 1) map collision; 2) identifying leaks and 3)
concurrency.
This CL implements a Handle representation in runtime/cgo package, and
related methods such as Value, Delete, etc. which allows Go users can
use a standard way to handle the above difficulties.
In addition, the CL allows a Go value to have multiple handles, and the
NewHandle always returns a different handle compare to the previously
returned handles. In comparison, CL 294670 implements a different
behavior of NewHandle that returns a unique handle when the Go value is
referring to the same object.
Benchmark:
name time/op
Handle/non-concurrent-16 487ns ± 1%
Handle/concurrent-16 674ns ± 1%
Fixes#37033
Change-Id: I0eadb9d44332fffef8fb567c745246a49dd6d4c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/295369
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Zhang <cherryyz@google.com>
This change refactors the existing funcLayout tests and sets them up to
support the new register ABI by explicitly setting the register counts
to zero. This allows the test to pass if GOEXPERIMENT=regabiargs is set.
A follow-up change will add tests for a non-zero register count.
For #40724.
Change-Id: Ibbe061b4ed4fd70566eb38b9e6182dca32b81127
Reviewed-on: https://go-review.googlesource.com/c/go/+/307869
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
runtime.raceread/racewrite/racewriterange are functions that are
called from compiler instrumented code, follwoing ABIInternal.
They are assembly functions defined as ABIInternal in the runtime,
in order to avoid wrappers because they need to get the caller's
PC. This CL makes them to use the actual internal ABI.
Change-Id: Id91d73cf257f7b11a858958d85c38c4aa904d9c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/307812
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This significantly simplifies the implementation of editRequirements
in preparation for making it lazy. It should have no effect on which
version combinations are rejected by 'go get', nor on which solutions
are found if downgrades are needed.
This change results in a small but observable change in error logging.
Before, we were reporting an error line for each argument that would
have exceeded its specified version, attributing it to one arbitrary
cause. Now, we are reporting an error line for each argument that
would cause any other argument to exceed its specified version. As a
result, if one argument would cause two others to exceed their
versions, we will now report one line instead of two; if two arguments
would independently cause one other to exceed its version, we will now
report two lines instead of one.
This change may result in a small performance improvement. Because we
are now scanning and rejecting incompatible requirements earlier, we
may waste less time computing upgrades and downgrades that ultimately
won't matter due to conflicting constraints.
For #36460
Change-Id: I125aa09b4be749dc5bacef23a859333991960e85
Reviewed-on: https://go-review.googlesource.com/c/go/+/305009
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
When a function panics then recovers, it needs to return to the
caller with named results having the correct values. For
in-register results, we need to load them into registers at the
defer return path.
For non-open-coded defers, we already generate correct code, as
the defer return path is part of the SSA CFG and contains the
instructions that are the same as an ordinary return statement,
including putting the results to the right places.
For open-coded defers, we have a special code generation that
emits a disconnected block that currently contains only the
deferreturn call and a RET instruction. It leaves the result
registers unset. This CL adds instructions that load the result
registers on that path.
Updates #40724.
Change-Id: I1f60514da644fd5fb4b4871a1153c62f42927282
Reviewed-on: https://go-review.googlesource.com/c/go/+/307231
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Austin Clements <austin@google.com>
This is a simple workaround for a bug where runtime.GC() can return
before finishing a full sweep, causing gcTestIsReachable to throw. The
right thing is to fix runtime.GC(), but this should get this test
passing reliably in the meantime.
Updates #45315.
Change-Id: Iae141e6dbb26a9c2649497c1feedd4aaeaf540c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/307809
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Now that we use square brackets for instantiations, we
can tell type arguments from ordinary arguments without
"guessing" which permits a simpler implementation.
Specifically, replace use of Checker.exprOrTypeList with
Checker.exprList, and delete Checker.exprOrTypeList and
Checker.multiExprOrType.
Disable a test for an (esoteric) failure due to an
unrelated problem with error matching when running
the test.
Change-Id: I17f18fffc32f03fa90d93a68ebf56e5f2fcc9dab
Reviewed-on: https://go-review.googlesource.com/c/go/+/306171
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Now that we use square brackets for instantiations, we
can tell type arguments from ordinary arguments without
"guessing" which permits a simpler implementation.
While at it, also fix a minor position error for type
instantiations (now matching the code for function
instantiations).
Change-Id: I20eca51c5b06259703767b5906e89197d6cd595a
Reviewed-on: https://go-review.googlesource.com/c/go/+/306169
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This moves the two helper functions startPos and endPos into
the syntax package where they belong. Export the functions and
adjust dependent code.
Change-Id: I8170faeadd7cfa8f53009f81fcffd50ec0fc6a98
Reviewed-on: https://go-review.googlesource.com/c/go/+/305578
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The exact same test case covered by this file is also in
fixedbugs/bug121.go. No need for duplication.
Also, the actual syntax error tested (multiple method names
with a single signature) is an unlikely syntax error, and
only here for historical reasons (in the very beginning, this
was actually possible to write). Now, virtually nobody is making
this mistake.
Change-Id: I9d68e0aee2a63025f44e6338647f8250ecc3077a
Reviewed-on: https://go-review.googlesource.com/c/go/+/307789
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In TestMorestack, on macOS, for some reason it got most of the
samples in synchronization (e.g. pthread_cond_signal and
pthread_cond_wait) and sometimes in other "syscalls" (usleep,
nanotime1), and very few samples in stack copying, sometimes 0,
which causes the test to fail. Maybe synchronization is slower on
macOS? (It doesn't seem so to me.) Or it is the OS's accounting
problem, where it is more likely to trigger a profiling signal
at a syscall (or certain kinds of syscalls)?
As the test is really about whether it can connect stack copying
with the function that grows the stack, this CL makes it spend
more time in copying stack than synchronization. Now it's getting
~100 samples for stack copying on a 5 second interval on my
machine, and the test passes reliably.
Fixes#44418.
Change-Id: I3a462c8c39766f2d67d697598f8641bbe64f16ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/307730
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
When an SSA pass ICEs, it calls f.Fatalf, which terminates the
compiler. When GOSSAFUNC is set, the current pass is not written
to ssa.html. This CL makes it write ssa.html when it calls Fatalf,
for the ease of debugging.
Change-Id: I5d55e4258f0693d89c48c0a84984f2f893b0811d
Reviewed-on: https://go-review.googlesource.com/c/go/+/307509
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
C_LECON and C_SECON classifications are not generated on ppc64, however
there are many optab entries which match against them. Remove them to
resolve their related TODOs.
Likewise, reorder the optab entries for better readability.
Change-Id: I894a209a148014e5aa438b7303e7fbdda4727c4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/307429
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Trust: Carlos Eduardo Seo <carlos.seo@linaro.org>
(*gcSizes).Sizeof was requiring the last field of a zero-sized struct to
be at least one byte. But that rule (fix for #9401, see logic in
calcStructOffset) only applies to a struct that has some non-zero sized
fields. Fix (*gcSizes).Sizeof to have the logic like calcStructOffset.
Fixes running the gotests with -G=3 enabled.
Fixes#45390
Change-Id: I011f40e3de3a327392bbbb791b9422be75336313
Reviewed-on: https://go-review.googlesource.com/c/go/+/307549
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
This change eliminates the use of funcPC to determine if an PC is in
abort. Using funcPC for this purpose is problematic when using plugins
because symbols no longer have unique PCs. funcPC also grabs the wrapper
for runtime.abort which isn't what we want for the new register ABI, so
rather than mark runtime.abort as ABIInternal, use funcID.
For #40724.
Change-Id: I2730e99fe6f326d22d64a10384828b94f04d101a
Reviewed-on: https://go-review.googlesource.com/c/go/+/307391
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
In CL 305829 a problematic change was made to the compiler's
amd64-specific "zerorange" function. In zerorange the compiler uses
different sets of strategies depending on the size of the stack frame
it needs to zero; turns out that only on plan9-amd64 was it hitting
the final fallback strategy, which is a REPSTOSQ instruction. REPSTOSQ
takes RAX as an input, hence the changes made in CL 305829 (switching
to R13) were incorrect.
This patch restores the zerorange REPSTOSQ sequence (back to use RAX).
This is going to be an interim solution, since long term we need to
avoid touching RAX in the function prolog (since if the new register
ABI is in effect, it will hold a live value).
Fixes#45372.
Change-Id: Ic89a6a2a76d6e03b9fbda99275101e96b70fdf5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/307469
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David du Colombier <0intro@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
For most ABI wrappers we don't need it because we're never going
to defer an ABI wrapper for a function that then recovers, so
that's would just be unnecessary code in the ABI wrapper.
However, for functions that could be on the path of invoking a
deferred function that can recover (runtime.reflectcall,
reflect.callReflect, and reflect.callMethod), we do want the
panic+recover adjustment. Set the Wrapper flag for them.
Currently, those functions are defined as ABIInternal to avoid
the ABI wrappers. But the assembly code still follows ABI0
calling convention, which would not work with the register-based
calling convention. In particlar, it is not possible to make
runtime.reflectcall ABIInternal, because it tail calls
runtime.callNN functions, which are splittable. Later CLs will
make them ABI0 and use the wrappers.
Updates #40724.
Change-Id: Ic7a45bbc6f726d29b5cb4932951a9d71578dcaf6
Reviewed-on: https://go-review.googlesource.com/c/go/+/307236
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
There is a single function in the flag package whose implementation
uses string concatenation instead of the recommended strings.Builder.
The function was last touched before strings.Builder was introduced
in Go 1.10, which explains the old style code. This PR updates
the implementation.
Fixes#45392
Change-Id: Id2d8f1788765a0c4faaeb1e6870914f72b3c8442
GitHub-Last-Rev: 0e12fe3045
GitHub-Pull-Request: golang/go#45393
Reviewed-on: https://go-review.googlesource.com/c/go/+/307329
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
If the current time is computed from extend string
and the zone file contains multiple zones with the
same name, the lookup by name might find incorrect
zone.
This happens for example with the slim Europe/Dublin
time zone file in the embedded zip. This zone file
has last transition in 1996 and rest is covered by
extend string.
tzset returns IST as the zone name to use, but there
are two records with IST name. Lookup by name finds
the wrong one. We need to check offset and isDST too.
In case we can't find an existing zone, we allocate
a new zone so that we use correct offset and isDST.
I have renamed zone variable to zones as it shadowed
the zone type that we need to allocate the cached zone.
Fixes#45370
Change-Id: I79102e4873b6de20d8a65f8a3057519ff5fae608
Reviewed-on: https://go-review.googlesource.com/c/go/+/307190
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Currently, when converting a float (say float64), we use convT64
function. In the runtime convT64 expects a uint64 argument. In
the compiler, convT64 is defined as taking an "any" argument (so
it works with also uint64-like types such as [1]uint64). The "any"
type is instantiated with the concrete type in walk. So the
backend will see instances such as convT64([1]uint64).
Currently, float64 is treated as uint64-like. So the backend will
see convT64(float64). With a memory-based calling convention this
is fine. With a register-based calling convention, however, it
will pass the argument in a floating point register, whereas the
runtime expects the argument in an integer register (as it is
declared as uint64).
To fix this, this CL introduces runtime functions convT32F and
convT64F. They behave the same as convT32/convT64, but with a
float argument. In the compiler, use convT32F/convT64F to convert
float-like type to interface.
With this, "GOEXPERIMENT=regabi,regabiargs go test math fmt"
works.
Updates #40724.
Change-Id: I8b2e232096a95e4a7c4ab81795d77ef224ffaab3
Reviewed-on: https://go-review.googlesource.com/c/go/+/307232
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Currently, there are Wrapper and ABIWrapper attributes. Wrapper
is set when compiler generates an wrapper function (e.g. method
wrapper). ABIWrapper is set when compiler generates an ABI
wrapper. It also sets Wrapper flag for ABI wrappers.
Currently, they have the following meanings:
- Wrapper flag hides the frame from (normal) traceback.
- Wrapper flag enables special panic+recover adjustment, so it
can correctly recover when a wrapper function is deferred.
- ABIWrapper flag disables the panic+recover adjustment, because
we never defer an ABI wrapper that can recover.
This CL changes them to:
- Both Wrapper and ABIWrapper flags hide the frame from (normal)
traceback. (Setting one is enough.)
- Wrapper flag enables special panic+recover adjustment.
ABIWrapper flag no longer has effect on this.
This makes it clearer if we do want an ABI wrapper that also does
the panic+recover adjustment. In the old mechanism we'd have to
unset ABIWrapper flag, even if the function is actually an ABI
wrapper. In the new mechanism we just need to set both ABIWrapper
and Wrapper flags.
Updates #40724.
Change-Id: I7fbc83f85d23676dc94db51dfda63dcacdf1fc19
Reviewed-on: https://go-review.googlesource.com/c/go/+/307235
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Currently, the IR of tailcall does not connect the arguments with
the OTAILCALL node, so the arguments are not marshaled correctly.
Disable tail call for now.
Updates #40724.
Change-Id: I39de3ea8e19a23eb63768ab7282d2f870e9c266e
Reviewed-on: https://go-review.googlesource.com/c/go/+/307234
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Austin Clements <austin@google.com>
CL 307010 for ppc64.
I spent a long time trying to figure out how to use the carry bit from
ADDCCC to further simplify this (like what we do on arm64), but gave
up after I couldn't figure out how to access the carry bit without
just adding more instructions.
Change-Id: I6cad51b93616865b203cb16554f16121375aabbc
Reviewed-on: https://go-review.googlesource.com/c/go/+/307149
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
For stack frames larger than StackBig, the stack split prologue needs
to guard against potential wraparound. Currently, it carefully
arranges to avoid underflow, but this is complicated and requires a
special check for StackPreempt. StackPreempt is no longer the only
stack poison value, so this check will incorrectly succeed if the
stack bound is poisoned with any other value.
This CL simplifies the logic of the check, reduces its length, and
accounts for any possible poison value by directly checking for
underflow.
Change-Id: I917a313102d6a21895ef7c4b0f304fb84b292c81
Reviewed-on: https://go-review.googlesource.com/c/go/+/307010
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
The CV add changes according to TODO in Go source-code.
Internal atomic set does not comply with sync/atomic library and has shortage
operations for signed integers.
This patch extend internal atomic set by Int32 and Int64 operations. It's
implemented new aliases and asm versions of operations. As a result Cas64 was
replaced by Casint64 in findRunnableGCWorker without type casting.
Another purpose is unified structure of internal atomics' source code. Before,
assembly impementations for different archs were in different files. For
example, filename for AMD64 was asm_amd64.s, but filename for RISC-V was
atomic_riscv64.s. Some arches have both files without any meaning. So, assembly
files were merged and renamed to atomic_{$ARCH}.s filenames.
Change-Id: I29a05a7cbf5f4a9cc146e8315536c038af545677
Reviewed-on: https://go-review.googlesource.com/c/go/+/289152
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Confusingly, the set of all methods of an interface is currently set in
Fields field of types.Interface. This is true, even though there is
already an allMethods field (and AllMethods method) of types.Type.
Change so the set of all methods of an interface are stored in
Type.allMethods, and Interface.Fields is removed. Update the comments
for Methods and AllMethods.
Change-Id: Ibc32bafae86831cba62606b079a855690612c759
Reviewed-on: https://go-review.googlesource.com/c/go/+/307209
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Extract queryLatestVersionIgnoringRetractions, which returns the
version we should load retractions and deprecations from. This will be
shared with CheckDeprecations.
Rename ShortRetractionRationale to ShortMessage. This will be used to
shorten deprecation warnings as well.
For #40357
Change-Id: Ic1e0c670396bdb3bd87c7a97cf2b14ca58ea1d80
Reviewed-on: https://go-review.googlesource.com/c/go/+/306332
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Instead of accepting bool flags, ListModules now accepts ListMode, a
set of bit flags.
Four flags are defined. listRetracted is split into ListRetracted and
ListRetractedVersion to avoid ambiguity with -u, -retracted, and
-versions.
For #40357
Change-Id: Ibbbe44dc1e285ed17f27a6581f3392679f2124fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/306331
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
(*File).readdir allocates a fixed-size 8KiB buffer on unix systems that
cannot be reused. While it accounts for just a single allocation, it's
more than large enough to show up in profiles and make things quite a
bit slower.
Instead of allocating so often, use a sync.Pool to allow these buffers to
be reused. This has a large impact on readdir heavy workloads.
Package os benchmarks:
name old time/op new time/op delta
Readdirname-12 35.6µs ± 5% 18.1µs ± 4% -49.00% (p=0.000 n=10+10)
Readdir-12 142µs ± 1% 121µs ± 0% -14.87% (p=0.000 n=10+9)
ReadDir-12 44.0µs ± 6% 28.4µs ± 8% -35.58% (p=0.000 n=9+10)
name old alloc/op new alloc/op delta
Readdirname-12 14.4kB ± 0% 6.2kB ± 0% -57.08% (p=0.000 n=10+10)
Readdir-12 41.6kB ± 0% 33.4kB ± 0% -19.77% (p=0.000 n=10+9)
ReadDir-12 21.9kB ± 0% 13.7kB ± 0% -37.39% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
Readdirname-12 131 ± 0% 130 ± 0% -0.76% (p=0.000 n=10+10)
Readdir-12 367 ± 0% 366 ± 0% -0.27% (p=0.000 n=10+10)
ReadDir-12 249 ± 0% 248 ± 0% -0.40% (p=0.000 n=10+10)
A clunky benchmark I threw together that calls filepath.WalkDir on $GOMODCACHE:
name old time/op new time/op delta
WalkDir-12 91.2ms ±19% 48.7ms ± 0% -46.54% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
WalkDir-12 54.0MB ± 0% 7.6MB ± 0% -85.92% (p=0.000 n=8+9)
name old allocs/op new allocs/op delta
WalkDir-12 136k ± 0% 130k ± 0% -4.15% (p=0.000 n=8+8)
Change-Id: I00e4d48726da0e46c528ab205409afd03127b844
Reviewed-on: https://go-review.googlesource.com/c/go/+/302169
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
The switch case for fs.ModeDevice can only be reached for block devices
while character devices match fs.ModeDevice | fs.ModeCharDevice. This
would cause character devices to wrongly be reported as regular files.
This bug has existed since the switch was first introduced in CL 5624048.
Change-Id: Icdbedb015e5376b385b3115d2e4574daa052f796
Reviewed-on: https://go-review.googlesource.com/c/go/+/300891
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>
Calling fs.Sub with the result of fs.Sub multiple times creates a deep
call stack for Open and other methods. Enhance the fs.FS returned by
fs.Sub to implement fs.SubFS and reduce the call stack.
Fixes#45349
Change-Id: I10e10501e030176e10e2ae5ad260212e5c784bed
Reviewed-on: https://go-review.googlesource.com/c/go/+/306769
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 way, "go version" will report the "base version" or major version
that the tool corresponds to. This is the same version number that is
matched against build tags such as "go1.14" or "!go1.16".
Obtaining this version being built is non-trivial, since we can't just
import a package or query git. The added comments document the chosen
mechanism, based on a regular expression. It was chosen over AST parsing
as it would add a significant amount of code without much gain, given
how simple the goversion.go file is.
For #41116.
Change-Id: I653ae935e27c13267f23898f89c84020dcd6e194
Reviewed-on: https://go-review.googlesource.com/c/go/+/264938
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
Trust: Daniel Martí <mvdan@mvdan.cc>
Trust: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The changes between (equivalent, and reviewed) go/types/errors.go
and errors.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker.
The go/types version is significantly different as it handles
error codes but doesn't have some of the types2 changes.
Change-Id: I48f79ce31490db938c830df7d38e247d55d54f2d
Reviewed-on: https://go-review.googlesource.com/c/go/+/305577
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/stmt.go
and stmt.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker, and minor adjustments
to get the code slightly closer to go/types/stmt.go.
The primary differences compared to go/types are:
- use of syntax rather than go/ast package, with significant
differences in the representation of switch and select statements,
range clauses of for statements, and inc/dec statements.
- no reporting of error codes
- use or error_ for collecting addition error information
Change-Id: I4409f62ecafd0653e4c8ef087c2580d8f0544efc
Reviewed-on: https://go-review.googlesource.com/c/go/+/305576
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/check_test.go
and check_test.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker, and minor adjustments
to get the code slightly closer to go/types/check_test.go.
The primary differences compared to go/types are:
- use of syntax rather than go/ast package
- re-implemented mechanism for error matching and elimination
based on the syntax.ErrorMap mechanism (there's no exported
access to the syntax scanner)
- error matching permits for column tolerances because types2
column information doesn't match go/types column information
Change-Id: I8ae6bc93dfa2b517673b642064a1f09166755286
Reviewed-on: https://go-review.googlesource.com/c/go/+/305573
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/resolver.go
and resolver.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker.
The primary differences compared to go/types are:
- use of syntax rather than go/ast package
- not using a walkDecl abstraction for const/var/type declarations
Change-Id: Id8d7b069813149ca4eadbb61d1124b22c56a91b1
Reviewed-on: https://go-review.googlesource.com/c/go/+/305572
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This change removes two short-circuits for zero-sized types (zero-sized
structs and zero-sized struct fields) in the recursive cases of the ABI
algorithm, because this does not match the spec's algorithm, nor the
compiler's algorithm.
The failing case here is a struct with a field that is an array of
non-zero length but whose element type is zero-sized. This struct must
be stack-assigned because of the array, according to the algorithm.
The reflect package was register-assigning it.
Because there were two short-circuits, this can also appear if a struct
has a field that is a zero-sized struct but contains such an array,
also.
This change adds regression tests for both of these cases.
For #44816.
For #40724.
Change-Id: I956804170962448197a1c9853826e3436fc8b1ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/306929
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Leftover values that have been replaced can cause problems in later
passes (within expandCalls). For example, a struct select that
itself yields a struct will have a problematic rewrite, if the chance
is presented.
Updates #40724.
Change-Id: I1b445c47c301c3705f7fc0a9d39f1f5c84f4e190
Reviewed-on: https://go-review.googlesource.com/c/go/+/306869
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This change finishes off functionality register ABI for the reflect
package.
Specifically, it implements a call on a MakeFunc'd value by performing
the reverse process that reflect.Value.Call does, using the same ABI
steps. It implements a call on a method value created by reflect by
translating between the method value's ABI to the method's ABI.
Tests are added for both cases.
For #40724.
Change-Id: I302820b61fc0a8f94c5525a002bc02776aef41af
Reviewed-on: https://go-review.googlesource.com/c/go/+/298670
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
cgo_unsafe_args paragma indicates that the function (or its
callee) uses address and offsets to dispatch arguments, which
currently using ABI0 frame layout. Pin them to ABI0.
With this, "GOEXPERIMENT=regabi,regabiargs go run hello.go" works
on Darwin/AMD64.
Change-Id: I3eadd5a3646a9de8fa681fa0a7f46e7cdc217d24
Reviewed-on: https://go-review.googlesource.com/c/go/+/306609
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
asm_windows.s contains dummy references of syscall.loadlibrary
and syscall.getprocaddress, to trigger ABI wrapper/alias
generation to get ABI0 symbols for them. The comment says they
are called from assembly in other packages, but I couldn't find
where. They are defined in Go and only referenced in Go.
CL 179862 removed dummy references in the runtime. This CL
is similar, for the syscall package.
Also, with CL 306609, they will have ABI0 definitions anyway.
Change-Id: I5c7b0efb9762e4ad9c94f0beea8d053d8c8b2cd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/306709
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Currently, gcTestMoveStackOnNextCall doubles the stack allocation on
each call because stack movement always doubles the stack. That's
rather unfortunate if you're doing a bunch of stack movement tests in
a row that don't actually have to grow the stack because you'll
quickly hit the stack size limit even though you're hardly using any
of the stack.
Fix this by adding a special stack poison value for
gcTestMoveStackOnNextCall that newstack recognizes and inhibits the
allocation doubling.
Change-Id: Iace7055a0f33cb48dc97b8f4b46e45304bee832c
Reviewed-on: https://go-review.googlesource.com/c/go/+/306672
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
gcTestMoveStackOnNextCall can fail to move the stack in very rare
cases if there's an unfortunately timed preemption that clobbers the
stack guard. This won't happen multiple times in quick succession, so
make the test just retry a few times.
Change-Id: I247dc0551514e269e7132cee7945291429b0e865
Reviewed-on: https://go-review.googlesource.com/c/go/+/306671
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
In CL 305672 we preserve the pointer type of a store by just not
decomposing it. But this can be problematic when the source of
the store is a direct interface aggregate type (e.g.
struct { x map[int]int }.
In this CL we take a different approach: we preserve the store
type when generating the new store, but also decompose the source.
Fixes#45344.
Change-Id: If5dd496458dee95aa649c6d106b96a6cdcf3e60d
Reviewed-on: https://go-review.googlesource.com/c/go/+/306669
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This change causes finalizers, reflect calls, and Windows syscall
callbacks to assume the register ABI when GOEXPERIMENT=regabiargs is
set. That is, when all Go functions are using the new ABI by default,
these features should assume the new ABI too.
For #40724.
Change-Id: Ie4ee66b8085b692e1ff675f01134c9a4703ae1b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/306571
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Currently when register assignment fails we roll back all the abiParts
that were generated in the process. However, the total number of
registers also increases, but does not get rolled back. The result is
a very incorrect register assignment.
For #40724.
For #44816.
Change-Id: I1934ea5f95f7608ff2067166255099dbc9135e8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/306109
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
For struct like { { a int64; b int16 }; c int32 }, on 64-bit
machines the offset of c is 16, as the inner struct takes 16
bytes because we round up type size to its alignment. Update the
abi package's offset calculation to include this.
We only need to do this for struct type, because for all other
types its size is naturally aligned.
TODO: add a test.
Change-Id: I0c661768cb1ed3cb409b20a88b7e23e059f8e3e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/306449
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
The covers three kinds of uses:
1. Calls of closures from assembly. These are always ABIInternal calls
without wrappers. I went through every indirect call in the runtime
and I think mcall is the only case of assembly calling a Go closure in
a way that's affected by ABIInternal. systemstack also calls a
closure, but it takes no arguments.
2. Calls of Go functions that expect raw ABIInternal pointers. I also
only found one of these: callbackasm1 -> cgocallback on Windows. These
are trickier to find, though.
3. Finally, I found one case on NetBSD where new OS threads were
directly calling the Go runtime entry-point from assembly via a PC,
rather than going through a wrapper. This meant new threads may not
have special registers set up. In this case, a change on all other
OSes had already forced new thread entry to go through an ABI wrapper,
so I just caught NetBSD up with that change.
With this change, I'm able to run a "hello world" with
GOEXPERIMENT=regabi,regabiargs.
For #40724.
Change-Id: I2a6d0e530c4fd4edf13484d923891c6160d683aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/305669
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The logic for constructing calls in (*state).call is based around
targeted experiments with register-based calls. However, when the
register ABI is turned on everywhere, it currently doesn't account for
direct calls to non-ABIInternal functions. This CL adds a much simpler
path to (*state).call when regabiargs is turned on that looks at the
ABI of the target function.
For #40724.
Change-Id: I7f4f5fed8a5ec131bcf1ce5b9d94d45672a304cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/306410
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When regabiargs is enabled, a function's incoming ABI should be
determined solely by the function's own definition ABI (which is
usually ABIInternal, but can be ABI0 for ABI wrappers).
For example, the current code miscompiles ABI0 -> ABIInternal wrappers
when the experiment is enabled because it treats the wrapper itself as
being called as ABIInternal. This causes it to assume the incoming
arguments are already in registers, so usually the wrapper doesn't do
anything with the arguments because it thinks they're already in the
right place. With this fix, these wrappers now correctly load the
arguments from the stack and put them in registers.
For #40724.
Change-Id: Iec784e88ebc55d9e95e830ed7533aa336f3b1ca2
Reviewed-on: https://go-review.googlesource.com/c/go/+/306409
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Currently the prologue generated for WRAPPER assembly functions uses BX
and DI, but these are argument registers in the register-based calling
convention. Thus, these end up being clobbered when we want to have an
ABIInternal assembly function.
Define REGENTRYTMP0 and REGENTRYTMP1, aliases for the dedicated function
entry scratch registers R12 and R13, and use those instead.
For #40724.
Change-Id: Ica78c4ccc67a757359900a66b56ef28c83d88b3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/303314
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
For in-register arguments, it must have only a single copy of it
present in the function. If there are multiple copies, it confuses
the register allocator, as they are in the same register.
Change-Id: I55cb06746f08aa7c9168026d0f411bce0a9f93f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/306330
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Coupling object resolution to parsing complicates the parsing code, and
is a barrier to improvement. It requires passing around context such as
'lhs' or 'keyOk', and even then sometimes requires guess-work, such as
whether to resolve the key in a composite literal.
In this CL we delay object resolution to a separate pass after the file
parse completes. This makes it easier to see logic of scoping, and
removes state from the parsing code. This can enable subsequent
improvements such as optionally skipping object resolution, aligning the
parser with cmd/compile/internal/syntax, and allowing alternative
parsers to reuse object resolution.
The additional AST traversal appears to slow down parsing by around 4%.
That seems small enough not to worry about, especially since performance
sensitive users may eventually be able to disable object resolution
entirely, saving around 18% off the previous baseline. I'll also mail a
speculative CL showing how we can significantly mitigate the cost of
object resolution by transposing scopes.
For #45104
Change-Id: I98d9143fd77ae29e84ec7c3ae2fdb1139510da37
Reviewed-on: https://go-review.googlesource.com/c/go/+/304455
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>
With GOEXPERIMENT=regabidefer, all deferred functions take no
arguments and have no results (their signature is always func()).
Since the signature is fixed, we can replace all of the reflectcalls
in the defer code with direct closure calls.
For #40724.
Change-Id: I3acd6742fe665610608a004c675f473b9d0e65ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/306010
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
The changes between (equivalent, and reviewed) go/types/operand.go
and operand.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker.
The primary differences compared to go/types are:
- use of syntax rather than go/ast package
- explicit mode for untyped nil (rather than relying on the type)
Change-Id: I0c9c1c6153c55cb0550096bd966c9f0f1c766734
Reviewed-on: https://go-review.googlesource.com/c/go/+/305571
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/decl.go
and decl.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker and a minor comment
update.
The primary differences to go/types/decl.go are:
- use of syntax rather than go/ast package
- use of error_ objects to collect follow-on error info
- use of check.conf.Trace rather than global trace flag
- more aggressively marking variables as used in the presence errors
- not using a walkDecl abstraction for const/var/type declarations
Change-Id: I5cf26779c9939b686a3dbaa4d38fdd0c154a92ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/305570
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The setting of n.Use for a call node in transformCall() (and previously
in Call()), was not corrrect, since it was trying to use the number of
results of the call, rather than whether the call result was actually
used. We are already setting n.Use to ir.CallUseStmt if the call node is
directly a statement, so we just need to initialize n.Use to
ir.CallExprStmt in Call(), which will get changed to ir.CallUseStmt at
the statement level if it's used as a statement.
Enable inlining of stenciled functions (just disabled for testing,
easier debugging). The above n.Use fix was required for the inlining
to work for two cases.
Change-Id: Ie4ef6cd53fd4b20a4f3be31e629280909a545b7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/305913
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
During substitution of the function type during stenciling, we must set
the Name nodes of the param/result fields of the func type. We get those
name nodes from the substituted Dcl nodes of the PPARAMS and PPARAMOUTs.
But we must check that the names match with the Dcl nodes, so that we
skip any param fields that correspond to unnamed (in) parameters.
Added a few tests to typelist.go by removing a variety of unneeded
function parameter names.
Change-Id: If786961b64549da6f18eeeb5060ea58fab874eb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/305912
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Add new tests for object resolution driven by source files with
declarations and uses marked via special comments. This made it easier
to add test coverage while refactoring object resolution for #45104.
Tests are added to a new resolver_test.go file. In a subsequent CL the
resolver.go file will be added, making this choice of file name more
sensible.
For #45104
For #45136
For #45160
Change-Id: I240fccc0de95aa8f2d03e39c77146d4c61f1ef9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/304450
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
In expand_calls, when rewriting OpArg to OpArgIntReg/OpArgFloatReg,
avoid generating duplicates. Otherwise it will confuse the
register allocator: it would think the second occurance clobbers
the first's register, causing it to generate copies, which may
clobber other args.
Change-Id: I4f1dc0519afb77500eae1c0e6ac8745e51f7aa4e
Reviewed-on: https://go-review.googlesource.com/c/go/+/306029
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
exitsyscall0 contains two G variables: _g_ and gp. _g_ is the active G,
g0, while gp is the G to run (which just exited from a syscall).
It is passing _g_ to schedEnabled, which is incorrect; we are about to
execute gp, so that is what we should be checking the schedulability of.
While this is incorrect and should be fixed, I don't think it has ever
caused a problem in practice:
* g0 does not have g.startpc set, so schedEnabled simplifies to
just !sched.disable.user.
* This is correct provided gp is never a system goroutine.
* As far as I know, system goroutines never use entersyscall /
exitsyscall.
As far I can tell, this was a simple copy/paste error from exitsyscall,
where variable _g_ is the G to run.
While we are here, eliminate _g_ entirely, as the one other use is
identical to using gp.
Change-Id: I5df98a34569238b89ab13ff7012cd756fefb10dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/291329
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Handle the case where types can be partially inferred for an
instantiated function that is not immediately called. The key for the
Inferred map is the CallExpr (if inferring types required the function
arguments) or the IndexExpr (if types could be inferred without the
function arguments).
Added new tests for the case where the function isn't immediately called
to typelist.go.
Change-Id: I60f503ad67cd192da2f2002060229efd4930dc39
Reviewed-on: https://go-review.googlesource.com/c/go/+/305909
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Change the amd64 version of 'zerorange' to avoid using RAX/RDI, since
it can be called in a context when one of these registers is live
(contains an incoming parameter).
Updates #40724.
Change-Id: Ibfa2b4e156b876354d4f8bd04eb8773c7056d948
Reviewed-on: https://go-review.googlesource.com/c/go/+/305829
Trust: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
When using cgo, some of the frames can be provided by cgoTraceback, a
cgo-provided function to generate C tracebacks. Unlike Go tracebacks,
cgoTraceback has no particular guarantees that it produces valid
tracebacks.
If one of the (invalid) frames happens to put the PC in the alignment
region at the end of a function (filled with int 3's on amd64), then
Frames.Next will find a valid funcInfo for the PC, but pcdatavalue will
panic because PCDATA doesn't cover this PC.
Tolerate this case by doing a non-strict PCDATA lookup. We'll still show
a bogus frame, but at least avoid throwing.
Fixes#44971
Change-Id: I9eed728470d6f264179a7615bd19845c941db78c
Reviewed-on: https://go-review.googlesource.com/c/go/+/301369
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The correct setting of t.nod is needed when exporting types. Make sure
we create instantiated named types correctly so t.nod is set.
New test file interfacearg.go that tests this (by instantiating a type
with an interface). Also has tests for various kinds of method
expressions.
Change-Id: Ia7fd9debd495336b73788af9e35d72331bb7d2b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/305730
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
After recent discussion about bodyless functions, their wrappers,
their stack maps, nosplit, and callbacks, I was inspired to go and
be sure that more defaults were sensible. This may not be all --
currently rtcall is "ABIDefault" which I think is correct, but I
am not 100% certain.
Updates #40724.
Change-Id: I95b14ee0e5952fa53e7fea9f6f5192358aa24f23
Reviewed-on: https://go-review.googlesource.com/c/go/+/304549
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Fix various small bugs related to delaying transformations due to type
params. Most of these relate to the need to delay a transformation when
an argument of an expression or statement has a type parameter that has
a structural constraint. The structural constraint implies the operation
should work, but the transformation can't happen until the actual value
of the type parameter is known.
- delay transformations for send statements and return statements if
any args/values have type params.
- similarly, delay transformation of a call where the function arg has
type parameters. This is mainly important for the case where the
function arg is a pure type parameter, but has a structural
constraint that requires it to be a function. Move the setting of
n.Use to transformCall(), since we may not know how many return
values there are until then, if the function arg is a type parameter.
- set the type of unary expressions from the type2 type (as we do with
most other expressions), since that works better with expressions
with type params.
- deal with these delayed transformations in subster.node() and convert
the CALL checks to a switch statement.
- make sure ir.CurFunc is set properly during stenciling, including
closures (needed for transforming return statements during
stenciling).
New test file typelist.go with tests for these cases.
Change-Id: I1b82f949d8cec47d906429209e846f4ebc8ec85e
Reviewed-on: https://go-review.googlesource.com/c/go/+/305729
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
CL 298669 implemented wrapping for defer/go calls so the function
being called with defer or go statement has no arguments. This
simplifies the compiler and the runtime, especially with the
new ABI.
Currently, it does not wrap functions that has no arguments but
only results. For defer/go calls, the results are not used. But
the runtime needs to allocate stack space for the callee to store
the results. Wrapping functions with results makes the runtime
simpler.
TODO: maybe not wrap if all results are in registers.
Updates #40724.
Change-Id: I74d2f4db1cbf9979afbcd846facb30d11d72ab23
Reviewed-on: https://go-review.googlesource.com/c/go/+/305550
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
CL 298669 implemented wrapping for defer/go calls so the function
being called with defer or go statement has no arguments. This
simplifies the compiler and the runtime, especially with the
new ABI.
If the called function does not have any argument, we don't need
to wrap. But the code missed the cases of method receiver, as
well as some apparent argumentless builtin calls which may later
be rewritten to having arguments (e.g. recover). This CL makes
sure to wrap those cases. Also add a check to ensure that go and
defer calls are indeed argumentless.
Handle "defer recover()" specially, as recover() is lowered to
runtime.gorecover(FP) where FP is the frame's FP. FP needs to be
evaluated before wrapping.
Updates #40724.
Change-Id: I2758b6c69ab6aa02dd588441a457fe28ddd0d5a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/304771
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Currently, for "defer i.M()" if i is nil it panics at the point of
defer statement, not when deferred function is called. We need to
do the nil check before wrapping it.
Updates #40724.
Change-Id: I62c669264668991f71999e2cf4610a9066247f9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/305549
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This CL adds a set of helper functions for testing GC interactions.
These are intended for use in the regabi signature fuzzer, but are
generally useful for GC tests, so we make them generally available to
runtime tests.
These provide:
1. An easy way to force stack movement, for testing stack copying.
2. A simple and robust way to check the reachability of a set of
pointers.
3. A way to check what general category of memory a pointer points to,
mostly so tests can make sure they're testing what they mean to.
For #40724, but generally useful.
Change-Id: I15d33ccb3f5a792c0472a19c2cc9a8b4a9356a66
Reviewed-on: https://go-review.googlesource.com/c/go/+/305330
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This CL restructures how we track function ABIs and generate ABI
wrappers in the compiler and adds import/export of ABIs across package
boundaries.
Currently, we start by tracking definition and referencing ABIs in two
global maps and eventually move some of this information into the
LSyms for functions. This complicates a lot of the existing code for
handling wrappers and makes it particularly hard to export ABI
information across packages. This change is built around instead
recording this information on the ir.Func.
First, this change replaces the global ABI def/ref maps with a type,
which makes the data flow and lifetime of this information clear in
gc.Main. These are populated during flag parsing.
Then, early in the front-end, we loop over all ir.Funcs to 1. attach
ABI def/ref information to the ir.Funcs and 2. create new ir.Funcs for
ABI wrappers. Step 1 is slightly subtle because the information is
keyed by linker symbol names, so we can't simply look things up in the
compiler's regular symbol table.
By generating ABI wrappers early in the front-end, we decouple this
step from LSym creation, which makes LSym creation much simpler (like
it was before ABI wrappers). In particular, LSyms for wrappers are now
created at the same time as all other functions instead of by
makeABIWrapper, which means we're back to the simpler, old situation
where InitLSym was the only thing responsible for constructing
function LSyms. Hence, we can restore the check that InitLSym is
called exactly once per function.
Attaching the ABI information to the ir.Func has several follow-on
benefits:
1. It's now easy to include in the export info. This enables direct
cross-package cross-ABI calls, which are important for the performance
of calling various hot assembly functions (e.g., internal/bytealg.*).
This was really the point of this whole change.
2. Since all Funcs, including wrappers, now record their definition
ABI, callTargetLSym no longer needs to distinguish wrappers from
non-wrappers, so it's now nearly trivial (it would be completely
trivial except that it has to work around a handful of cases where
ir.Name.Func is nil).
The simplification of callTargetLSym has one desirable but potentially
surprising side-effect: the compiler will now generate direct calls to
the definition ABI even when ABI wrappers are turned off. This is
almost completely unnoticeable except that cmd/internal/obj/wasm looks
for the call from runtime.deferreturn (defined in Go) to
runtime.jmpdefer (defined in assembly) to compile is specially. That
now looks like a direct call to ABI0 rather than going through the
ABIInternal alias.
While we're in here, we also set up the structures to support more
than just ABI0 and ABIInternal and add various additional consistency
checks all around.
Performance-wise, this reduces the overhead induced by wrappers from
1.24% geomean (on Sweet) to 0.52% geomean, and reduces the number of
benchmarks impacts >2% from 5 to 3. It has no impact on compiler speed.
Impact of wrappers before this change:
name old time/op new time/op delta
BiogoIgor 15.8s ± 2% 15.8s ± 1% ~ (p=0.863 n=25+25)
BiogoKrishna 18.3s ± 6% 18.1s ± 7% -1.39% (p=0.015 n=25+25)
BleveIndexBatch100 5.88s ± 3% 6.04s ± 6% +2.72% (p=0.000 n=25+25)
BleveQuery 6.42s ± 1% 6.76s ± 1% +5.31% (p=0.000 n=24+24)
CompileTemplate 245ms ± 3% 250ms ± 6% ~ (p=0.068 n=22+25)
CompileUnicode 93.6ms ± 2% 93.9ms ± 5% ~ (p=0.958 n=22+25)
CompileGoTypes 1.60s ± 2% 1.59s ± 2% ~ (p=0.115 n=24+24)
CompileCompiler 104ms ± 4% 104ms ± 3% ~ (p=0.453 n=22+25)
CompileSSA 11.0s ± 2% 11.0s ± 1% ~ (p=0.789 n=24+25)
CompileFlate 153ms ± 2% 153ms ± 1% ~ (p=0.055 n=21+20)
CompileGoParser 229ms ± 2% 230ms ± 2% ~ (p=0.305 n=21+22)
CompileReflect 585ms ± 5% 582ms ± 3% ~ (p=0.365 n=25+25)
CompileTar 211ms ± 1% 211ms ± 3% ~ (p=0.592 n=20+22)
CompileXML 282ms ± 3% 281ms ± 2% ~ (p=0.937 n=22+23)
CompileStdCmd 13.7s ± 3% 13.6s ± 2% ~ (p=0.700 n=25+25)
FoglemanFauxGLRenderRotateBoat 8.67s ± 1% 8.78s ± 1% +1.30% (p=0.000 n=25+25)
FoglemanPathTraceRenderGopherIter1 20.5s ± 2% 20.9s ± 2% +1.85% (p=0.000 n=25+25)
GopherLuaKNucleotide 30.1s ± 2% 31.1s ± 2% +3.38% (p=0.000 n=25+25)
MarkdownRenderXHTML 246ms ± 5% 250ms ± 1% +1.42% (p=0.002 n=25+23)
Tile38WithinCircle100kmRequest 828µs ± 6% 885µs ± 6% +6.85% (p=0.000 n=23+25)
Tile38IntersectsCircle100kmRequest 1.04ms ± 5% 1.10ms ± 7% +5.63% (p=0.000 n=25+25)
Tile38KNearestLimit100Request 974µs ± 4% 972µs ± 4% ~ (p=0.356 n=25+24)
[Geo mean] 588ms 595ms +1.24%
(https://perf.golang.org/search?q=upload:20210328.5)
And after this change:
name old time/op new time/op delta
BiogoIgor 15.9s ± 1% 15.8s ± 1% -0.48% (p=0.008 n=22+25)
BiogoKrishna 18.4s ± 6% 17.8s ± 6% -3.55% (p=0.008 n=25+25)
BleveIndexBatch100 5.86s ± 3% 5.97s ± 4% +1.88% (p=0.001 n=25+25)
BleveQuery 6.42s ± 1% 6.75s ± 1% +5.14% (p=0.000 n=25+25)
CompileTemplate 246ms ± 5% 245ms ± 2% ~ (p=0.472 n=23+23)
CompileUnicode 93.7ms ± 3% 93.5ms ± 2% ~ (p=0.813 n=22+23)
CompileGoTypes 1.60s ± 2% 1.60s ± 2% ~ (p=0.108 n=25+23)
CompileCompiler 104ms ± 3% 104ms ± 2% ~ (p=0.845 n=23+23)
CompileSSA 11.0s ± 2% 11.0s ± 2% ~ (p=0.525 n=25+25)
CompileFlate 152ms ± 1% 153ms ± 2% ~ (p=0.408 n=22+22)
CompileGoParser 230ms ± 1% 230ms ± 1% ~ (p=0.363 n=21+23)
CompileReflect 582ms ± 3% 584ms ± 4% ~ (p=0.658 n=25+25)
CompileTar 212ms ± 2% 211ms ± 2% ~ (p=0.315 n=23+24)
CompileXML 282ms ± 1% 282ms ± 1% ~ (p=0.991 n=23+22)
CompileStdCmd 13.6s ± 2% 13.6s ± 2% ~ (p=0.699 n=25+24)
FoglemanFauxGLRenderRotateBoat 8.66s ± 1% 8.69s ± 1% +0.28% (p=0.002 n=25+24)
FoglemanPathTraceRenderGopherIter1 20.5s ± 3% 20.5s ± 2% ~ (p=0.407 n=25+25)
GopherLuaKNucleotide 30.1s ± 2% 31.2s ± 2% +3.82% (p=0.000 n=25+25)
MarkdownRenderXHTML 246ms ± 3% 245ms ± 1% ~ (p=0.478 n=23+22)
Tile38WithinCircle100kmRequest 820µs ± 4% 856µs ± 5% +4.39% (p=0.000 n=24+25)
Tile38IntersectsCircle100kmRequest 1.05ms ± 6% 1.07ms ± 6% +1.91% (p=0.014 n=25+25)
Tile38KNearestLimit100Request 970µs ± 4% 970µs ± 3% ~ (p=0.819 n=22+24)
[Geo mean] 588ms 591ms +0.52%
(https://perf.golang.org/search?q=upload:20210328.6)
For #40724.
Change-Id: I1c374e32d4bbc88efed062a1b360017d3642140d
Reviewed-on: https://go-review.googlesource.com/c/go/+/305274
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
ir.Name.Func is non-nil for *almost* all function names. This CL fixes
a few more major cases that leave it nil, though there are still a few
cases left: interface method values, and algorithms generated by
eqFor, hashfor, and hashmem.
We'll need this for mapping from ir.Names to function ABIs shortly.
The remaining cases would be nice to fix, but they're all guaranteed
to be ABIInternal, so we can at least work around them.
For #40724.
Change-Id: Ifcfa781c78899ccea0bf155d80f8cfc27f30351e
Reviewed-on: https://go-review.googlesource.com/c/go/+/305271
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
CL 64811 removed dcopy. Update the comment in types.Sym.
The Russquake moved iexport.go. Update the path to it.
WRAPPER is now also used by ABI wrappers, so update the comment since
it's now more general than method wrappers.
Change-Id: Ie0df61dcef7168f6720838cd5c9a66adf546a44f
Reviewed-on: https://go-review.googlesource.com/c/go/+/305269
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When PSSSaltLength is set, the maximum salt length must equal:
(modulus_key_size - 1 + 7)/8 - hash_length - 2
and for example, with a 4096 bit modulus key, and a SHA-1 hash,
it should be:
(4096 -1 + 7)/8 - 20 - 2 = 490
Previously we'd encounter this error:
crypto/rsa: key size too small for PSS signature
Fixes#42741
Change-Id: I18bb82c41c511d564b3f4c443f4b3a38ab010ac5
Reviewed-on: https://go-review.googlesource.com/c/go/+/302230
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Discovered by Junchen Li on CL 246858, the comparison before p and z are
swapped can be simplified from
pe < ze || (pe == ze && (pm1 < zm1 || (pm1 == zm1 && pm2 < zm2)))
to
pe < ze || pe == ze && pm1 < zm1
because zm2 is initialized to 0 before the branch.
Change-Id: Iee92d570038df2b0f8941ef6e422a022654ab2d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/247241
Run-TryBot: Akhil Indurti <aindurti@gmail.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Under certain circumstances, the existing rules for bit operations can
produce code that writes beyond its intended bounds. For example,
consider the following code:
func repro(b []byte, addr, bit int32) {
_ = b[3]
v := uint32(b[0]) | uint32(b[1])<<8 | uint32(b[2])<<16 | uint32(b[3])<<24 | 1<<(bit&31)
b[0] = byte(v)
b[1] = byte(v >> 8)
b[2] = byte(v >> 16)
b[3] = byte(v >> 24)
}
Roughly speaking:
1. The expression `1 << (bit & 31)` is rewritten into `(SHLL 1 bit)`
2. The expression `uint32(b[0]) | uint32(b[1])<<8 | uint32(b[2])<<16 |
uint32(b[3])<<24` is rewritten into `(MOVLload &b[0])`
3. The statements `b[0] = byte(v) ... b[3] = byte(v >> 24)` are
rewritten into `(MOVLstore &b[0], v)`
4. `(ORL (SHLL 1, bit) (MOVLload &b[0]))` is rewritten into
`(BTSL (MOVLload &b[0]) bit)`. This is a valid transformation because
the destination is a register: in this case, the bit offset is masked
by the number of bits in the destination register. This is identical
to the masking performed by `SHL`.
5. `(MOVLstore &b[0] (BTSL (MOVLload &b[0]) bit))` is rewritten into
`(BTSLmodify &b[0] bit)`. This is an invalid transformation because
the destination is memory: in this case, the bit offset is not
masked, and the chosen instruction may write outside its intended
32-bit location.
These changes fix the invalid rewrite performed in step (5) by
explicitly maksing the bit offset operand to `BT(S|R|C)(L|Q)modify`. In
the example above, the adjusted rules produce
`(BTSLmodify &b[0] (ANDLconst [31] bit))` in step (5).
These changes also add several new rules to rewrite bit sets, toggles,
and clears that are rooted at `(OR|XOR|AND)(L|Q)modify` operators into
appropriate `BT(S|R|C)(L|Q)modify` operators. These rules catch cases
where `MOV(L|Q)store ((OR|XOR|AND)(L|Q) ...)` is rewritten to
`(OR|XOR|AND)(L|Q)modify` before the `(OR|XOR|AND)(L|Q) ...` can be
rewritten to `BT(S|R|C)(L|Q) ...`.
Overall, compilecmp reports small improvements in code size on
darwin/amd64 when the changes to the compiler itself are exlcuded:
file before after Δ %
runtime.s 536464 536412 -52 -0.010%
bytes.s 32629 32593 -36 -0.110%
strings.s 44565 44529 -36 -0.081%
os/signal.s 7967 7959 -8 -0.100%
cmd/vendor/golang.org/x/sys/unix.s 81686 81678 -8 -0.010%
math/big.s 188235 188253 +18 +0.010%
cmd/link/internal/loader.s 89295 89056 -239 -0.268%
cmd/link/internal/ld.s 633551 633232 -319 -0.050%
cmd/link/internal/arm.s 18934 18928 -6 -0.032%
cmd/link/internal/arm64.s 31814 31801 -13 -0.041%
cmd/link/internal/riscv64.s 7347 7345 -2 -0.027%
cmd/compile/internal/ssa.s 4029173 4033066 +3893 +0.097%
total 21298280 21301472 +3192 +0.015%
Change-Id: I2e560548b515865129e1724e150e30540e9d29ce
GitHub-Last-Rev: 9a42bd29a5
GitHub-Pull-Request: golang/go#45242
Reviewed-on: https://go-review.googlesource.com/c/go/+/304869
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
The cmd/pprof package currently uses golang.org/x/crypto/ssh/terminal
which - as of CL 258003 - is merely a wrapper around golang.org/x/term.
Thus, drop the dependency on golang.org/x/crypto/ssh/terminal and use
golang.org/x/term directly.
Change-Id: Ib15f1f110c338b9dba4a91a873171948ae6298a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/304691
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Pull out the tranformation part of the typechecking functions for:
- selector expressions (OXDOT)
- calls to builtin functions (which go through the typechecker loop
twice, once for the call and once for each different kind of
builtin).
Some of the transformation functions create new nodes that should have
the same type as the original node. For consistency, now each of the
transformation functions requires that the node passed in has its type
and typecheck flag set. If the transformation function replaces or adds
new nodes, it will set the type and typecheck flag for those new nodes.
As usual, passes all the gotests, even with -G=3 enabled.
Change-Id: Ic48b0ce5f58425f4a358afa78315bfc7c28066c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/304729
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
On ARM64, (external) linker generated trampoline may clobber R16
and R17. In CL 183842 we change Duff's devices not to use those
registers. However, this is not enough. The register allocator
also needs to know that these registers may be clobbered in any
calls that don't follow the standard Go calling convention. This
include Duff's devices and the write barrier.
Fixes#32773, second attempt.
Change-Id: Ia52a891d9bbb8515c927617dd53aee5af5bd9aa4
Reviewed-on: https://go-review.googlesource.com/c/go/+/184437
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Meng Zhuo <mzh@golangcn.org>
As suggested by Bryan in CL 249759, remove the forwarding aliases in
cmd/cover and use the symbols from golang.org/x/tools directly.
cmd/cover is not an importable package, so it is fine to remove these
exported symbols.
Change-Id: I887c5e9349f2dbe4c90be57f708412b844e18081
Reviewed-on: https://go-review.googlesource.com/c/go/+/304690
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This change avoids executing syscalls testing if IPv4 address mapping
is possible unless the socket being opened belongs to the AF_INET6
family.
In a pledged OpenBSD process, this test is only allowed when the
"inet" pledge is granted; however this check was also being performed
for AF_UNIX sockets (separately permitted under the "unix" pledge),
and would cause the process to be killed by the kernel. By avoiding
the IPv4 address mapping check until the socket is checked to be
AF_INET6, a pledged OpenBSD process using AF_UNIX sockets without the
"inet" pledge won't be killed for this misbehavior.
The OpenBSD kernel is not currently ready to support using UNIX domain
sockets with only the "unix" pledge (and without "inet"), but this is
one change necessary to support this.
Change-Id: If6962a7ad999b71bcfc9fd8e10d9c4067fa3f338
GitHub-Last-Rev: 3c5541b334
GitHub-Pull-Request: golang/go#45155
Reviewed-on: https://go-review.googlesource.com/c/go/+/303276
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Aaron Bieber <deftly@gmail.com>
Trust: Ian Lance Taylor <iant@golang.org>
This is a small helper file that provides a default importer
for the type checker tests. There is no go/types equivalent.
The actual change is removing the "// UNREVIEWED" marker.
Change-Id: Ic1f9858bdd9b818d9ddad754e072d9d14d8fb9b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/304252
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The only changes between (equivalent, and reviewed) go/types/examples directory
are in examples/types.go2. The go/types/examples/types.go2 file should be updated
accordingly.
$ f=examples/types.go2; diff $f $HOME/goroot/src/go/types/$f
1d0
< // UNREVIEWED
109c108
< var _ (T /* ERROR cannot use generic type T */ )[ /* ERROR unexpected \[ */ int]
---
> var _ (T /* ERROR cannot use generic type T */ )[ /* ERROR expected ';' */ int]
147a147,154
> // We accept parenthesized embedded struct fields so we can distinguish between
> // a named field with a parenthesized type foo (T) and an embedded parameterized
> // type (foo(T)), similarly to interface embedding.
> // They still need to be valid embedded types after the parentheses are stripped
> // (i.e., in contrast to interfaces, we cannot embed a struct literal). The name
> // of the embedded field is derived as before, after stripping parentheses.
> // (7/14/2020: See comment above. We probably will revert this generalized ability
> // if we go with [] for type parameters.)
149,152c156,158
< ( /* ERROR cannot parenthesize */ int8)
< ( /* ERROR cannot parenthesize */ *int16)
< *( /* ERROR cannot parenthesize */ int32)
< List[int]
---
> int8
> *int16
> *List[int]
155,156c161
< * /* ERROR int16 redeclared */ int16
< List /* ERROR List redeclared */ [int]
---
> * /* ERROR List redeclared */ List[int]
280a286
>
The actual changes are removing the "// UNREVIEWED" markers.
Change-Id: I8a80fa11f3c84f9a403c690b537973a53e1adc2c
Reviewed-on: https://go-review.googlesource.com/c/go/+/304250
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/example_test.go
and example_test.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker.
The primary differences to go/types/example_test.go are:
- use of syntax instead of go/ast package
- no ExampleMethodSet test (types2 doesn't have MethodSet)
- some code in ExampleInfo is disabled due to less precise
position information provided by the syntax tree
Change-Id: I035284357acc8ecb7849022b5a9d873ae2235987
Reviewed-on: https://go-review.googlesource.com/c/go/+/304249
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/api_test.go
and api_test.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker, the addition of the
TestConvertibleTo and TestAssignableTo tests, and adjustments to test
prefixes (genericPkg, brokenPkg to be in line with go/types).
There are several differences to go/types/api_test.go:
- use of syntax rather than go/ast package
- use of the parseSrc helper function
- TestTypesInfo test entries reflect different handling of untyped nil
- TestInferredInfo is (for go1.17) in another file controlled by a build
constraint in go/types
- TestSelection test is currently skipped (types2 position information
is not accurate enough)
- TestScopeLookupParent doesn't have access to a scanner and instead
relies on syntax.CommentsDo.
- Broken packages are assumed to contain generic code for the tests.
Change-Id: Ic14e6fb9d6bef5416df39e465b5994de76f84097
Reviewed-on: https://go-review.googlesource.com/c/go/+/304131
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/lookup.go
and lookup.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker.
Note: The function ptrRecv in types2/lookup.go is found in
methodset.go in go/types (methodset.go doesn't exist
in types2).
Change-Id: I48cfd3df0947becb4c3b5e55b89263917bcfbf16
Reviewed-on: https://go-review.googlesource.com/c/go/+/304129
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
The changes between (equivalent, and reviewed) go/types/check.go
and check.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker.
The primary differences to go/types/check.go are:
- use of syntax instead of go/ast package
- tracing is controlled via flag not the "trace" constant
Change-Id: I1c9998afb3e0b7e29f5b169d3a4054cf22841490
Reviewed-on: https://go-review.googlesource.com/c/go/+/304109
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Add -benchtime to the list of flags that allow caching test results.
If -benchtime is set without -bench, no benchmarks are run. The cache
does not need to be invalidated in this case.
If -benchtime is set with -bench, benchmarks are run. The cache is
invalidated due to the -bench flag in this case.
Fixes#44555
Change-Id: I2eb5c9f389a587d150fb984590d145251d0fa2dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/304689
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
On ppc64le, we need to insert a load to restore the toc
pointer in R2 after calling into plt stubs. Sometimes the
symbol data is loaded into readonly memory. This is the
case when linking with the race detector code.
Likewise, add extra checks to ensure we can, and are
replacing a nop.
Change-Id: Iea9d9ee7a5ba0f4ce285f4d0422823de1c037cb7
Reviewed-on: https://go-review.googlesource.com/c/go/+/304430
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Fix a bug in the go/defer desugar handling of keepalive arguments. The
go/defer wrapping code has special handling for calls whose arguments
are pointers that have been cast to "uintptr", so as to insure that
call "keepalive" machinery for such calls continues to work. This
patch fixes a bug in the special case code to insure that it doesn't
kick in for other situations where you have an unsafe.Pointer ->
uintptr argument (outside the keepalive context).
Fixes make.bat on windows with GOEXPERIMENT=regabidefer in effect.
Change-Id: I9db89c4c73f0db1235901a4fae57f62f88c94ac3
Reviewed-on: https://go-review.googlesource.com/c/go/+/304457
Trust: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
The changes between (equivalent, and reviewed) go/types/stdlib_test.go
and stdlib_test.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker, using the os package
instead of ioutil, and some comment adjustments. Also, bug251.go passes
because of recent changes.
The primary difference is in the firstComment function which
doesn't have access to a scanner and instead uses the syntax
package's CommentsDu function.
Change-Id: I946ffadc97e87c692f76f369a1b16cceee528477
Reviewed-on: https://go-review.googlesource.com/c/go/+/304130
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/assignments.go
and assignments.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker.
The primary differences to go/types/assignments.go are:
- use of syntax instead of go/ast package
- no reporting of error codes (for now)
- different handling of nil values (we can't use Typ[UntypedNil]
to represent an untyped nil because types2 gives such nil values
context-dependent types)
Change-Id: I5d8a58f43ca8ed2daa060c46842a6ebc11b3cb35
Reviewed-on: https://go-review.googlesource.com/c/go/+/304051
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/api.go
and api.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker.
The primary differences to go/types/api.go are:
- use of syntax instead of go/ast package
- use of simpler Error type (for now)
- additional exported Config flags
- different handling of nil values (we can't use Typ[UntypedNil]
to represent an untyped nil because types2 gives such nil values
context-dependent types)
Change-Id: I7d46b29d460c656d7a36fe70108a370383266373
Reviewed-on: https://go-review.googlesource.com/c/go/+/304050
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/expr.go
and expr.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker.
The primary differences to go/types/expr.go are:
- use of package syntax rather than ast
- no reporting of error codes in errors
- implicit conversions of untyped nil lead to a typed nil
(in go/types, nil remains untyped)
Change-Id: I1e235b20ebda597eb7ce597d1749f26431addde2
Reviewed-on: https://go-review.googlesource.com/c/go/+/303092
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This is intended to be a pure-refactoring change, with very little
observable change in the behavior of the 'go' command. A few error
messages have prefixes changed (by virtue of being attached to
packages or modules instead of the build list overall), and
'go list -m' (without arguments) no longer loads the complete module
graph in order to provide the name of the (local) main module.
The previous modload.buildList variable contained a flattened build
list, from which the go.mod file was reconstructed using various
heuristics and metadata cobbled together from the original go.mod
file, the package loader (which was occasionally constructed without
actually loading packages, for the sole purpose of populating
otherwise-unrelated metadata!), and the updated build list.
This change replaces that variable with a new package-level variable,
named "requirements". The new variable is structured to match the
structure of the go.mod file: it explicitly specifies the roots of the
module graph, from which the complete module graph and complete build
list can be reconstructed (and cached) on demand. Similarly, the
"direct" markings on the go.mod requirements are now stored alongside
the requirements themselves, rather than side-channeled through the
loader.
The requirements are now plumbed explicitly though the modload
package, with accesses to the package-level variable occurring only
within top-level exported functions. The structured requirements are
logically immutable, so a new copy of the requirements is constructed
whenever the requirements are changed, substantially reducing implicit
communication-by-sharing in the package.
For #36460
Updates #40775
Change-Id: I97bb0381708f9d3e42af385b5c88a7038e1f0556
Reviewed-on: https://go-review.googlesource.com/c/go/+/293689
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
This test is verifying that setting or unsetting an environment
variable in Go via the "os" package makes that change visible to the C
getenv function. The test has been failing on Windows since CL 304569;
it isn't clear to me whether it was running at all before that point.
On Windows the getenv and _putenv C functions are not thread-safe,
so Go's os.Setenv and os.Getenv use the SetEnvironmentVariable and
GetEnvironmentVariable system calls instead. That seems to work fine
in practice; however, changes via SetEnvironmentVariable are
empirically not visible to the C getenv function on certain versions
of Windows.
The MSDN getenv documentation¹ states that ‘getenv operates only on
the data structures accessible to the run-time library and not on the
environment “segment” created for the process by the operating system.
Therefore, programs that use the envp argument to main or wmain may
retrieve invalid information.’ That may be related to what we're
seeing here.
(https://github.com/curl/curl/issues/4774 describes this same behavior
observed in the curl project.)
¹https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/getenv-wgetenv?view=msvc-160#remarks
Updates #36705
Change-Id: I222792f75c650f32c5025b0fa3edab232ff66353
Reviewed-on: https://go-review.googlesource.com/c/go/+/304669
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Pull out the transformation part of the typechecking functions for:
- assignment statements
- return statements
- send statements
- select statements
- type conversions
- normal function/method calls
- index operations
The transform functions are like the original typechecking functions,
but with all code removed related to:
- Detecting compile-time errors (already done by types2)
- Setting the actual type of existing nodes (already done based on
info from types2)
- Dealing with untyped constants
Moved all the transformation functions to a separate file, transform.go.
Continuing with the same pattern, we delay transforming a node if it has
any type params in its args, marking it with a typecheck flag of 3, and
do the actual transformation during stenciling.
Assignment statements are tricky, since their transformation must be
delayed if any of the left or right-hands-sides are delayed.
Still to do are:
- selector expressions (OXDOT)
- composite literal expressions (OCOMPLIT)
- builtin function calls
Change-Id: Ie608cadbbc69b40db0067a5536cf707dd974aacc
Reviewed-on: https://go-review.googlesource.com/c/go/+/304049
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
os.Getwd notes that if the current directory can be reached via
multiple paths (due to symbolic links), Getwd may return any one
of them. A way to ensure that the desired path is used is to set
the PWD environment variable pointing to it.
The go generate command has started to update the PWD environment
variable as of CL 287152, which was the missing link previously
resulting in mkwinsyscall misunderstanding whether it's inside
the std lib when symbolic links are involved (issue 44079).
Now all that's left is for us to also set the PWD environment
variable when invoking the go command in the test, so that it
too knows the intended working directory path to use.
Fixes#44080.
Updates #44079.
Updates #43862.
Change-Id: I65c9d19d0979f486800b9b328c9b45a1a3180e81
Reviewed-on: https://go-review.googlesource.com/c/go/+/304449
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
On Windows, when calling into needm in cgocallback on a new thread that
is unknown to the Go runtime, we currently call through an ABI wrapper.
The ABI wrapper tries to restore the G register from TLS.
On other platforms, TLS is set up just enough that the wrapper will
simply load a nil g from TLS, but on Windows TLS isn't set up at all, so
there's nowhere for the wrapper to load from.
So, bypass the wrapper in the call to needm. needm takes no arguments
and returns no results so there are no special ABI considerations,
except that we must clear X15 which is used as a zero register in Go
code (a function normally performed by the ABI wrapper). needm is also
otherwise already special and carefully crafted to avoid doing anything
that would require a valid G or M, at least until it is able to create
one.
While we're here, this change simplifies setg so that it doesn't set up
TLS on Windows and instead provides an OS-specific osSetupTLS to do
that.
The result of this is that setg(nil) no longer clears the TLS space
pointer on Windows. There's exactly one place this is used (dropm) where
it doesn't matter anymore, and an empty TLS means that setg's wrapper
will crash on the return path. Another result is that the G slot in the
TLS will be properly cleared, however, which isn't true today.
For #40724.
Change-Id: I65c3d924a3b16abe667b06fd91d467d6d5da31d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/303070
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
We need to be careful that when doing value graph surgery, we not
re-substitute a value that has already been substituted. That can lead
to confusing a previous iteration's value with the current iteration's
value.
The simple fix in this CL just aborts the optimization if it detects
intertwined phis (a phi which is the argument to another phi). It
might be possible to keep the optimization with a more complicated
CL, but:
1) This CL is clearly safe to backport.
2) There were no instances of this abort triggering in
all.bash, prior to the test introduced in this CL.
Fixes#45175
Change-Id: I2411dca03948653c053291f6829a76bec0c32330
Reviewed-on: https://go-review.googlesource.com/c/go/+/304251
Trust: Keith Randall <khr@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
When a in-flight request is cancelled, (*Transport).cancelRequest is
called. The cancelRequest function looks up and invokes a cancel
function before returning. The function lookup happens with reqMu held,
but the cancel function is invoked after dropping the mutex.
If two calls to cancelRequest are made at the same time, it is possible
for one to return before the cancel function has been invoked.
This race causes flakiness in TestClientTimeoutCancel:
- The test cancels a request while a read from the request body is
pending.
- One goroutine calls (*Transport).cancelRequest. This goroutine
will eventually invoke the cancel function.
- Another goroutine calls (*Transport).cancelRequest and closes the
request body. The cancelRequest call returns without invoking
the cancel function.
- The read from the request body returns an error. The reader
checks to see if the request has been canceled, but concludes
that it has not (because the cancel function hasn't been invoked
yet).
To avoid this race condition, call the cancel function with the
transport reqMu mutex held.
Calling the cancel function with the mutex held does not introduce any
deadlocks that I can see. The only non-noop request cancel functions
are:
A send to a buffered channel:
https://go.googlesource.com/go/+/refs/heads/master/src/net/http/transport.go#1362
The (*persistConn).cancelRequest function, which does not cancel any
other requests:
https://go.googlesource.com/go/+/refs/heads/master/src/net/http/transport.go#2526Fixes#34658.
Change-Id: I1b83dce9b0b1d5cf7c7da7dbd03d0fc90c9f5038
Reviewed-on: https://go-review.googlesource.com/c/go/+/303489
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
I don't know why the test requires runtime.(*Frame).Next symbol
present in the binary under test. I assume it is just some
sanity check? With CL 268479 runtime.(*Frame).Next can be pruned
by the linker. Replace it with runtime.main which should always
be present.
May fix the longtest builders.
Change-Id: Id3104c058b2786057ff58be41b1d35aeac2f3073
Reviewed-on: https://go-review.googlesource.com/c/go/+/304431
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The size of the field may be smaller than the addend,
such is the case with R_PPC64_TOC16_HA/LO and similar
relocations.
Add an extra return value to ldelf.relSize to account for
addend size which may be larger than the relocated field,
and fix the related ppc64 relocations.
Such relocs can be seen in large PIC blobs such
as the ppc64le race detector included with golang.
Change-Id: I457186fea5d0ec5572b9bbf79bb7fa21a36cc1b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/303990
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
When converting a type T to a non-empty interface I, we build the
itab which contains the code pointers of the methods. Currently,
this brings those methods live (if the itab is live), even if the
interface method is never used. This CL changes the itab to use
weak references, so the methods can be pruned if not otherwise
live.
Fixes#42421.
Change-Id: Iee5de2ba11d603c5a102a2ba60440d839a7f9702
Reviewed-on: https://go-review.googlesource.com/c/go/+/268479
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
No valid operation should match those removed by this patch. They
kind of look as if they match X-form load/stores on ppc64, but the
second argument is always ignored when translating to machine code.
Similarly, it should be noted an X-form memory access encodes into
an Addr which is a classified as a ZOREG argument with a non-zero
index, and a register type Addr.
Change-Id: I1adbb020d1b2612b18949d0e7eda05dbb3e8a25c
Reviewed-on: https://go-review.googlesource.com/c/go/+/303329
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Carlos Eduardo Seo <carlos.seo@linaro.org>
Adds code to the compiler's "order" phase to rewrite go and defer
statements to always be argument-less. E.g.
defer f(x,y) => x1, y1 := x, y
defer func() { f(x1, y1) }
This transformation is not beneficial on its own, but it helps
simplify runtime defer handling for the new register ABI (when
invoking deferred functions on the panic path, the runtime doesn't
need to manage the complexity of determining which args to pass in
register vs memory).
This feature is currently enabled by default if GOEXPERIMENT=regabi or
GOEXPERIMENT=regabidefer is in effect.
Included in this CL are some workarounds in the runtime to insure that
"go" statement targets in the runtime are argument-less already (since
wrapping them can potentially introduce heap-allocated closures, which
are currently not allowed). The expectation is that these workarounds
will be temporary, and can go away once we either A) change the rules
about heap-allocated closures, or B) implement some other scheme for
handling go statements.
Change-Id: I01060d79a6b140c6f0838d6e6813f807ccdca319
Reviewed-on: https://go-review.googlesource.com/c/go/+/298669
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
TestContextCancel is a test that ensures a process is killed soon after
canceling the context, even if Wait is not called (#16222). The test
checks whether the process exited without calling Wait by writing some
data to its stdin.
Currently the test involves two goroutines writing to stdin and reading
from stdout. However the reading goroutine is not very necessary to
detect the process exit.
This patch simplifies the test by connecting the process stdout to
/dev/null.
For #42061
Change-Id: I0447a1c024ee5abb050c627ec3766b731b02181a
Reviewed-on: https://go-review.googlesource.com/c/go/+/303352
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In the process of refactoring ioutil.Discard to io.Discard in
CL 263141 "an" should have been changed to "a" but was likely
missed in the process.
This commit corrects the spelling of the documentation.
Change-Id: I0609c45878291f8f01560efc3f3e6fba191e095b
GitHub-Last-Rev: e3257ca272
GitHub-Pull-Request: golang/go#45190
Reviewed-on: https://go-review.googlesource.com/c/go/+/304209
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
The internal ABI spec was recently updated to include specific
language covering "past-the-end" pointers and structs containing
trailing zero-sized fields. Add a unit test that makes sure we do the
right thing in this case. Fix a couple comments in other unit tests.
Change-Id: I18d373d11e122aec74b316837843887272676c63
Reviewed-on: https://go-review.googlesource.com/c/go/+/303809
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Otherwise, the added test would fail in an unnecessary way:
go build example.com/cov/onlytest: no non-test Go files ...
The test script is mimicking other cover_pkgall_*.txt scripts, so it
similarly tests both GOPATH and module modes.
Fixes#27333.
Change-Id: Ie60be569b31d49b173a78556c0669a87ada6799e
Reviewed-on: https://go-review.googlesource.com/c/go/+/288292
Trust: Daniel Martí <mvdan@mvdan.cc>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Current MaxBytesReader behaviour differs from its documentation. It's
not similar enough to io.LimitReader. It panics when limit (n) < -1 and
returns [-1, <nil>] when limit (n) = -1. To fix that, we treat all
negative limits as equivalent to 0.
It would be possible to make MaxBytesReader analogically identical in
behaviour to io.LimitReader, but that would require to stop
maxBytesReader's Read from reading past the limit. Read always reads one
more byte (if possible) for non-negative limits and returns a non-EOF
error. This behaviour will now apply to all limits.
Fixes#45101
Change-Id: I25d1877dbff1eb4b195c8741fe5e4a025d01ebc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/303171
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Damien Neil <dneil@google.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
More cleanup to remove unnecessary parts of AuxCall.
Passed testing on arm64 (a link-register architecture)
in addition to amd64 so very likely okay.
(Gratuitously updated commit message to see if it will
correctly this time.)
Updates #40724
Change-Id: Iaece952ceb5066149a5d32aaa14b36755f26bb8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/303433
Trust: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Currently, the go resolver always send two DNS queries (A and AAAA) even
if tcp4/udp4/ip4 or tcp6/udp6/ip6 is used. This can cause unwanted
latencies when making IPv4-only or IPv6-only connections.
This change make go resolver aware of network parameter. Now, only one A
query is sent when tcp4/udp4/ip4 is used, and vice versa for
tcp6/udp6/ip6.
Fixes#45024
Change-Id: I815f909e6df5f7242cfc900f7dfecca628c3a2c8
GitHub-Last-Rev: 3d30c486de
GitHub-Pull-Request: golang/go#45016
Reviewed-on: https://go-review.googlesource.com/c/go/+/301709
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>
Negative constant shift counts are already handled
earlier in the code. No need anymore for this extra
section.
With this change, the shift code matches types2
with respect to the function logic.
Change-Id: Ic8b7f382271c79ab66021e30955cd9bac092332b
Reviewed-on: https://go-review.googlesource.com/c/go/+/303093
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Based on https://golang.org/cl/284256 for go/types.
Brings this code more in line with go/types.
Adjusted various tests to match new error messages which
generally are now better: for assignment errors, instead
of a generic "cannot convert" we now say "cannot use"
followed by a clearer reason as to why not.
Major differences to go/types with respect to the changed
files:
- Some of the new code now returns error codes, but they
are only used internally for now, and not reported with
errors.
- go/types does not "convert" untyped nil values to target
types, but here we do. This is unchanged from how types2
handled this before this CL.
Change-Id: If45336d7ee679ece100f6d9d9f291a6ea55004d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/302757
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
For additions, compares, and slices, create transform functions that do
just the transformations for those nodes by the typecheck package (given
that the code has been fully typechecked by types2). For nodes that have
no args with typeparams, we call these transform functions directly in
noder2. But for nodes that have args with typeparams, we have to delay
and call the tranform functions during stenciling, since we don't know
the specific types involved.
We indicate that a node still needs transformation by setting Typecheck
to a new value 3. This value means the current type of the node has been
set (via types2), but the node may still need transformation.
Had to export typcheck.IsCmp and typecheck.Assignop from the typecheck
package.
Added new tests list2.go (required delaying compare typecheck/transform
because of != compare in checkList) and adder.go (requires delaying add
typecheck/transform, since it can do addition for numbers or strings).
There are several more transformation functions needed for expressions
(indexing, calls, etc.) and several more complicated ones needed for
statements (mainly various kinds of assignments).
Change-Id: I7d89d13a4108308ea0304a4b815ab60b40c59b0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/303091
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Windows 10 >= 1607 allows CreateFile and friends to use long paths if
bit 0x80 of the PEB's BitField member is set.
In time this means we'll be able to entirely drop our long path hacks,
which have never really worked right (see bugs below). Until that point,
we'll simply have things working well on recent Windows.
Updates #41734.
Updates #21782.
Updates #36375.
Change-Id: I765de6ea4859dd4e4b8ca80af7f337994734118e
Reviewed-on: https://go-review.googlesource.com/c/go/+/291291
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Optimize some patterns into rev16/rev16w instruction.
Pattern1:
(c & 0xff00ff00)>>8 | (c & 0x00ff00ff)<<8
To:
rev16w c
Pattern2:
(c & 0xff00ff00ff00ff00)>>8 | (c & 0x00ff00ff00ff00ff)<<8
To:
rev16 c
This patch is a copy of CL 239637, contributed by Alice Xu(dianhong.xu@arm.com).
Change-Id: I96936c1db87618bc1903c04221c7e9b2779455b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/268377
Trust: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The current calculation method of constant pool size is:
c.pool.size = -c.pool.size & (funcAlign - 1)
c.pool.size += uint32(sz)
This doesn't make sense. This CL changes it as:
if q.As == ADWORD {
c.pool.size = roundUp(c.pool.size, 8)
}
c.pool.size += uint32(sz)
which takes into account the padding size generated by aligning DWORD to
8 bytes.
It's unnecessary to set the Pc field in addpool and addpool128 because
the Pc value will be reset in function span7, so remove the related lines.
Change-Id: I5eb8f259be55a6b97fc2c20958b4a602bffa4f88
Reviewed-on: https://go-review.googlesource.com/c/go/+/298609
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: eric fang <eric.fang@arm.com>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Move DWARF generation for global variables from the linker to the
compiler. This effectively parallelizes this part of DWARF generation,
speeds up the linker minutely, and gives us a slightly more rational
implementation (there was really no compelling reason to do DWARF gen
for globals in the linker).
Change-Id: I0c1c98d3a647258697e90eb91d1d8a9f6f7f376a
Reviewed-on: https://go-review.googlesource.com/c/go/+/295011
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
The explanatory comment and the associated version counter variable
for the helper routine "wrapCall" seem to have been left behind in
walk.go during the big refactoring -- move it back to where it should
be, next to wrapCall in stmt.go. Also fix a small buglet in the
comment itself.
Change-Id: I8637a838214b216581be59e01149a72282a46526
Reviewed-on: https://go-review.googlesource.com/c/go/+/303729
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
replaced old type-based logic with new abi-based logic;
earlier versions of this CL compared them for equality.
For not-in-a-register, they match everywhere tested.
also modified GetFrameOffset to make it more like the one it replaces;
the LocalsOffset is subtracted.
Change-Id: I65ce7f0646c493c277df6b6f46e4839a0d886ac9
Reviewed-on: https://go-review.googlesource.com/c/go/+/302072
Trust: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
runtime.save_g adds X18 to runtime.tls_g in order to have a pointer to
thread local storage. X18 represents a pointer to the TEB on ARM64 and
runtime.tls_g is set in runtime.wintls at initialization time. This
function calls TlsAlloc to allocate a "TLS slot", which is supposed to
index into NtCurrentTeb()->TlsSlots. So the full calculation we want is:
X18 + offsetof(TEB, TlsSlots) + 8*TlsAllocReturnValue
It makes sense to store the complete value of "offsetof(TEB,
TlsSlots) + TlsAllocReturnValue" into runtime.tls_g so that the
calculation can simplify to:
X18 + runtime.tls_g
But, instead of computing that, we're currently doing something kind of
strange, in which we:
- call TlsAlloc, which puts its return value into X0
- make sure X0 is less than 64, so we don't overflow
- set runtime.tls_g to 8*X1 + offsetof(TEB, TlsSlots)
The question is: why are we using X1 instead of X0? What is in X1?
Probably it was, by luck, zero before, and TlsAlloc returned zero, so
there was no problem. But on recent versions of Windows, X1 is some
other garbage value and not zero, so we eventually crash when trying to
dereference X18 + runtime.tls_g.
This commit fixes the problem by just computing:
runtime.tls_g = 8*X0 + offsetof(TEB, TlsSlots)
Fixes#45138.
Change-Id: I560426bae7468217bd183ac6c6eb4b56a3815b09
Reviewed-on: https://go-review.googlesource.com/c/go/+/303273
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Correct sign extension handling for consts on riscv64. This fixes a bug
in part exposed by CL 302609 - previously 64 bit consts were rewritten into
multiple 32 bit consts and the expansion would result in sign/zero extension
not being eliminated. With this change a MOVDconst with a 64 bit value can be
followed by a MOV{B,H,W}reg, which will be eliminated without actually
truncating to a smaller value.
Change-Id: I8d9cd380217466997b341e008a1f139bc11a0d51
Reviewed-on: https://go-review.googlesource.com/c/go/+/303350
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
If I change a rule in ARM64.rules to use the variable name "b" in a
conflicting way, rulegen would previously not complain, and the compiler
would later give a confusing error:
$ go run *.go && go build cmd/compile/internal/ssa
# cmd/compile/internal/ssa
../rewriteARM64.go:24236:10: b.NewValue0 undefined (type int64 has no field or method NewValue0)
Make rulegen complain early about those cases. Sometimes they might
happen to be harmless, but in general they can easily cause confusion or
unintended effect due to shadowing.
After the change, with the same conflicting rule:
$ go run *.go && go build cmd/compile/internal/ssa
2021/03/22 11:31:49 rule ARM64.rules:495 uses the reserved name b
exit status 1
Note that 24 existing rules were using reserved names. It seems like the
shadowing was harmless, as it wasn't causing typechecking issues nor did
it seem to cause unintended behavior when the rule rewrite code ran.
The bool values "b" were renamed "t", since that seems to have a
precedent in other rules and in the fmt package.
Sequential values like "a b c" were renamed to "x y z", since "b" is
reserved.
Finally, "typ" was renamed to "_typ", since there doesn't seem to be an
obviously better answer.
Passes all three of:
$ GOARCH=amd64 go build -toolexec 'toolstash -cmp' -a std
$ GOARCH=arm64 go build -toolexec 'toolstash -cmp' -a std
$ GOARCH=mips64 go build -toolexec 'toolstash -cmp' -a std
Fixes#45154.
Change-Id: I1cce194dc7b477886a9c218c17973e996bcedccf
Reviewed-on: https://go-review.googlesource.com/c/go/+/303549
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This constant existed in case there was a serious problem with the
change to the "all" pattern in Go 1.16 (CL 240623), so that we could
roll back the change in behavior by just flipping the constant without
introducing merge conflicts elsewhere.
Go 1.16 has been out for a while and the new "all" behavior seems fine,
so we can jettison this feature flag.
For #36460
Change-Id: Ic2730edcee81514d56c7086e11542468eb63c84a
Reviewed-on: https://go-review.googlesource.com/c/go/+/303431
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Windows amd64 calling convention requires 16-bytes aligned
stack pointer. Before this patch, the real frame size is
0x48 (frame size) + 0x10 (frame pointer & return address),
which does not satisfy the alignment requirement.
_cgo_sys_thread_create eventually calls NtCreateThread,
which receives a pointer to a ThreadContext structure
allocated from (mis-aligned) stack, and may fail with
STATUS_DATATYPE_MISALIGNMENT on some implementations.
BP is saved/restored by prolog/epilog.
AX, CX, DX are volatile, no need to save and restore.
Fixes#41075
Change-Id: I01c0a22b4bf3b4cfdebf4df587445aa46c667973
GitHub-Last-Rev: 15d2bd740e
GitHub-Pull-Request: golang/go#44524
Reviewed-on: https://go-review.googlesource.com/c/go/+/295329
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Alex Brainman <alex.brainman@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Christopher Nelson <nadiasvertex@gmail.com>
When -clobberdeadreg flag is set, the compiler inserts code that
clobbers integer registers at call sites. This may be helpful for
debugging register ABI.
Only implemented on AMD64 for now.
Change-Id: Ia203d3f891c30fd95d0103489056fe01d63a2899
Reviewed-on: https://go-review.googlesource.com/c/go/+/302809
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Alpine Linux is not the only musl-based Linux distribution. Checking for
/etc/alpine-release excludes many other distributions (Oasis, KISS,
Sabotage, sta.li). Not having the correct GO_LDSO set during go builds will
result in the wrong linker/loader on nonalpine musl systems for pie builds.
Instead, the dynamic loader should be checked for every system and set. This
results in the correct dynamic linker being found on glibc systems
(/lib/ld-linux-x86-64.so.2) and musl systems (/lib/ld-musl-x84_64.so.1).
Fixes#45034
Change-Id: I4c9389abc759aa34431dc6c781022636b81d6910
GitHub-Last-Rev: e17b9eb106
GitHub-Pull-Request: golang/go#45036
Reviewed-on: https://go-review.googlesource.com/c/go/+/301989
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Cherry Zhang <cherryyz@google.com>
In the runtime there are Windows-specific assembly routines that are
address-taken via funcPC and are not intended to be called through a
wrapper. Mark them as ABIInternal so that we don't grab the wrapper,
because that will break in all sorts of contexts.
For #40724.
For #44065.
Change-Id: I12a728786786f423e5b229f8622e4a80ec27a31c
Reviewed-on: https://go-review.googlesource.com/c/go/+/302109
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This changes makes it so that nanotimeQPC calls nanotime1 without an ABI
wrapper by specifying the ABIInternal version directly. The reason why
this is necessary is because ABI wrappers typically require additional
stack space, and nanotimeQPC is used deep within nosplit contexts,
and with the ABI wrappers now enabled, this exhausts the stack guard
space held for nosplit functions. Rather than increase the stack guard,
we choose to do this.
For #40724.
Change-Id: Ia9173ca903335a9d6f380f57f4a45e49b58da6bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/303069
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Updates ExampleGet to show how to handle bad responses with non-1XX,2XX
status codes. Given that the canonical examples are copied, we need
to have them properly check against failures. This is a bug I've seen
often in the wild, that's exacerbated when for example unmarshalling
JSON or even protobufs, and no errors are returned by the decoders,
so code fails silently after making a request for example to a gateway
that they were unauthorized to access.
Fixes#39778
Change-Id: I1cd688f2fab47581c8cf228235d3662b4c8e4315
Reviewed-on: https://go-review.googlesource.com/c/go/+/299609
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Adds mentions of NewRequestWithContext and *Client.Do as prescriptions
for how to use a specified context.Context, to the docs of:
* (*Client).Get
* (*Client).Head
* (*Client).Post
* (*Client).PostForm
* Get
* Head
* Post
* PostForm
given that we can't remove those convenience functions, nor
change the method signatures, except for Go2.
Fixes#35562
Change-Id: I4859e6757e7f958c9067ac4ef15881cfba7d1f8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/299610
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Several classifications exist only to help disambiguate an
implied register (i.e $0/R0 as the implied second register
argument when loading constants, or pseudo-registers used
exclusively by the assembler front-end).
The register determination is folded into getimpliedreg. The
classifications and their related optab entries are removed
or updated.
Change-Id: Iffb167aa9fa57fbc1a537c79fbdfb36cb38f9d95
Reviewed-on: https://go-review.googlesource.com/c/go/+/301789
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Cherry Zhang <cherryyz@google.com>
Previously, we used to call doc.ToText to print each comment
in a comment group attached to an interface method. This broke any
preformatted code block attached to the comment, and displayed everything
aligned to a single column. Additionally, the name of the interface
also wasn't displayed which didn't show which interface
the method belonged to.
To fix this, we print the entire interface node using format.Node
which takes care of displaying the comments correctly, and we also
filter out the methods that don't match, so that the method can be
displayed as belonging to an interface.
As an example, previously it would show:
// Comment before exported method.
//
// // Code block showing how to use ExportedMethod
// func DoSomething() error {
// ExportedMethod()
// return nil
// }
func ExportedMethod() // Comment on line with exported method.
Now, it shows:
type ExportedInterface interface {
// Comment before exported method.
//
// // Code block showing how to use ExportedMethod
// func DoSomething() error {
// ExportedMethod()
// return nil
// }
ExportedMethod() // Comment on line with exported method.
}
Fixes#43188
Change-Id: I28099fe4aab35e08049b2616a3506240f57133cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/279433
Trust: Agniva De Sarker <agniva.quicksilver@gmail.com>
Trust: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Rob Pike <r@golang.org>
"VMOV Vn.<T>[index], Vn" is equivalent to "VDUP Vn.<T>[index], Vn", and
the latter has a higher priority in the disassembler than the former.
But the assembler doesn't support to encode this combination of VDUP,
this leads to an inconsistency between assembler and disassembler.
For example, if we assemble "VMOV V20.S[0], V20" to hex then decode it,
we'll get "VDUP V20.S[0], V20".
VMOV V20.S[0], V20 -> 9406045e -> VDUP V20.S[0], V20 -> error
But we cannot assemble this VDUP again.
Similar reason for "VDUP Rn, Vd.<T>". This CL completes the support for
VDUP.
This patch is a copy of CL 276092. Co-authored-by: JunchenLi
<junchen.li@arm.com>
Change-Id: I8f8d86cf1911d5b16bb40d189f1dc34b24416aaf
Reviewed-on: https://go-review.googlesource.com/c/go/+/302929
Trust: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
types2 will give us a constant with a type T, if an untyped constant is
used with another operand of type T (in a provably correct way). When we
substitute in the type args during stenciling, we now know the real type
of the constant. We may then need to change the BasicLit.val to be the
correct type (e.g. convert an int64Val constant to a floatVal constant).
Otherwise, later parts of the compiler will be confused.
Updated tests list.go and double.go with uses of untyped constants.
Change-Id: I9966bbb0dea3a7de1c5a6420f8ad8af9ca84a33e
Reviewed-on: https://go-review.googlesource.com/c/go/+/303089
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Previously, the runtime had to understand the full syntax of the
GOEXPERIMENT environment variable. Now, sys.GOEXPERIMENT is the
pre-processed experiment list produced by objabi, so we can simplify
the runtime parser.
Change-Id: I0d113a4347dde50a35b8b1f2b0110c88fe802921
Reviewed-on: https://go-review.googlesource.com/c/go/+/303049
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This moves all remaining GOEXPERIMENT flags into the objabi.Experiment
struct, drops the "_enabled" from their name, and makes them all bool
typed.
We also drop DebugFlags.Fieldtrack because the previous CL shifted the
one test that used it to use GOEXPERIMENT instead.
Change-Id: I3406fe62b1c300bb4caeaffa6ca5ce56a70497fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/302389
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Now that we can set GOEXPERIMENT at build time, we no longer need
-d=fieldtrack in the compiler to enabled field tracking at build time.
Switch the one test that uses -d=fieldtrack to use GOEXPERIMENT
instead so we can eliminate this debug flag and centralize on
GOEXPERIMENT.
Updates #42681.
Change-Id: I14c352c9a97187b9c5ec8027ff672d685f22f543
Reviewed-on: https://go-review.googlesource.com/c/go/+/302969
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This patch provides changes according to TODO. Since writeMutex and
writeBlock functions have a lot of code in common, it is better to
move this code to one function.
Change-Id: I81aaad067b0cb1647824909f3b5f6861add3a7ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/280152
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Hyang-Ah Hana Kim <hyangah@gmail.com>
PPC64 needs to preserve bits when applying some relocations. DS form
relocations must preserve the lower two bits, and thus needs to inspect
the section data as it streams out.
Similarly, the overflow checking requires inspecting the primary
opcode to see if the value is sign or zero extended.
The existing PPC64 code no longer works as the slice returned by
(loader*).Data is cleared as we layout the symbol and process
relocations. This data is always the section undergoing relocation,
thus we can directly inspect the contents to preserve bits or
check for overflows.
Change-Id: I239211f7e5e96208673663b6553b3017adae7e01
Reviewed-on: https://go-review.googlesource.com/c/go/+/300555
Run-TryBot: Paul Murphy <murp@ibm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Remove unneeded calls to typecheck in noder2 associated with g.use() and
g.obj(). These routines are already setting the types2-derived type
correctly for ONAME nodes, and there is no typechecker1-related
transformations related to ONAME nodes, other than making sure that
newly created closure variables have their type set.
Tested through normal -G=3 testing in all.bash (all of go/tests).
Change-Id: I1b790ab9948959685fca3a768401458201833671
Reviewed-on: https://go-review.googlesource.com/c/go/+/303029
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
This separates GOEXPERIMENT=regabi into five sub-experiments:
regabiwrappers, regabig, regabireflect, regabidefer, and regabiargs.
Setting GOEXPERIMENT=regabi now implies the working subset of these
(currently, regabiwrappers, regabig, and regabireflect).
This simplifies testing, helps derisk the register ABI project,
and will also help with performance comparisons.
This replaces the -abiwrap flag to the compiler and linker with
the regabiwrappers experiment.
As part of this, regabiargs now enables registers for all calls
in the compiler. Previously, this was statically disabled in
regabiEnabledForAllCompilation, but now that we can control it
independently, this isn't necessary.
For #40724.
Change-Id: I5171e60cda6789031f2ef034cc2e7c5d62459122
Reviewed-on: https://go-review.googlesource.com/c/go/+/302070
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Currently, the nosplit test disables ABI wrapper generation because it
generates a main.main in assembly, and so the ABI wrapper for calling
from runtime.main to main.main counts against the nosplit limit, which
cases some of the tests to fail.
Fix this by first entering ABI0 in a splittable context and then
calling from there into the test entry point, since this doesn't
introduce an ABI wrapper.
While we're here, this CL removes the test's check for the
framepointer experiment. That's now statically enabled, so it doesn't
appear in the experiment line, and enabling any other experiment
causes the test to think that the framepointer experiment *isn't*
enabled.
For #40724.
Change-Id: I6291eb9391f129779e726c5fc8c41b7b4a14eeb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/302772
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Currently, objabi exports GOEXPERIMENT flags as ints that are either 0
or 1. Since the dawn of time, there's been a comment saying that we
*could* support general integers here, but it's never happened and all
the "== 0" and "!= 0" and "== 1" are driving me crazy and are making
the code harder to read and maintain. Hence, this CL adds support for
boolean GOEXPERIMENT flags. We'll introduce some bool-typed flags in
the next CL.
Change-Id: I7813400db130a9b8f71a644fe7912808dbe645bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/302069
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Currently, dist attempts to build the bootstrap with the GOEXPERIMENT
set in the environment. However, the logic is incomplete and notably
requires a hack to enable the appropriate build tags for
GOEXPERIMENT=regabi. Without this hack, the build becomes skewed
between a compiler that uses regabi and a runtime that doesn't when
building toolchain2.
We could try to improve the GOEXPERIMENT processing in cmd/dist, but
it will always chase cmd/internal/objabi and it's quite difficult to
share the logic with objabi because of the constraints on building
cmd/dist.
Instead, we switch to building go_bootstrap without any GOEXPERIMENT
and only start using GOEXPERIMENT once we have a working, modern
cmd/go (which has all the GOEXPERIMENT logic in it). We also build
toolchain1 without any GOEXPERIMENT set, in case the bootstrap
toolchain is recent enough to understand build-time GOEXPERIMENT
settings.
As part of this, we make GOEXPERIMENT=none mean "no experiments". This
is necessary since, now that we support setting GOEXPERIMENT at build
time, we need an explicit way to say "ignore all baked-in experiments".
For #40724.
Change-Id: I115399579b766a7a8b2f352f7e5efea5305666cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/302050
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
objabi parses GOEXPERIMENT, but most of the consumers look at the raw
GOEXPERIMENT string that objabi gets from the environment. Centralize
this logic by only exposing the parsed GOEXPERIMENT value from objabi.
This sets us up for the next few changes. It also has the nice but
mostly useless property that the order of experiment names will be
canonicalized in build cache hashes.
After this, the only remaining place that looks at raw GOEXPERIMENT is
cmd/dist, which we'll fix in the next CL.
For #40724.
Change-Id: Idb150f848e17c184fae91372ca8b361591472f51
Reviewed-on: https://go-review.googlesource.com/c/go/+/302049
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The last primary usage of renameio was the WriteFile in
modfetch.WriteDiskCache. Because it's not guaranteed that the fsync in
WriteDiskCache will eliminate file corruption, and it slows down tests
on Macs significantly, inline that last usage, removing the fsync.
Also, remove the uses of renameio.Pattern. The ziphash file is no
longer written to a temporary location before being copied to its
final location, so that usage can just be cut. The remaining use is
for the zipfile . Remove the first because the files are no longer
written using the pattern anyway, so that the pattern variable has no
effect. Replace it with a local pattern variable that is also passed
to os.CreateTemp.
Change-Id: Icf3adabf2a26c37b82afa1d07f821a46b30d69ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/301889
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
When the stack bound check fails, print the call chain with
symbol versions (along with the names). Now that we have ABI
wrappers and wrappers do consume stack space, it is clearer to
distinguish the wrappers vs. the underlying functions.
Change-Id: Id1d922e3e7934b31317f233aff3d9667b6ac90c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/302869
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Follow what MIPS does and load >32-bit constants from memory using two instructions,
rather than generating a four to six instruction sequence. This removes more than 2,500
instructions from the Go binary. This also makes it possible to load >32-bit constants
via a single assembly instruction, if required.
Change-Id: Ie679a0754071e6d8c52fe0d027f00eb241b3a758
Reviewed-on: https://go-review.googlesource.com/c/go/+/302609
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Actually enable intrinsics for runtime/internal/atomic.{And,Or}{8,} on RISCV64.
This seems to have been lost when CL 268098 was rebased.
Change-Id: If072daa79c8964b186c127d5e065a7cc9e23ba27
Reviewed-on: https://go-review.googlesource.com/c/go/+/302229
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Most platforms only use a single MOV const operand - remove the MOV{B,H,W}const
operands from riscv64 and consistently use MOVDconst instead. The implementation
of all four is the same and there is no benefit gained from having multiple const
operands (in fact it requires a lot more rewrite rules).
Change-Id: I0ba7d7554e371a1de762ef5f3745e9c0c30d41ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/302610
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Munday <mike.munday@lowrisc.org>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This CL adds rewrite rules for CSETM, CSINC, CSINV, and CSNEG. By adding
these rules, we can save one instruction.
For example,
func test(cond bool, a int) int {
if cond {
a++
}
return a
}
Before:
MOVD "".a+8(RSP), R0
ADD $1, R0, R1
MOVBU "".cond(RSP), R2
CMPW $0, R2
CSEL NE, R1, R0, R0
After:
MOVBU "".cond(RSP), R0
CMPW $0, R0
MOVD "".a+8(RSP), R0
CSINC EQ, R0, R0, R0
This patch is a copy of CL 285694. Co-authored-by: JunchenLi
<junchen.li@arm.com>
Change-Id: Ic1a79e8b8ece409b533becfcb7950f11e7b76f24
Reviewed-on: https://go-review.googlesource.com/c/go/+/302231
Trust: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Don't eagerly record the target type for an untyped operand if the
target type is just one of possibly many types in the type list of
a type parameter. Instead, record expression type only after we
checked that all types in the type list are ok.
Also, update assertion in Checker.recordTypeAndValue since (currently),
a type parameter is not considered a const type. We may change that,
eventually.
This is a temporary (but working) solution. Eventually we should
copy the approach taken in go/types.
Fixes#45096.
Change-Id: Icf61ee893aca6ead32bfc45ee5831572e672357b
Reviewed-on: https://go-review.googlesource.com/c/go/+/302755
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Then, write the 'go.mod' file with that version before further
processing. That way, if the command errors out due to a change in
behavior, the reason for the change in behavior will be visible in the
file diffs.
If the 'go.mod' file cannot be written (due to -mod=readonly or
-mod=vendor), assume Go 1.11 instead of the current Go release.
(cmd/go has added 'go' directives automatically, including in 'go mod
init', since Go 1.12.)
For #44976
Change-Id: If9d4af557366f134f40ce4c5638688ba3bab8380
Reviewed-on: https://go-review.googlesource.com/c/go/+/302051
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This CL resurrects the clobberdead debugging mode (CL 23924).
When -clobberdead flag is set (TODO: make it GOEXPERIMENT?), the
compiler inserts code that clobbers all dead stack slots that
contains pointers.
Mark windows syscall functions cgo_unsafe_args, as the code
actually does that, by taking the address of one argument and
passing it to cgocall.
Change-Id: Ie09a015f4bd14ae6053cc707866e30ae509b9d6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/301791
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
For Builtin ops, we currently stay with using the old
typechecker to transform the call to a more specific expression
and possibly use more specific ops. However, for a bunch of the
ops, we delay calling the old typechecker if any of the args have
type params, for a variety of reasons.
In the near future, we will start creating separate functions that do
the same transformations as the old typechecker for calls, builtins,
indexing, comparisons, etc. These functions can then be called at noder
time for nodes with no type params, and at stenciling time for nodes
with type params.
Remove unnecessary calls to types1 typechecker for most kinds of
statements (still need it for SendStmt, AssignStmt, ReturnStmt, and
SelectStmt). In particular, we don't need it for RangeStmt, and this
avoids some complaints by the types1 typechecker on generic code.
Other small changes:
- Fix check on whether to delay calling types1-typechecker on type
conversions. Should check if HasTParam is true, rather than if the
type is directly a TYPEPARAM.
- Don't call types1-typechecker on an indexing operation if the left
operand has a typeparam in its type and is not obviously a TMAP,
TSLICE, or TARRAY. As above, we will eventually have to create a new
function that can do the required transformations (for complicated
cases) at noder time or stenciling time.
- Copy n.BuiltinOp in subster.node()
- The complex arithmetic example in absdiff.go now works.
- Added new tests double.go and append.go
- Added new example with a new() call in settable.go
Change-Id: I8f377afb6126cab1826bd3c2732aa8cdf1f7e0b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/301951
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The changes between (equivalent, and reviewed) go/types/call.go
and call.go can be seen by comparing patchset 1 and 2. The actual
changes are removing the "// UNREVIEWED" marker, renaming of
sig_params to sigParams, and a couple of comment adjustments.
These additional changes reduce the difference between this
file and the go/types version.
Note that the verification pass using a MethodSet doesn't
exist because there's no MethodSet in types2.
Change-Id: I4d49460e0457401ed705dff5cfd17c9ff259d89f
Reviewed-on: https://go-review.googlesource.com/c/go/+/300998
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Static tmps are private to a package, but with plugins a package
can be shared among multiple DSOs. They need to have a consistent
view of the static tmps, especially for writable ones. So export
them. (Read-only static tmps have the same values anyway, so it
doesn't matter. Also Mach-O doesn't support dynamically exporting
read-only symbols anyway.)
Fixes#44956.
Change-Id: I921e25b7ab73cd5d5347800eccdb7931e3448779
Reviewed-on: https://go-review.googlesource.com/c/go/+/301793
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
The assember uses R15 as scratch space when assembling global variable
references in dynamically linked code. If the assembly code uses the
clobbered value of R15, report an error. The user is probably expecting
some other value in that register.
Getting rid of the R15 use isn't very practical (we could save a
register to a field in the G maybe, but that gets cumbersome).
Fixes#43661
Change-Id: I43f848a3d8b8a28931ec733386b85e6e9a42d8ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/283474
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In Go1.13 and above, signed integers are permitted as shift counts as long as they are >=0.
However, the comments in the "Arithmetic operators" section says shift operators accept "unsigned integer" as of right operands. Replacing this with "integer>=0" resolves the misunderstanding that shift
operators permit only unsigned integers.
Reference: Go1.13 Release Notes: https://golang.org/doc/go1.13
Change-Id: Icd3c7734d539ab702590e992a618c9251c653c37
GitHub-Last-Rev: 4f263a48d3
GitHub-Pull-Request: golang/go#44664
Reviewed-on: https://go-review.googlesource.com/c/go/+/297249
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Robert Griesemer <gri@golang.org>
Ignore an embedded type in an interface which is the predeclared
interface "comparable" (which currently can only be in a type
constraint), since the name doesn't resolve and the "comparable" type
doesn't have any relevant methods (for the purposes of the compiler).
Added new test case graph.go that needs this fix.
Change-Id: I2443d2c3dfeb9d0a78aaaaf91a2808ae2759d247
Reviewed-on: https://go-review.googlesource.com/c/go/+/301831
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Adds the (*tls.Conn).HandshakeContext method. This allows
us to pass the context provided down the call stack to
eventually reach the tls.ClientHelloInfo and
tls.CertificateRequestInfo structs.
These contexts are exposed to the user as read-only via Context()
methods.
This allows users of (*tls.Config).GetCertificate and
(*tls.Config).GetClientCertificate to use the context for
request scoped parameters and cancellation.
Replace uses of (*tls.Conn).Handshake with (*tls.Conn).HandshakeContext
where appropriate, to propagate existing contexts.
Fixes#32406
Change-Id: I259939c744bdc9b805bf51a845a8bc462c042483
Reviewed-on: https://go-review.googlesource.com/c/go/+/295370
Run-TryBot: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Katie Hockman <katie@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
This was causing test failures while revising CL 293689: splitting the
roots out from the rest of the module graph may allow 'go list -e' to
proceed even when the rest of the module graph can't be loaded (e.g.
due to missing go.mod checksums). If that occurs, it becomes more
important that the moduleInfo helper function itself avoid fetching
unchecked files.
For #36460
Change-Id: I088509eeb3008cc6e8bfe85a00ec2bf500bf9423
Reviewed-on: https://go-review.googlesource.com/c/go/+/301371
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Accepts comma "," as a separator for fractional seconds
hence we now accept:
* 2006-01-02 15:04:05,999999999 -0700 MST
* Mon Jan _2 15:04:05,120007 2006
* Mon Jan 2 15:04:05,120007 2006
This change follows the recommendations of ISO 8601 per
https://en.wikipedia.org/wiki/ISO_8601#cite_note-26
which states
ISO 8601:2004(E), ISO, 2004-12-01, "4.2.2.4 ...
the decimal fraction shall be divided from the integer
part by the decimal sign specified in ISO 31-0, i.e.
the comma [,] or full stop [.]. Of these, the comma
is the preferred sign."
Unfortunately, I couldn't directly access the ISO 8601 document
because suddenly it is behind a paywall on the ISO website,
charging CHF 158 (USD 179) for 38 pages :-(
However, this follows publicly available cited literature, as well
as the recommendations from the proposal approval.
Fixes#6189
Updates #27746
Updates #26002
Updates #36145
Updates #43813Fixes#43823
Change-Id: Ibe96064e8ee27c239be78c880fa561a1a41e190c
Reviewed-on: https://go-review.googlesource.com/c/go/+/300996
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Added test example orderedmap.go (binary search tree) that requires this
fix (calling function compare in _Map).
Also added new tests slices.go and metrics.go that just work.
Change-Id: Ifa5f42ab6eee9aa54c40f0eca19e00a87f8f608a
Reviewed-on: https://go-review.googlesource.com/c/go/+/301829
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Add support for maps in subster.typ(). Add new test cases maps.go and set.go.
Change substitution of a TFUNC in subster.typ() to always create new
param and result structs if any of the receiver, param, or result
structs get substituted. All these func structs must be copied, because
they have offset fields that are dependent, and so must have an
independent copy for each new signature (else there will be an error
later when frame offsets are calculated).
Change-Id: I576942a62f06b46b6f005abc98f65533008de8dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/301670
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Add support for channels in subster.typ(). Add new test file chans.go.
To support assignability of bidirectional channel args to directional
channel params, I needed to type check generic calls after they are
instantiated. (Eventually, we will create separate functions to just do
the assignability logic, so we don't need to call the old typechecker in
this case.) So, for generic calls, we now leave the call as OCALL (as a
signal that the call still needs typechecking), and do typecheck.Call()
during stenciling.
Smaller changes:
- Set the type of an instantiated OCLOSURE node (and not just the associated
OFUNC node)
- In instTypeName2, filter out the space that types2.TypeString inserts
after a common in a typelist. Our standard naming requires no space
after the comma.
- With the assignability fix above, I no longer need the explicit
conversions in cons.go.
Change-Id: I148858bfc6708c0aa3f50bad7debce2b8c8c091f
Reviewed-on: https://go-review.googlesource.com/c/go/+/301669
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This change moves the call of sysMap from (*mheap).sysAlloc into
(*mheap).grow, so we only sysMap what we're going to use in the near
future (thanks to the curArena mechanism). The purpose of this change is
to better support systems with strict overcommit rules which generally
accept reserved memory but not prepared memory (see malloc.go for exact
descriptions of these states).
This move requires changing linearAlloc to only optionally map memory.
In one case, with mheap.heapArenaAlloc, we do want it to map memory. But
now in the other case, with mheap.arena, we don't, because we want grow
to take care of it.
The risk with this change is we may make more syscalls than before on
systems with 64 MiB arenas, but because heap growth is relatively rare
this is unlikely to be a noticable issue. We also bound the amount of
syscalls made by only extending curArena (and thus mapping) by
pallocChunkPages*pageSize which is 4 MiB.
Fixes#42612.
Change-Id: I736df696afe78ddb1a747a896caa0db8726027e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/270537
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
A Directive (like <!ENTITY xxx []>) can't have other nodes nested inside
it (in our data structure representation), so there is no way to
preserve comments. The previous behavior was to just elide them, which
however might change the semantic meaning of the surrounding markup.
Instead, replace them with a space which hopefully has the same semantic
effect of the comment.
Directives are not actually a node type in the XML spec, which instead
specifies each of them separately (<!ENTITY, <!DOCTYPE, etc.), each with
its own grammar. The rules for where and when the comments are allowed
are not straightforward, and can't be implemented without implementing
custom logic for each of the directives.
Simply preserving the comments in the body of the directive would be
problematic, as there can be unmatched quotes inside the comment.
Whether those quotes are considered meaningful semantically or not,
other parsers might disagree and interpret the output differently.
This issue was reported by Juho Nurminen of Mattermost as it leads to
round-trip mismatches. See #43168. It's not being fixed in a security
release because round-trip stability is not a currently supported
security property of encoding/xml, and we don't believe these fixes
would be sufficient to reliably guarantee it in the future.
Fixes CVE-2020-29510
Updates #43168
Change-Id: Icd86c75beff3e1e0689543efebdad10ed5178ce3
Reviewed-on: https://go-review.googlesource.com/c/go/+/277893
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Before this change, <:name> would parse as <name>, which could cause
issues in applications that rely on the parse-encode cycle to
round-trip. Similarly, <x name:=""> would parse as expected but then
have the attribute dropped when serializing because its name was empty.
Finally, <a:b:c> would parse and get serialized incorrectly. All these
values are invalid XML, but to minimize the impact of this change, we
parse them whole into Name.Local.
This issue was reported by Juho Nurminen of Mattermost as it leads to
round-trip mismatches. See #43168. It's not being fixed in a security
release because round-trip stability is not a currently supported
security property of encoding/xml, and we don't believe these fixes
would be sufficient to reliably guarantee it in the future.
Fixes CVE-2020-29509
Fixes CVE-2020-29511
Updates #43168
Change-Id: I68321c4d867305046f664347192948a889af3c7f
Reviewed-on: https://go-review.googlesource.com/c/go/+/277892
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
This commit rewrites ReadFromUDP to be mid-stack inlined
and pass a UDPAddr for lower layers to fill in.
This lets performance-sensitive clients avoid an allocation.
It requires some care on their part to prevent the UDPAddr
from escaping, but it is now possible.
The UDPAddr trivially does not escape in the benchmark,
as it is immediately discarded.
name old time/op new time/op delta
WriteToReadFromUDP-8 17.2µs ± 6% 17.1µs ± 5% ~ (p=0.387 n=9+9)
name old alloc/op new alloc/op delta
WriteToReadFromUDP-8 112B ± 0% 64B ± 0% -42.86% (p=0.000 n=10+10)
name old allocs/op new allocs/op delta
WriteToReadFromUDP-8 3.00 ± 0% 2.00 ± 0% -33.33% (p=0.000 n=10+10)
Updates #43451
Co-authored-by: Filippo Valsorda <filippo@golang.org>
Change-Id: I1f9d2ab66bd7e4eff07fe39000cfa0b45717bd13
Reviewed-on: https://go-review.googlesource.com/c/go/+/291509
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Filippo Valsorda <filippo@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
The register allocator has a special case that doesn't allocate
LR on ARMv5. This was necessary when softfloat expansion was done
by the assembler. Now softfloat calls are inserted by SSA, so it
works as normal. Remove this special case.
Change-Id: I5502f07597f4d4b675dc16b6b0d7cb47e1e8974b
Reviewed-on: https://go-review.googlesource.com/c/go/+/301792
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
These are always sorted and grouped during initialization of the
actual opcode -> optab map generation. Thus, their initial location
in optab is mostly aimed at readability. This cleanup is intends to
ease reviewing of future patches which simplify, combine, or remove
MOV* optab entries.
Change-Id: I87583ed34fab79e0f625880f419d499939e2a9e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/300612
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
The whitespace was there to align with the following comment,
but the extra whitespace was unnecessary; it wasn't gofmt'd.
Then the file got gofmt'd, but the whitespace didn't get fixed.
Change-Id: I45aad9605b99d83545e4e611ae3ea1b2ff9e6bf6
Reviewed-on: https://go-review.googlesource.com/c/go/+/301649
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
After CL 179377, this change deletes all the prior cmd/cover code
and instead vendors and type aliases code using the significantly
optimized golang.org/x/tools/cover, which sped up ParseProfiles by
manually parsing profiles instead of a regex. The speed up was:
name old time/op new time/op delta
ParseLine-12 2.43µs ± 2% 0.05µs ± 8% -97.98% (p=0.000 n=10+9)
name old speed new speed delta
ParseLine-12 42.5MB/s ± 2% 2103.2MB/s ± 7% +4853.14% (p=0.000 n=10+9)
Fixes#32211.
Change-Id: Ie4e8be7502f25eb95fae7a9d8334fc97b045d53f
Reviewed-on: https://go-review.googlesource.com/c/go/+/249759
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
As Cherry pointed out on golang.org/cl/299909, the page allocator
doesn't guarantee any alignment for multi-page allocations, so object
alignments are thus implicitly capped at page alignment.
Change-Id: I6f5df27f269b095cde54056f876fe4240f69c5c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/301292
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
This CL replaces self_test.go with the (improved) version
from go/types, modified for types2.
To see the differences between go/types/self_test.go and
this version, compare against patch set 1.
Change-Id: I7ae830a17f7a0de40cc1f5063166a7247f78ec27
Reviewed-on: https://go-review.googlesource.com/c/go/+/300997
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
- Remove specialized errorf functions for invalid AST/argument/operation.
Instead use prefix constants with the error message.
- Replace several calls to Checker.errorf with calls to Checker.error
if there are no arguments to format.
- Replace a handful of %s format verbs with %v to satisfy vet check.
- Add a basic test that checks that we're not using Checker.errorf when
we should be using Checker.error.
Change-Id: I7bc7c14f3cf774689ec8cd5782ea31b6e30dbcd6
Reviewed-on: https://go-review.googlesource.com/c/go/+/300995
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The favicon.ico and robots.txt files have been with us in the root
directory since 2009 and 2011 respectively. Back then, the Go repo
had content for the golang.org website, which could be run locally.
Since these files were at the root of the website, they were added
to the corresponding location in the GOROOT tree—at the root.
In 2018, work started on factoring out golang.org website content
and code into a new golang.org/x/website repository (issue 29206).
The favicon.ico and robots.txt files were copied to x/website repo,
but some more work needed to be done before they would be picked up
and served when golangorg was executed in module mode. That work is
done by now (CL 293413 and CL 293414).
The scope of the godoc tool has also been reduced to just serving
Go package documentation and not the website (issue 32011), so it
can provide its own favicon.ico as needed (CL 300394).
This means these two files have no more use and can be deleted.
So long and goodbye!
Change-Id: Id71bdab6317c1dc481c9d85beaaac4b4eb92d379
Reviewed-on: https://go-review.googlesource.com/c/go/+/300549
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This is enabled with a ridiculous magic name for method,
or for last input type passed, that needs to be changed
to something inutterable before actual release.
Ridiculous method name: MagicMethodNameForTestingRegisterABI
Ridiculous last (input) type name: MagicLastTypeNameForTestingRegisterABI
RLTN is tested with strings.Contains, so you can have
MagicLastTypeNameForTestingRegisterABI1
and
MagicLastTypeNameForTestingRegisterABI2
if that is helpful
Includes test test/abi/fibish2.go
Updates #44816.
Change-Id: I592a6edc71ca9bebdd1d00e24edee1ceebb3e43f
Reviewed-on: https://go-review.googlesource.com/c/go/+/299410
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
I was curious about the minimum possible alignment for each size class
and the minimum size to guarantee any particular alignment (e.g., to
know at what class size you can start assuming heap bits are byte- or
word-aligned).
Change-Id: I205b750286e8914986533c4f60712c420c3e63e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/299909
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Currently, the build config includes GOEXPERIMENT environment
variable if it is not empty, but that doesn't take the default
value (set at make.bash/bat/rc time) into consideration. This
may cause standard library packages appearing stale, as the
build config appears changed.
This CL changes it to use cfg.GOEXPERIMENT variable, which
includes the default value (if it is not overwritten).
May fix regabi and staticlockranking builders.
Change-Id: I242f887167f8e99192010be5c1a046eb88ab0c2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/301269
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Simple change to avoid calling the old typechecker in noder.Addr(). This
fixes cases where generic code calls a pointer method with a non-pointer
receiver.
Added test typeparam/lockable.go that now works with this change.
For lockable.go to work, also fix incorrect check to decide whether to
translate an OXDOT now or later. We should delay translating an OXDOT
until instantiation (because we don't know how embedding, etc. will
work) if the receiver has any typeparam, not just if the receiver type
is a simple typeparam. We also have to handle OXDOT for now in
IsAddressable(), until we can remove calls to the old typechecker in
(*irgen).funcBody().
Change-Id: I77ee5efcef9a8f6c7133564106a32437e36ba4bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/300990
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Refer to ARM reference manual, like add(extended register) instructions,
the extension is encoded in the "option" field. If "Rd" or "Rn" is
RSP and "option" is "010" then LSL is preferred. Therefore, the instrution
"add Rm<<imm, RSP, RSP" or "add Rm<<imm RSP" is valid and can be encoded
as add(extended register) instruction.
But the current assembler can not handle like "op R1<<1, RSP, RSP"
instructions, this patch adds the support.
Because MVN(extended register) does not exist, remove it.
Add test cases.
Change-Id: I968749d75c6b93a4f297b39c73cc292e6b1035ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/284900
Trust: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Restore code to call types.CheckSize() in g.typ(). There are certain
cases (involving maps) where we need to do CheckSize here. In general,
the old typechecker calls CheckSize() a lot, and we want to eliminate
calling it eventually, so should get do types.CheckSize() when we create
a new concrete type.
However, the test typeparams/cons.go does not work with just calling
types.CheckSize() in g.typ() (which is why I disabled the calls
originally). The reason is that g.typ() is called recursively within
types.go, so it can be called on a partially-created recursive type,
which leads to an error in CheckSize(). So, we need to call CheckSize()
only on fully-created top-level types. So, I divided typ() into typ()
and typ1(), where typ() is now the external entry point, and typ1() is
called within types.go. Now, typ() can call CheckSize() safely.
I also added in an extra condition - we do not currently need to call
CheckSize() on non-fully-instantiated types, since they will not make it
to the backend. That could change a bit with dictionaries.
Fixes#44895
Change-Id: I783aa7d2999dd882ddbd99a7c19a6ff6ee420102
Reviewed-on: https://go-review.googlesource.com/c/go/+/300989
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This CL changes GOEXPERIMENT to act like other GO[CONFIG] environment
variables. Namely, that it can be set at make.bash time to provide a
default value used by the toolchain, but then can be manually set when
running either cmd/go or the individual tools (compiler, assembler,
linker).
For example, it's now possible to test rsc.io/tmp/fieldtrack by simply
running:
GOEXPERIMENT=fieldtrack go test -gcflags=-l rsc.io/tmp/fieldtrack \
-ldflags=-k=rsc.io/tmp/fieldtrack.tracked
without needing to re-run make.bash. (-gcflags=-l is needed because
the compiler's inlining abilities have improved, so calling a function
with a for loop is no longer sufficient to suppress inlining.)
Fixes#42681.
Change-Id: I2cf8995d5d0d05f6785a2ee1d3b54b2cfb3331ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/300991
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
cache.Trim, dowloadZip, rewriteVersionList, writeDiskCache all use
renameio.WriteFile to write their respective files to disk. For the
uses in cache.Trim and downloadZip, instead do of renameio.WriteFile,
do a truncate to the length of the file, then write the relevant bytes
so that a corrupt file (which would contain null bytes because of
the truncate) could be detected. For rewriteVersionList, use
lockedfile.Transform to do the write (which does a truncate as part of
the write too. writeDiskCache stays the same in this CL.
Also desete renameio methods that aren't used and remove the
renameio.WriteFile wrapper and just use renameio.WriteToFile which it
wraps.
There is a possibility of corrupt files in the cache (which was true
even before this CL) so later CLs will add facilities to clear corrupt
files in the cache.
Change-Id: I0d0bda40095e4cb898314315bf313e71650d8d25
Reviewed-on: https://go-review.googlesource.com/c/go/+/277412
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The existing code makes copies of every byte it hashes.
When passed a large chunk of memory, Write and WriteString
can skip the copying and initSeed for most of it.
To ensure that Write, WriteByte, and WriteString continue to
generate output that depends only on the sequence of bytes,
expand the grouping test to include WriteString and interleaved calls.
Also, make the test process a lot more data, to ensure that
Write* handled full buffers correctly.
name old time/op new time/op delta
Hash8Bytes-8 17.1ns ± 3% 16.5ns ± 2% -3.26% (p=0.000 n=29+27)
Hash320Bytes-8 74.9ns ± 2% 58.5ns ± 2% -21.86% (p=0.000 n=30+29)
Hash1K-8 246ns ± 3% 195ns ± 1% -20.82% (p=0.000 n=29+30)
Hash8K-8 1.87µs ± 2% 1.59µs ± 2% -15.04% (p=0.000 n=26+30)
name old speed new speed delta
Hash8Bytes-8 468MB/s ± 3% 484MB/s ± 2% +3.36% (p=0.000 n=29+27)
Hash320Bytes-8 4.28GB/s ± 2% 5.47GB/s ± 2% +27.97% (p=0.000 n=30+29)
Hash1K-8 4.17GB/s ± 3% 5.26GB/s ± 1% +26.28% (p=0.000 n=29+30)
Hash8K-8 4.38GB/s ± 2% 5.16GB/s ± 2% +17.70% (p=0.000 n=26+30)
Updates #42710
Change-Id: If3cdec1580ffb3e36fab9865e5a9d089c0a34bec
Reviewed-on: https://go-review.googlesource.com/c/go/+/278758
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The sentence starts "fsys must only contain",
which leads the reader to believe that fsys must not contain others.
The rapid reversal leads to confusion.
I had to read it several times to be sure I'd parsed it correctly.
Remove "only"; rely on the rest of the sentence to clarify.
Change-Id: I9fb7935aed4f9839344d3a00b761d20981fba864
Reviewed-on: https://go-review.googlesource.com/c/go/+/296529
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Emphasize ReadDirFile. It isn't really optional,
and all filesystems have at least one directory (".").
The remaining two additional interfaces are optimizations.
Call them that.
Fully qualify package package io identifiers.
Change-Id: Ibc425a5dfd27e08c2c10c353f780e4a6304cfd87
Reviewed-on: https://go-review.googlesource.com/c/go/+/296390
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The Go standard library retrofitted context support onto existing APIs
using context.Background and later offered variants that directly
supported user-defined context value specification. This commit makes
that behavior clear in documentation and suggests context-aware
alternatives if the user is looking for one.
An example motivation is supporting code for use in systems that expect
APIs to be cancelable for lifecycle correctness or load
shedding/management reasons, as alluded to in
https://blog.golang.org/context-and-structs.
Updates #44143
Change-Id: I2d7f954ddf9b48264d5ebc8d0007058ff9bddf14
Reviewed-on: https://go-review.googlesource.com/c/go/+/296152
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Jean de Klerk <deklerk@google.com>
Trust: Jean de Klerk <deklerk@google.com>
Run-TryBot: Jean de Klerk <deklerk@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
It turns out that if you write Go pointers to Go memory, the Go compiler
must be involved so that it generates various calls to the GC in the
process. Letting Windows write Go pointers to Go memory violated this.
So, we replace that with just a boring call to runtime.KeepAlive. That's
not a great API, but this is all internal code anyway. We fix it up
more elegantly for external consumption in x/sys/windows with CL 300369.
Fixes#44900.
Change-Id: Id6599a793af9c4815f6c9387b00796923f32cb97
Reviewed-on: https://go-review.googlesource.com/c/go/+/300349
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently, the cmd/dist runs test cases in misc/cgo/testsantizers only
when memeory sanitizer is supported, but the tsan tests in
misc/cgo/testsanitizers do not require support for -msan option, which
makes tsan tests can not be run on some unsupported -msan option platforms.
Therefore, this patch moves the test constraints from cmd/dist to
msan_test.go, so that the tsan tests in misc/cgo/testsanitizers
can be run on any system where the C compiler supports -fsanitize=thread
option.
Change-Id: I779c92eedd0270050f1a0b1a69ecce50c3712bc9
Reviewed-on: https://go-review.googlesource.com/c/go/+/297774
Trust: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In the case of partially inferred type arguments, we need to use the
IndexExpr as the key in g.info.Inferred[] rather than the CallExpr.
Added an extra fromStrings1 call in the settable.go test that tests
partially inferred type arguments. This new call uses a new concrete
type SettableString as well.
I also added another implementation fromStrings3 (derived from a go2go
tests) that typechecks but intentionally causes a panic.
Change-Id: I74d35c5a741f72f37160a96fbec939451157f392
Reviewed-on: https://go-review.googlesource.com/c/go/+/300309
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is rarely used, and is implied based on the
memory type of the operand. This is a step towards
simplifying the MOV* pseudo opcodes on ppc64.
Similarly, remove the bogus param value from AVMULESB.
Change-Id: Ibad4d045ec6d8c5163a468b2db1dfb762ef674ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/300177
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Trust: Ian Lance Taylor <iant@golang.org>
The timerpMask optimization updates a mask of Ps (potentially)
containing timers in pidleget / pidleput. For correctness, it depends on
the assumption that new timers can only be added to a P's own heap.
addtimer violates this assumption if it is preempted after computing pp.
That G may then run on a different P, but adding a timer to the original
P's heap.
Avoid this by disabling preemption while pp is in use.
Other uses of doaddtimer should be OK:
* moveTimers: always moves to the current P's heap
* modtimer, cleantimers, addAdjustedTimers, runtimer: does not add net
new timers to the heap while locked
Fixes#44868
Change-Id: I4a5d080865e854931d0a3a09a51ca36879101d72
Reviewed-on: https://go-review.googlesource.com/c/go/+/300610
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
The new Graph type implements an incremental version of the MVS
algorithm, with requirements pushed in by the caller instead of pulled
by an internal MVS traversal.
To avoid redundancy going forward (and to ensure adequate test
coverage of the incremental implementation), the existing buildList
function is reimplemented in terms of Graph.
For #36460
Change-Id: Idd0b6ab8f17cc41d83a2a4c25a95f82e9ce1eab0
Reviewed-on: https://go-review.googlesource.com/c/go/+/244760
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Previosly, EditBuildList performed an mvs.Upgrade followed by an
mvs.Downgrade, with the Downgrade building on the result of the
Upgrade. Unfortunately, that approach potentially folds in irrelevant
dependencies from the first Upgrade, which are then preserved
unnecessarily by the Downgrade (see mod_get_downup_artifact.txt).
Now, we use the initial Upgrade only to compute the maximum allowed
versions of transitive dependencies, and apply the module upgrades and
downgrades together in a single operation.
For #36460
Change-Id: I7590c137111fed4a3b06531c88d90efd49e6943a
Reviewed-on: https://go-review.googlesource.com/c/go/+/290770
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
In the ppc64 ISA DS form loads and stores are restricted to offset
fields that are a multiple of 4. This is currently handled with checks
in the rules that generate MOVDload, MOVWload, MOVDstore and
MOVDstorezero to prevent invalid instructions from getting to the
assembler.
An unhandled case was discovered which led to the search for a better
solution to this problem. Now, instead of checking the offset in the
rules, this will be detected when processing these Ops in
ssaGenValues in ppc64/ssa.go. If the offset is not valid, the address
of the symbol to be loaded or stored will be computed using the base
register + offset, and that value used in the new base register.
With the full address in the base register, the offset field can be
zero in the instruction.
Updates #44739
Change-Id: I4f3c0c469ae70a63e3add295c9b55ea0e30ef9b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/299789
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
To ease readability we typically keep the partial order lists sorted by
rank. This isn't required for correctness, it just makes it (slightly)
easier to read the lists.
Currently we must notice out-of-order entries during code review, which
is an error-prone process.
Add a test to enforce ordering, and fix the errors that have crept in.
Most of the existing errors were misordered lockRankHchan or
lockRankPollDesc.
While we're here, I've moved the correctness check that the partial
ordering satisfies the total ordering from init to a test case. This
will allow us to catch these errors without even running
staticlockranking.
Change-Id: I9c11abe49ea26c556439822bb6a3183129600c3b
Reviewed-on: https://go-review.googlesource.com/c/go/+/300171
Trust: Michael Pratt <mpratt@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Deal with cases like: 'type P[T any] T' (used to add methods to an
arbitrary type T), In this case, P[T] has kind types.TTYPEPARAM (as does
T itself), but requires more code to substitute than a simple TTYPEPARAM
T. See the comment near the beginning of subster.typ() in stencil.go.
Add new test absdiff.go. This test has a case for complex types (which
I've commented out) that will only work when we deal better with Go
builtins in generic functions (like real and imag).
Remove change in fmt.go for TTYPEPARAMS that is no longer needed (since
all TTYPEPARAMS have a sym) and was sometimes causing an extra prefix
when formatting method names.
Separate out the setting of a TTYPEPARAM bound, since it can reference
the TTYPEPARAM being defined, so must be done separately. Also, we don't
currently (and may not ever) need bounds after types2 typechecking.
Change-Id: Id173057e0c4563b309b95e665e9c1151ead4ba77
Reviewed-on: https://go-review.googlesource.com/c/go/+/300049
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
reflectcall tail calls runtime.call{16,32,...} functions, so they
have the same signature as reflectcall. It is important for them
to have the correct arg map, because those functions, as well as
the function being reflectcall'd, could move the stack. When that
happens, its pointer arguments, in particular regArgs, need to be
adjusted. Otherwise it will still point to the old stack, causing
memory corruption.
This only caused failures on the regabi builder because it is the
only place where internal/abi.RegArgs is not a zero-sized type.
May fix#44821.
Change-Id: Iab400ea6b60c52360d0b43a793f6bfe50ca9989b
Reviewed-on: https://go-review.googlesource.com/c/go/+/300154
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
In some cases, this test would prompt for interactive SSH passwords in
order to authenticate to github.com over SSH. Setting GIT_SSH_COMMAND
to /bin/false prevents that, while still provoking the desired Git
failure mode.
Updates #44904.
Change-Id: Idc9fe9f47d2ccb6c8a4ea988b73d9c8c774e4079
Reviewed-on: https://go-review.googlesource.com/c/go/+/300156
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Kevin Burke <kev@inburke.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Kevin Burke <kev@inburke.com>
In scenarios where splice() is called, splice() is usually called not just once, but many times,
which means that a lot of pipes will be created and destroyed frequently, costing an amount of system resources
and slowing down performance, thus I suggest that we add a pipe pool for reusing pipes.
Benchmark tests:
goos: linux
goarch: amd64
pkg: internal/poll
cpu: AMD EPYC 7K62 48-Core Processor
name old time/op new time/op delta
SplicePipe-8 1.36µs ± 1% 0.02µs ± 0% -98.57% (p=0.001 n=7+7)
SplicePipeParallel-8 747ns ± 4% 4ns ± 0% -99.41% (p=0.001 n=7+7)
name old alloc/op new alloc/op delta
SplicePipe-8 24.0B ± 0% 0.0B -100.00% (p=0.001 n=7+7)
SplicePipeParallel-8 24.0B ± 0% 0.0B -100.00% (p=0.001 n=7+7)
name old allocs/op new allocs/op delta
SplicePipe-8 1.00 ± 0% 0.00 -100.00% (p=0.001 n=7+7)
SplicePipeParallel-8 1.00 ± 0% 0.00 -100.00% (p=0.001 n=7+7)
Fixes#42740
Change-Id: Idff654b7264342084e089b5ba796c87c380c471b
Reviewed-on: https://go-review.googlesource.com/c/go/+/271537
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Until now, errors which came with additional details (e.g., a declaration
cycle error followed by the list of objects involved in the cycle, one per
line) were reported as an ordinary error followed by "secondary" errors,
with the secondary errors marked as such by having a tab-indented error
message.
This approach often required clients to filter these secondary errors
(as they are not new errors, they are just clarifying a previously
reported error).
This CL introduces a new internal error_ type which permits accumulating
various error information that may then be reported as a single error.
Change-Id: I25b2f094facd37e12737e517f7ef8853d465ff77
Reviewed-on: https://go-review.googlesource.com/c/go/+/296689
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The heuristic gopls uses to guess error spans can get tripped-up on
certain valid characters in an import path (for example '-').
Update the error for broken imports to capture the full import path
span, so that gopls doesn't need to rely on heuristics.
Change-Id: Ieb8e0dce11933643f701b32271ff5f3477fecaaa
Reviewed-on: https://go-review.googlesource.com/c/go/+/300169
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>
These instructions are actually 5 argument opcodes as specified
by the ISA. Prior to this patch, the MB and ME arguments were
merged into a single bitmask operand to workaround the limitations
of the ppc64 assembler backend.
This limitation no longer exists. Thus, we can pass operands for
these opcodes without having to merge the MB and ME arguments in
the assembler frontend or compiler backend.
Likewise, support for 4 operand variants is unchanged.
Change-Id: Ib086774f3581edeaadfd2190d652aaaa8a90daeb
Reviewed-on: https://go-review.googlesource.com/c/go/+/298750
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Trust: Carlos Eduardo Seo <carlos.seo@linaro.org>
ABI info producer and consumer had different ideas for register
order for parameters.
Includes a test, includes improvements to debugging output.
Updates #44816.
Change-Id: I4812976f7a6c08d6fc02aac1ec0544b1f141cca6
Reviewed-on: https://go-review.googlesource.com/c/go/+/299570
Trust: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Old: return the ABI register index of the result (wrong!)
New: return the index w/in sequence of result registers (right!)
Fixed bug:
genCaller0/genCaller0.go:43:9: internal compiler error: 'Caller0':
panic during schedule while compiling Caller0:
runtime error: index out of range [10] with length 9
Updates #44816.
Change-Id: I1111e283658a2d6422986ae3d61bd95d1b9bde5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/299549
Trust: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
We'll need to attach types to these operations, so we need to
represent them in the import/export data.
Some of the operations use a selector indicating a different package,
so we need to provide an option to encode the package of a selector.
The default selector() function can't encode that extra information,
as selector's exact encoding is used by go/types.
Change-Id: I4c110fe347b3d915f88a722834bc4058baea7854
Reviewed-on: https://go-review.googlesource.com/c/go/+/299771
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Get instantiatiated generic types working with interfaces, including
typechecking assignments to interfaces and instantiating all the methods
properly. To get it all working, this change includes:
- Add support for substituting in interfaces in subster.typ()
- Fill in the info for the methods for all instantiated generic types,
so those methods will be available for later typechecking (by the old
typechecker) when assigning an instantiated generic type to an
interface. We also want those methods available so we have the list
when we want to instantiate all methods of an instantiated type. We
have both for instantiated types encountered during the initial noder
phase, and for instantiated types created during stenciling of a
function/method.
- When we first create a fully-instantiated generic type (whether
during initial noder2 pass or while instantiating a method/function),
add it to a list so that all of its methods will also be
instantiated. This is needed so that an instantiated type can be
assigned to an interface.
- Properly substitute type names in the names of instantiated methods.
- New accessor methods for types.Type.RParam.
- To deal with generic types which are empty structs (or just don't use
their type params anywhere), we want to set HasTParam if a named type
has any type params that are not fully instantiated, even if the
type param is not used in the type.
- In subst.typ() and elsewhere, always set sym.Def for a new forwarding
type we are creating, so we always create a single unique type for
each generic type instantiation. This handles recursion within a
type, and also recursive relationships across many types or methods.
We remove the seen[] hashtable, which was serving the same purpose,
but for subst.typ() only. We now handle all kinds of recursive types.
- We don't seem to need to force types.CheckSize() on
created/substituted generic types anymore, so commented out for now.
- Add an RParams accessor to types2.Signature, and also a new
exported types2.AsSignature() function.
Change-Id: If6c5dd98427b20bfe9de3379cc16f83df9c9b632
Reviewed-on: https://go-review.googlesource.com/c/go/+/298449
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Over a dozen of the ld tests were missing closes. That was less
obvious before CL 299670 started using T.TempDir instead, which fails
a test when the tempdir can't be cleaned up (as it can't on Windows
when things are still open), insteading of leaving tempdirs around on
disk after the test.
Most of the missing closes were fixed in CL 299670, but the builders
helpfully pointed out that I missed at least this one.
Change-Id: I35f695bb7cbfba31e16311c5af965c148f9d7943
Reviewed-on: https://go-review.googlesource.com/c/go/+/299929
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Trust: Dan Scales <danscales@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
The ValAndOff type is a 64bit integer holding a 32bit value and a
32bit offset in each half, but for historical reasons its Val and Off
methods returned an int64. This was convenient when AuxInt was always
an int64, but now that AuxInts are typed we can return int32 from Val
and Off and get rid of a several casts and now unnecessary range
checks.
This change:
- changes the Val and Off methods to return an int32 (from int64);
- adds Val64 and Off64 methods for convenience in the few remaining
places (in the ssa.go files) where Val and Off are stored in int64
fields;
- deletes makeValAndOff64, renames makeValAndOff32 to makeValAndOff
- deletes a few ValAndOff methods that are now unused;
- removes several validOff/validValAndOff check that will always
return true.
Passes:
GOARCH=amd64 gotip build -toolexec 'toolstash -cmp' -a std
GOARCH=386 gotip build -toolexec 'toolstash -cmp' -a std
GOARCH=s390x gotip build -toolexec 'toolstash -cmp' -a std
(the three GOARCHs with SSA rules files impacted by the change).
Change-Id: I2abbbf42188c798631b94d3a55ca44256f140be7
Reviewed-on: https://go-review.googlesource.com/c/go/+/299149
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The compiler currently has problem that some imported type is missing
size calculation. The problem is not triggered until CL 283313 merged,
due to the compiler can compile the functions immediately when it sees
them, so during SSA generation, size calculation is still ok.
CL 283313 makes the compiler always push functions to compile queue,
then drain from it for compiling function. During this process, the
types calculation size is disabled, so calculating size during SSA now
make the compiler crashes.
To fix this, we can just always calculate type size during typechecking,
when importing type from other packages.
Fixes#44732
Change-Id: I8d00ea0b5aadd432154908280e55d85c75f3ce92
Reviewed-on: https://go-review.googlesource.com/c/go/+/299689
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Limits the number of bytes that can be consumed by Uvarint
to MaxVarintLen64 (10) to avoid wasted computations.
With this change, if Uvarint reads more than MaxVarintLen64
bytes, it'll return the erroring byte count of n=-(MaxVarintLen64+1)
which is -11, as per the function signature.
Updated some tests to reflect the new change in expectations of n
when the number of bytes to be read exceeds the limits..
Fixes#41185
Change-Id: Ie346457b1ddb0214b60c72e81128e24d604d083d
Reviewed-on: https://go-review.googlesource.com/c/go/+/299531
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
When writing code that reflects over a struct type, it's a common requirement to know the full set of struct fields, including fields available due to embedding of anonymous members while excluding fields that are erased because they're at the same level as another field with the same name.
The logic to do this is not that complex, but it's a little subtle and easy to get wrong.
This CL adds a new `VisibleFields` function to the reflect package that returns the full set of effective fields that apply in a given struct type.
Performance isn't a prime consideration, as it's common to cache results by type.
Fixes#42782
Change-Id: I7f1af76cecff9b8a2490f17eec058826e396f660
Reviewed-on: https://go-review.googlesource.com/c/go/+/281233
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Daniel Martí <mvdan@mvdan.cc>
Currently, relocation type is stored as uint8 in object files, as
Go relocations do not exceed 255. In the linker, however, it is
used as a 16-bit type, because external relocations can exceed
255. The linker has to store the extra byte in a side table. This
complicates many things.
Just store it as uint16 in object files. This simplifies things,
with a small cost of increasing the object file sizes.
before after
hello.o 1672 1678
runtime.a 7927784 8056194
Change-Id: I313cf44ad0b8b3b76e35055ae55d911ff35e3158
Reviewed-on: https://go-review.googlesource.com/c/go/+/268477
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Currently, the compiler synthesize a special ".fp" node, which
points to the FP of the current frame, be to used to call
gorecover. Later that node turns to an Arg in SSA that is not
really an arg, causing problems for the new ABI work which changes
the handling of Args, so we have to special-case that node.
This CL changes the compiler to get the FP by using getcallersp,
which is an intrinsic in SSA and works on all platforms. As we
need the FP, not the caller SP, one drawback is that we have to
add FixedFrameSize for LR machines. But it does allow us to remove
that special node.
Change-Id: Ie721d51efca8116c9d23cc4f79738fffcf847df8
Reviewed-on: https://go-review.googlesource.com/c/go/+/297930
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Currently, when instrumenting for the race detector, the compiler
inserts racefuncentry/racefuncentryfp at the entry of instrumented
functions. racefuncentry takes the caller's PC. On AMD64, we synthesize
a node which points to -8(FP) which is where the return address is
stored. Later this node turns to a special Arg in SSA that is not
really an argument. This causes problems in the new ABI work so that
special node has to be special-cased.
This CL changes the special node to a call to getcallerpc, which lowers
to an intrinsic in SSA. This also unifies AMD64 code path and LR machine
code path, as getcallerpc works on all platforms.
Change-Id: I1377e140b91e0473cfcadfda221f26870c1b124d
Reviewed-on: https://go-review.googlesource.com/c/go/+/297929
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
CL 280456 introduced a new store combining rule. On the LHS some
of the Aux and AuxInt of the stores are not specified, therefore
ignored during the matching. The rule is only correct if they
match. This CL adds explict match.
TODO: maybe we want the rule matcher require Aux/AuxInt to be
always specified on the LHS (using _ to explicitly ignore)? Or
maybe we want it to match the zero value if not specified? The
current approach is error-prone.
Fixes#44823.
Change-Id: Ic12b4a0de63117f2f070039737f0c905f28561bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/299289
Trust: Cherry Zhang <cherryyz@google.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Correctly accessing allgs is a bit hairy. Some paths need to lock
allglock, some don't. Those that don't are safest using atomicAllG, but
usage is not consistent.
Rather than doing this ad-hoc, move all access* through forEachG /
forEachGRace, the locking and atomic versions, respectively. This will
make it easier to ensure safe access.
* markroot is the only exception, as it has a far-removed guarantee of
safe access via an atomic load of allglen far before actual use.
Change-Id: Ie1c7a8243e155ae2b4bc3143577380c695680e89
Reviewed-on: https://go-review.googlesource.com/c/go/+/279994
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Previously, if you attempted to fetch a private repository, or your
Git/curl client failed for an unknown reason, codehost would return an
UnknownRevisionError, which reported that a given revision in go.mod
was "unknown". This is confusing to many users who can go look in
their browser for example and see that the commit-ish exists.
Instead check whether "git ls-remote" exited with an error, and if so,
return that instead of the UnknownRevision message.
Fixes#42751.
Change-Id: I0dbded878b2818280e61126a4493767d719ad577
Reviewed-on: https://go-review.googlesource.com/c/go/+/297950
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Now that allglock is no longer taken in throw, paniclk can move to the
bottom of the lock order where it belongs.
There is no fundamental reason that we really need to skip checks on
paniclk in lockWithRank (despite the recursive throws that could be
caused by lock rank checking, startpanic_m would still allow the crash
to complete). However, the partial order of lockRankPanic should be
every single lock that may be held before a throw, nil dereference,
out-of-bounds access, which our partial order doesn't cover.
Updates #42669
Change-Id: Ic3efaea873dc2dd9fd5b0d6ccdd5319730b29a22
Reviewed-on: https://go-review.googlesource.com/c/go/+/270862
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This change modifies the reflect ABI assignment algorithm to catch
zero-sized types at the top level of each argument and faux-stack-assign
them. It doesn't actually generate an ABI step, which is unnecessary,
but it ensures that the offsets of further stack-assigned arguments are
aligned to the alignment of that zero-sized argument.
This change is necessary to have the register ABI assignment algorithm
gracefully degrade to ABI0 when no registers are present in the ABI.
Fixes#44377.
Change-Id: Ia95571688a61259302bb3c6d5fb33fbb6b5e8db8
Reviewed-on: https://go-review.googlesource.com/c/go/+/293789
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
This change switches reflect to use global variables for ABI-related
register counts instead of internal/abi constants. The advantage of
doing so is that we can make the internal/abi constants non-zero and
enable the runtime register argument spiller/unspiller even if they're
not used. It's basically turning two things we need to flip when we
switch to the register ABI into one.
It also paves the way for testing the reflect register ABI path
independently, because now we can switch the global variables at will
and run the register-assignment algorithm in tests without having the
rest of the runtime be broken.
Change-Id: Ie23629a37a5c80aeb24909d4bd9eacbd3f0c06d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/293149
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Previously, if an extracted module directory existed in the module
cache, but the corresponding ziphash file did not, if the sum was
missing from go.sum, we would not verify the sum. This caused 'go get'
not to write missing sums. 'go build' in readonly mode (now the
default) checks for missing sums and doesn't attempt to fetch modules
that can't be verified against go.sum.
With this change, when requesting the module directory with
modfetch.DownloadDir, if the ziphash file is missing, the go command
will re-hash the zip without downloading or re-extracting it again.
Note that the go command creates the ziphash file before the module
directory, but another program could remove it separately, and it
might not be present after a crash.
Fixes#44749
Change-Id: I64551e048a3ba17d069de1ec123d5b8b2757543c
Reviewed-on: https://go-review.googlesource.com/c/go/+/298352
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Most subprocess invocations in the go command use base.AppendPWD to
append an accurate value of PWD to the command's environment, which can
speed up calls like os.Getwd and also help to provide less-confusing
output from scripts. Update `go generate` to do so.
Fixes#43862
Change-Id: I3b756f1532b2d922f7d74fd86414d5567a0122c0
GitHub-Last-Rev: 3ec8da265a
GitHub-Pull-Request: golang/go#43940
Reviewed-on: https://go-review.googlesource.com/c/go/+/287152
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Baokun Lee <bk@golangcn.org>
Map serialization using reflect.Value.MapIndex cannot retrieve
map keys that contain a NaN, resulting in a panic.
Switch the implementation to use the reflect.Value.MapRange method
instead, which iterates over all map entries regardless of whether
they are directly retrievable.
Note that according to RFC 8259, section 4, a JSON object should
have unique names, but does not forbid the occurrence of duplicate names.
Fixes#43207
Change-Id: If4bc55229b1f64b8ca4b0fed37549725efdace39
Reviewed-on: https://go-review.googlesource.com/c/go/+/278632
Trust: Meng Zhuo <mzh@golangcn.org>
Trust: Joe Tsai <thebrokentoaster@gmail.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
Previously, we would sometimes see an internal (*instance) type for a
receiver of a types2 method, which was a bug. To deal with that, we put
in an extra (*Selection).TArgs() method. However, that (*instance) type
is no longer showing up for receivers, so we can remove the types2
method we added and do the work with existing types2 API methods.
Change-Id: I03e68f5bbaaf82fe706b6efecbb02e951bbd3cd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/298869
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
this caused a problem in write barrier code when a spurious
zero-offset prevented a write barrier elision.
removed cache after instrumenting it and discovering
zero safe hits (one value must dominate the other, else
unsafe).
Change-Id: I42dfdb4d38ebfe158b13e766a7fabfc514d773f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/297349
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
'go mod tidy' and 'go mod vendor' normally report errors when a
package can't be imported, even if the import appears in a file that
wouldn't be compiled by the current version of Go. These errors are
common for packages introduced in higher versions of Go, like "embed"
in 1.16.
This change causes 'go mod tidy' and 'go mod vendor' to ignore
missing package errors if the import path appears to come from the
standard library because it lacks a dot in the first path element.
Fixes#44557
Updates #27063
Change-Id: I61d6443e77ab95fd8c0d1514f57ef4c8885a77cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/298749
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
types2 uses the syntax printer to print expressions (for tracing
or error messages), so we need to (at least) print type lists in
interfaces.
While at it, also implement the printing of type parameter lists.
Fixes#44766.
Change-Id: I36a4a7152d9bef7251af264b5c7890aca88d8dc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/298549
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
It turns out that the proc thread update function doesn't actually
allocate new memory for its arguments and instead just copies the
pointer values into the preallocated memory. Since we were allocating
that memory as []byte, the garbage collector didn't scan it for pointers
to Go allocations and freed them. We _could_ fix this by requiring that
all users of this use runtime.KeepAlive for everything they pass to the
update function, but that seems harder than necessary. Instead, we can
just do the allocation as []unsafe.Pointer, which means the GC can
operate as intended and not free these from beneath our feet. In order
to ensure this remains true, we also add a test for this.
Fixes#44662.
Change-Id: Ib392ba8ceacacec94b11379919c8179841cba29f
Reviewed-on: https://go-review.googlesource.com/c/go/+/297389
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This test verifies the behavior of a test that fails due to timing
out. However, the test to be timed out was only sleeping for 1s before
returning successfully. That is empirically not always long enough for
the test process itself to detect the timeout and terminate.
We could replace the sleep with a select{}, but that would assume that
the deadlock detector does not terminate a test that reaches that
state (true today, but not necessarily so).
We could replace the arbitrarily sleep with an arbitrarily longer
sleep, but that's, well, arbitrary.
Instead, have the test sleep in an unbounded loop to ensure that it
always continues to run until the timeout is detected, and check the
test output to ensure that it actually reached the timeout path.
Fixes#32983
Change-Id: Ie7f210b36ef0cc0a4db473f780e15a3d6def8bda
Reviewed-on: https://go-review.googlesource.com/c/go/+/289889
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Verified with test and with single step watching changes to register
values across morestack calls, after reload.
Also added stack-growth test with pointer parameters of varying lifetime.
For #40724.
Change-Id: Idb5fe27786ac5c6665a734d41e68d3d39de2f4da
Reviewed-on: https://go-review.googlesource.com/c/go/+/294429
Trust: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Morestack works for non-pointer register parameters
Within a function body, pointer-typed parameters are correctly
tracked.
Results still not hooked up.
For #40724.
Change-Id: Icaee0b51d0da54af983662d945d939b756088746
Reviewed-on: https://go-review.googlesource.com/c/go/+/294410
Trust: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
After CL 272654, the compiler now use go/constant.Value to represent
constant nodes. That makes ir.ConstantValue requires node type to
correctly return value for untyped int node. But untyped int node can
have nil type after typechecked, e.g: using int value as key for
map[string]int, that makes the compiler crashes.
To fix it, just don't add the invalid key to constSet, since when
it's not important to report duplicated keys when they aren't valid.
For #43311Fixes#44432
Change-Id: I44d8f2b95f5cb339e77e8a705a94bcb16e62beb9
Reviewed-on: https://go-review.googlesource.com/c/go/+/294034
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
When syntax.Parse returns error, noder.file will be nil. Currently, we
continue accessing it regardlessly and depend on gc.hidePanic to hide
the panic from user.
Instead, we should gracefully handle the error in LoadPackage, then exit
earlier if any error occurred.
Updates #43311
Change-Id: I0a108ef360bd4f0cc9f481071b8967355e1513af
Reviewed-on: https://go-review.googlesource.com/c/go/+/294030
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Moved all "target" information into "storeRC"; it was a register
cursor, now it is a register cursor that also carries the store
target with it if there are no registers. Also allows booby-trapping
to ensure that the target is unambiguously one or the other.
For #40724.
Change-Id: I53ba4b91679e5fcc89c63b7d31225135299c6ec6
Reviewed-on: https://go-review.googlesource.com/c/go/+/293397
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Arm64 doesn't have scaled register format, such as (R1*2), (R1)(R2*3),
but currently the assembler doesn't report an error for such kind of
instruction operand format. This CL disables the scaled register
operand format for arm64 and reports an error if this kind of instruction
format is seen.
With this CL, the assembler won't print (R1)(R2) as (R1)(R2*1), so that
we can make the assembly test simpler.
Change-Id: I6d7569065597215be4c767032a63648d2ad16fed
Reviewed-on: https://go-review.googlesource.com/c/go/+/289589
Trust: eric fang <eric.fang@arm.com>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Currently any variable that is spilled onto the stack will occupy at least 8 bytes,
because the stack offset is required to be aligned with 8 bytes on linux/arm64.
This CL removes this constraint by aligning the stack slot with its actual size.
Updates #42385
Change-Id: Icbd63dc70cd19852802e43f134355f19ba7e1e29
Reviewed-on: https://go-review.googlesource.com/c/go/+/267999
Trust: eric fang <eric.fang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Constant of BITCON type can be moved into RSP by MOVD or MOVW instructions
directly, this CL enables this format of these two instructions.
For 32-bit ADDWop instructions with constant, rewrite the high 32-bit
to be a repetition of the low 32-bit, just as ANDWop instructions do,
so that we can optimize ADDW $bitcon, Rn, Rt as:
MOVW $bitcon, Rtmp
ADDW Rtmp, Rn, Rt
The original code is:
MOVZ $bitcon_low, Rtmp
MOVK $bitcon_high,Rtmp
ADDW Rtmp, Rn, Rt
Change-Id: I30e71972bcfd6470a8b6e6ffbacaee79d523805a
Reviewed-on: https://go-review.googlesource.com/c/go/+/289649
Trust: eric fang <eric.fang@arm.com>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This CL adds assembly support for 128-bit FLDPQ and FSTPQ instructions.
This CL also deletes some wrong pre/post-indexed LDP and STP instructions,
such as {ALDP, C_UAUTO4K, C_NONE, C_NONE, C_PAIR, 74, 8, REGSP, 0, C_XPRE},
because when the offset type is C_UAUTO4K, pre and post don't work.
Change-Id: Ifd901d4440eb06eb9e86c9dd17518749fdf32848
Reviewed-on: https://go-review.googlesource.com/c/go/+/273668
Trust: eric fang <eric.fang@arm.com>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Methods of generic types are instantiated lazily (upon use). Thus,
when we encounter a method of such a type, we need to instantiate
the method signature with the receiver type arguments. We infer
those type arguments from the method receiver. If the method is
embedded, we must use the actual embedded receiver type, otherwise
the receiver type declared with the method doesn't match up and
inference will fail.
(Note that there's no type inference in the source code here, it's
only the implementation which uses the existing inference mechanism
to easily identify the actual type arguments. If the implementation
is correct, the inference will always succeed.)
Updates #44688.
Change-Id: Ie35b62bebaeaf42037f2ca00cf8bd34fec2ddd9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/298129
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This fix uses mutex around the problematic store and subsequent access;
if this causes performance problems later a better fix is to do all the
ABI binding in gc/walk where it is single-threaded.
Change-Id: I488f28ab75beb8351c856fd50b0095cab463642e
Reviewed-on: https://go-review.googlesource.com/c/go/+/298109
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Also handles case where OpArg does not escape but has its address
taken.
May have exposed a lurking bug in 1.16 expandCalls,
if e.g., loading len(someArrayOfstructThing[0].secondStringField)
from a local. Maybe.
For #40724.
Change-Id: I0298c4ad5d652b5e3d7ed6a62095d59e2d8819c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/293396
Trust: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The 32 bit versions are easily implement with a single instruction, while the
8 bit versions require a bit more effort but use the same atomic instructions
via rewrite rules.
Change-Id: I42e8d457b239c8f75e39a8e282fc88c1bb292a99
Reviewed-on: https://go-review.googlesource.com/c/go/+/268098
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This allows the use of CLONE_VFORK and CLONE_VM for fork/exec, preventing
'fork/exec ...: cannot allocate memory' failures from occuring when attempting
to execute commands from a Go process that has a large memory footprint.
Additionally, this should reduce the latency of fork/exec on these platforms.
Fixes#31936
Change-Id: I4e28cf0763173145cacaa5340680dca9ff449305
Reviewed-on: https://go-review.googlesource.com/c/go/+/295849
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
types thought it knew how to do this, but that's a lie, because types
doesn't know what the ABI is.
includes extra checking to help prevent things from accidentally working
if they need to be changed but aren't.
For #40724.
Change-Id: I166cd948f262344b7bebde6a2c25e7a7f878bbfb
Reviewed-on: https://go-review.googlesource.com/c/go/+/293393
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
If we don't actually require the listed module, we previously
implicitly resolved "latest", but also (erroneously) forgot to apply
exclusions and retractions for it. But there is really no need to
resolve "latest" in this case at all — now we omit the version from
the reported module info entirely.
Fixes#44296
Change-Id: Id595f52f597c7213bd65b73bf066a678d9e1d694
Reviewed-on: https://go-review.googlesource.com/c/go/+/297150
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
In CL 251159, I removed a hard-coded special case changing the
rewriting behavior for std dependencies in GOROOT/src/vendor and
GOROOT/src/cmd/vendor. Unfortunately, that caused packages in 'std' to
be reported as stale when run within GOROOT/src.
This change restores the special-case behavior, but plumbs it through
the PackageOpts explicitly instead of comparing strings stored in
global variables.
Fixes#44725
Change-Id: If084fe74972ce1704715ca79b0b7e092dd90c88b
Reviewed-on: https://go-review.googlesource.com/c/go/+/297869
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Previously, mvs.Downgrade could introduce spurious dependencies if the
downgrade computed for one module lands on a “hidden” version (such as
a pseudo-version) due to a requirement introduced by the downgrade for
another module.
To eliminate those spurious dependencies, we can add one more call to
BuildList to recompute the “actual” downgraded versions, and then
including only those actual versions in the final call to BuildList.
For #36460
Change-Id: Icc6b54aa004907221b2bcbbae74598b0e4100776
Reviewed-on: https://go-review.googlesource.com/c/go/+/294294
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Add generic rule to rewrite the single-precision square root expression
with one single-precision instruction. The optimization will reduce two
times of precision converting between double-precision and single-precision.
On arm64 flatform.
previous:
FCVTSD F0, F0
FSQRTD F0, F0
FCVTDS F0, F0
optimized:
FSQRTS S0, S0
And this patch adds the test case to check the correctness.
This patch refers to CL 241877, contributed by Alice Xu
(dianhong.xu@arm.com)
Change-Id: I6de5d02281c693017ac4bd4c10963dd55989bd7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/276873
Trust: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
When netpollopen in poll_runtime_pollOpen returns an error, the work in
runtime_pollUnblock and runtime_pollClose can be avoided since the
underlying system call to set up the poller failed.
E.g. on linux, this avoids calling netpollclose and thus epoll_ctl(fd,
EPOLL_CTL_DEL, ...) in case the file does not support epoll, i.e.
epoll_ctl(fd, EPOLL_CTL_ADD, ...) in netpollopen failed.
Fixes#44552
Change-Id: I564d90340fd1ab3a6490526353616a447ae0cfb8
Reviewed-on: https://go-review.googlesource.com/c/go/+/297392
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
While the dev.typeparams branch was merged, the type parameter API is
slated for go1.18. Hide these changes to the go/parser and go/types API.
This was done as follows:
+ For APIs that will probably not be needed for go1.18, simply unexport
them.
+ For APIs that we expect to export in go1.18, prefix symbols with '_',
so that the planned (upper-cased) symbol name is apparent.
+ For APIs that must be exported for testing, move both API and tests
to files guarded by the go1.18 build constraint.
+ parser.ParseTypeParams is unexported and copied wherever it is
needed.
+ The -G flag is removed from gofmt, replaced by enabling type
parameters if built with the go1.18 build constraint.
Notably, changes related to type parameters in go/ast are currently left
exported. We're looking at the AST API separately.
The new API diff from 1.16 is:
+pkg go/ast, method (*FuncDecl) IsMethod() bool
+pkg go/ast, method (*ListExpr) End() token.Pos
+pkg go/ast, method (*ListExpr) Pos() token.Pos
+pkg go/ast, type FuncType struct, TParams *FieldList
+pkg go/ast, type ListExpr struct
+pkg go/ast, type ListExpr struct, ElemList []Expr
+pkg go/ast, type TypeSpec struct, TParams *FieldList
+pkg go/types, type Config struct, GoVersion string
Change-Id: I1baf67e26279b49092e774309a836c460979774a
Reviewed-on: https://go-review.googlesource.com/c/go/+/295929
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>
CL 197938 changed syscall* functions to call entersyscall, instead
of entersyscallblock. It missed syscall_syscallX, probably because
it was in sys_darwin_64.go, not sys_darwin.go like others. Change
that one as well.
Found during the review of CL 270380 (thanks Joel).
Change-Id: I0884fc766703f555a3895be332dccfa7d2431374
Reviewed-on: https://go-review.googlesource.com/c/go/+/286435
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The changes from the (reviewed) dev.regabi copy of expr.go can be seen
by comparing patchset 2 and 7. The actual change is some small
improvements to readability and consistency in untyped conversion,
adding some missing documentation, and removing the "// REVIEW
INCOMPLETE" marker.
Note that expr.go diverges from types2 in its handling of untyped
conversion.
Change-Id: I13a85f6e08f43343e249818245aa857b1f4bf29c
Reviewed-on: https://go-review.googlesource.com/c/go/+/295729
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>
If a canonical version is passed to fixVersion when loading the main
go.mod and that version don't match the module path's major version
suffix, don't call Query.
Query doesn't return a useful error in this case when the path is
malformed, for example, when it doens't have a dot in the first path
element. It's better to report the major version mismatch error.
Fixes#44494
Change-Id: I97b1f64aee894fa0db6fb637aa03a51357ee782c
Reviewed-on: https://go-review.googlesource.com/c/go/+/296590
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Now that we don't automatically pass all inheritable handles to new
processes, we can make pipes returned by os.Pipe() inheritable, just
like they are on Unix. This then allows them to be passed through the
SysProcAttr.AdditionalInheritedHandles parameter simply.
Updates #44011.
Fixes#21085.
Change-Id: I8eae329fbc74f9dc7962136fa9aae8fb66879751
Reviewed-on: https://go-review.googlesource.com/c/go/+/288299
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
One of escape analysis's responsibilities is to summarize whether/how
each function parameter flows to the heap so we can correctly
incorporate those flows into callers' escape analysis data flow
graphs.
As an optimization, we separately record when parameters flow to
result parameters, so that we can more precisely analyze parameter
flows based on how the results are used at the call site. However, if
a named result parameter itself needs to be heap allocated, this
optimization isn't safe and the parameter needs to be recorded as
flowing to heap rather than flowing to result.
Escape analysis used to get this correct because it conservatively
rewalked the data-flow graph multiple times. So even though it would
incorrectly record the result parameter flow, it would separately find
a flow to the heap. However, CL 196811 (specifically, case 3)
optimized the walking logic to reduce unnecessary rewalks causing us
to stop finding the extra heap flow.
This CL fixes the issue by correcting location.leakTo to be sensitive
to sink.escapes and not record result-flows when the result parameter
escapes to the heap.
Fixes#44614.
Change-Id: I48742ed35a6cab591094e2d23a439e205bd65c50
Reviewed-on: https://go-review.googlesource.com/c/go/+/297289
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This fixes two uncommon cases.
First, the tzdata code permits timezone offsets up to 24 * 7, although
the POSIX TZ parsing does not. The tzdata code uses this to specify a
day of week in some cases.
Second, we incorrectly rejected a negative time offset for when a time
zone change comes into effect.
Fixes#44385
Change-Id: I5f2efc1d385e9bfa974a0de3fa81e7a94b827602
Reviewed-on: https://go-review.googlesource.com/c/go/+/296392
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
- Deal with closures in generic functions by fixing the stenciling code
- Deal with instantiated function values (instantiated generic
functions that are not immediately called) during stenciling. This
requires changing the OFUNCINST node to an ONAME node for the
appropriately instantiated function. We do this in a second pass,
since this is uncommon, but requires editing the tree at multiple
levels.
- Check global assignments (as well as functions) for generic function
instantiations.
- Fix a bug in (*subst).typ where a generic type in a generic function
may definitely not use all the type args of the function, so we need
to translate the rparams of the type based on the tparams/targs of
the function.
- Added new test combine.go that tests out closures in generic
functions and instantiated function values.
- Added one new variant to the settable test.
- Enabling inlining functions with closures for -G=3. (For now, set
Ntype on closures in -G=3 mode to keep compatibility with later parts
of compiler, and allow inlining of functions with closures.)
Change-Id: Iea63d5704c322e42e2f750a83adc8b44f911d4ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/296269
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
This allows users to specify which process should be used as the parent
process when creating a new process.
Note that this doesn't just trivially pass the handle onward to
PROC_THREAD_ATTRIBUTE_PARENT_PROCESS, because inherited handles must be
valid in the parent process, so if we're changing the destination
process, then we must also change the origin of the parent handles. And,
the StartProcess function must clean up these handles successfully when
exiting, regardless of where the duplication happened. So, we take care
in this commit to use DuplicateHandle for both duplicating and for
closing the inherited handles.
The test was taken originally from CL 288272 and adjusted for use here.
Fixes#44011.
Change-Id: Ib3b132028dcab1aded3dc0e65126c8abebfa35eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/288300
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
This allows users to specify handles that they explicitly want to be
inherited by the new process. These handles must already be marked as
inheritable.
Updates #44011.
Updates #21085.
Change-Id: Ib18322e7dc2909e68c4209e80385492804fa15d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/288298
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Windows does not have CLOEXEC, but rather handles are marked explicitly
for being inherited by new processes. This can cause problems when
different Windows functions create new processes from different threads.
syscall.StartProcess has traditionally used a mutex to prevent races
with itself, but this doesn't handle races with other win32 functions.
Fortunately there's a solution: PROC_THREAD_ATTRIBUTE_HANDLE_LIST allows
us to pass the entire list of handles that we want to be inherited. This
lets us get rid of the mutex and also makes process creation safe across
the Go runtime, no matter the context.
Updates #44011.
Change-Id: Ia3424cd2ec64868849cbd6cbb5b0d765224bf4ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/288297
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
For now, this only add a single relocation type, which is sufficient for
Windows resources. Later we'll see if we need more for cgo.
In order to ensure these code paths are actually tested, this expands
the rsrc tests to include all the architectures of PE objects that we
need to be recognizing, and splits things more clearly between binutils
and llvm objects, which have a slightly different layout, so that we
test both.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: Ia1ee840265e9d12c0b12dd1c5d0810f8b300e557
Reviewed-on: https://go-review.googlesource.com/c/go/+/289429
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
When using plugins, a type (whose value) may be pass to a plugin
and get converted to interface there, or vice versa. We need to
treat the type as potentially converted to interface, and retain
its methods.
Should fix#44586.
Change-Id: I80dd35e68baedaa852a317543ccd78d94628d13b
Reviewed-on: https://go-review.googlesource.com/c/go/+/296709
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
In CL 253457, we did the same fix for direct function calls. But for
method calls, the receiver argument also need to be passed through the
wrapper function, which we are not doing so the compiler crashes with
the code in #44415.
It will be nicer if we can rewrite OCALLMETHOD to normal OCALLFUNC, but
that will be for future CL. The passing receiver argument to wrapper
function is easier for backporting to go1.16 branch.
Fixes#44415
Change-Id: I03607a64429042c6066ce673931db9769deb3124
Reviewed-on: https://go-review.googlesource.com/c/go/+/296490
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
StaticLECall (multiple value in +mem, multiple value result +mem) ->
StaticCall (multiple ergister value in +mem,
multiple register-sized-value result +mem) ->
ARCH CallStatic (multiple ergister value in +mem,
multiple register-sized-value result +mem)
But the architecture-dependent stuff is indifferent to whether
it is mem->mem or (mem)->(mem) until Prog generation.
Deal with OpSelectN -> Prog in ssagen/ssa.go, others, as they
appear.
For #40724.
Change-Id: I1d0436f6371054f1881862641d8e7e418e4a6a16
Reviewed-on: https://go-review.googlesource.com/c/go/+/293391
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
ComputeAddrtaken needs to descend into closures, now that imported
bodies can include closures. The bug was that we weren't properly
setting Addrtaken for a variable inside a closure inside a function that
we were importing.
For now, still disable inlining of functions with closures for -G mode.
I'll enable it in a later change -- there are just a few fixes related
to the fact that we don't need to set Ntype for closure functions.
Added a test derived from the cilium repro in the issue.
Fixes#44370
Change-Id: Ida2a403636bf8740b471b3ad68b5474951811e19
Reviewed-on: https://go-review.googlesource.com/c/go/+/296649
Run-TryBot: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
These are the the most common uses, and they reduce line noise.
I don't love adding new deprecated APIs,
but since they're trivial wrappers,
it'll be very easy to update them along with the rest.
No functional changes; passes toolstash-check.
Change-Id: I691a8175cfef9081180e463c63f326376af3f3a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/296009
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This reverts commit CL 294849.
Reason for revert: this doesn't actually fix the issue, as revealed
by the noopt builder's failures.
Change-Id: Ib4ea9ceb4d75e46b3b91ec348b365fd8c83316ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/296629
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The code for delayed declaration of inlined result parameters only
handles non-empty return statements. This is generally okay, because
we already early declare if there are any (non-blank) named result
parameters.
But if a user writes a function with only blank result parameters and
with exactly one return statement, which is empty, then they could end
up hitting the dreaded "Value live at entry" ICE.
This CL fixes the issue by ensuring we always early declare inlined
result parameters if there are any empty return statements.
Fixes#44355.
Change-Id: I315f3853be436452883b1ce31da1bdffdf24d506
Reviewed-on: https://go-review.googlesource.com/c/go/+/293293
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
In CL 253457, we did the same fix for direct function calls. But for
method calls, the receiver argument also need to be passed through the
wrapper function, which we are not doing so the compiler crashes with
the code in #44415.
As we already rewrite t.M(...) into T.M(t, ...) during walkCall1, to fix
this, we can do the same trick in wrapCall, so the receiver argument
will be treated as others.
Fixes#44415
Change-Id: I396182983c85d9c5e4494657da79d25636e8a079
Reviewed-on: https://go-review.googlesource.com/c/go/+/294849
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This function has the wrong signature, so return an error when that
actually might lead to unexpected results. Users should switch to
x/sys/windows for the real version of this function.
Updates #44538.
Change-Id: I4d1f3d1e380815733ecfea683f939b1d25dcc32a
Reviewed-on: https://go-review.googlesource.com/c/go/+/296154
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Follow the implementation used by the other BSDs and account for the
intricacy of having to pass the fds array even though the file
descriptors are returned.
Re-submit of CL 130996 with corrected pipe2 wrapper.
Change-Id: Ie36d8214cba60c4fdb579f18bfc1c1ab3ead3ddc
Reviewed-on: https://go-review.googlesource.com/c/go/+/295372
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
On windows/arm, the abort is given from one byte off of the function
address, perhaps because Windows wants to simulate x86/amd64 modes, or
because it's jumping from thumb mode. This is not the case with
windows/arm64, though.
This prevents a failure in the builders with the TestAbort test:
crash_test.go:727: output contains BAD:
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
panic: BAD: recovered from abort
[signal 0xc0000005 code=0x0 addr=0x0 pc=0x6a5721]
Change-Id: I8939c60611863cc0c325e179a772601acea9fd4a
Reviewed-on: https://go-review.googlesource.com/c/go/+/296153
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Work in progress.
TODO:
- insert debugging output for all the steps listed below
- emit modified call instructions w/ multiple register inputs
and Result-typed outputs (next CL)
- initially just change output from "mem" to "Result{mem}"
= most places this hits will be future work.
- change OpArg to use registerized variants
- (done) match abi paramresultinfo with particular arg, use Name
- (this CL) push register offsets for "loads" and "stores" into
recursive decomposition.
- hand registerized Result to exit block
For #40724.
Change-Id: Ie5de9d71f8fd4e092f5ee9260b54de35abf91016
Reviewed-on: https://go-review.googlesource.com/c/go/+/293390
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
This fixes a bug in the internal ABI specification that made it not
equivalent to ABI0 even with zero architectural argument registers in
the case of a zero-sized argument with alignment > 1.
In ABI0, even zero-sized arguments cause alignment padding in the
stack frame.
Currently, in the internal ABI, zero-sized arguments get
register-assigned even if there are no registers because they don't
consume any registers. Hence, they don't create alignment padding in
the stack frame.
Fix this by stack-assigning zero-sized arguments.
For #40724.
Change-Id: I1f5a95a94fed8b5313a360e5e76875701ba5f562
Reviewed-on: https://go-review.googlesource.com/c/go/+/295791
Trust: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Florian Weimer pointed out that my justification for using MMX mode
was nonsense and that staying in x87 mode simplifies transitions to
and from C. Hence, switch the spec to say we're always in x87 mode.
For #40724.
Change-Id: Iad916b2c376db41f95614aa6897f6b1184576bb7
Reviewed-on: https://go-review.googlesource.com/c/go/+/295789
Trust: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
The code generated when storing eight bytes loaded from memory created a
series of small writes instead of a single, large one. The specific
pattern of instructions generated stored 1 byte, then 2 bytes, then 4
bytes, and finally 1 byte.
The new rules match this specific pattern both for amd64 and for s390x,
and convert it into a single instruction to store the 8 bytes. arm64 and
ppc64le already generated the right code, but the new codegen test
covers also those architectures.
Fixes#41663
Change-Id: Ifb9b464be2d59c2ed5034acf7b9c3e473f344030
Reviewed-on: https://go-review.googlesource.com/c/go/+/280456
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
The third argument to GetQueuedCompletionStatus is a pointer to a
uintptr, not a uint32. Users of this functions have therefore been
corrupting their memory every time they used it. Either that memory
corruption was silent (dangerous), or their programs didn't work so they
chose a different API to use.
Fixes#44538.
RELNOTES=yes
Change-Id: Idf48d4c712d13da29791e9a460159255f963105b
Reviewed-on: https://go-review.googlesource.com/c/go/+/295371
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Plumb abi information into ssa/ssagen for plain calls
and plain functions (not methods). Does not extend all the
way through the compiler (yet).
One test disabled because it extends far enough to break the test.
Normalized all the compiler's register args TODOs to
// TODO(register args) ...
For #40724.
Change-Id: I0173a4579f032ac3c9db3aef1749d40da5ea01ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/293389
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
OCONVOP doesn't have effect in the compiled code so, it can be safely
excluded from inline cost calculation.
Also make sequence ODEREF OCONVNOP* OADDR cost 1. This is rather common
conversion, such as *(*uint32)(unsafe.Pointer(&x)).
Fixes#42788
Change-Id: I5001f7e89d985c198b6405694cdd5b819cf3f47a
Reviewed-on: https://go-review.googlesource.com/c/go/+/281232
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Elias Naur <mail@eliasnaur.com>
Use an atomic.Value to hold the done channel.
Conveniently, we have a mutex handy to coordinate writes to it.
name old time/op new time/op delta
ContextCancelDone-8 67.5ns ±10% 2.2ns ±11% -96.74% (p=0.000 n=30+28)
Fixes#42564
Change-Id: I5d72e0e87fb221d4e230209e5fb4698bea4053c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/288193
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Sameer Ajmani <sameer@golang.org>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
For mips32 currently, we are using FP32, while the gcc may be FPXX,
which may generate .MIPS.abiflags and .gnu.attributes section with
value as FPXX. So the kernel will treat the exe as FPXX, and may
choose to use FR=1 FPU mode for it.
Currently, in Go, we use 2 lwc1 to load both half of a double value
to a pair of even-odd FPR. This behavior can only work with FR=0 mode.
In FR=1 mode, all of 32 FPR are 64bit. If we lwc1 the high-half of a double
value to an odd FPR, and try to use the previous even FPR to compute, the
real high-half of even FPR will be unpredicatable.
We set -mfp32 to force the gcc generate FP32 code and section value.
More details about FP32/FPXX/FP64 are explained in:
https://web.archive.org/web/20180828210612/https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking
When GOMIPS/GOMIPS64 is set as softfloat, we should also pass
-msoft-float to gcc.
Here we also add -mno-odd-spreg option, since Loongson's CPU cannot use
odd-number FR in FR=0 mode.
Fixes#39435
Change-Id: I54026ad416a815fe43a9261ebf6d02e5519c3930
Reviewed-on: https://go-review.googlesource.com/c/go/+/237058
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Meng Zhuo <mzh@golangcn.org>
The decodeState type is a large part of the allocated space during Unmarshal.
The errorContext field is infrequently used, and only on error.
Extract it into a pointer and allocate it separate when necessary.
name old time/op new time/op delta
UnmarshalString-8 115ns ± 5% 114ns ± 3% ~ (p=0.170 n=15+15)
UnmarshalFloat64-8 113ns ± 2% 106ns ± 1% -6.42% (p=0.000 n=15+14)
UnmarshalInt64-8 93.3ns ± 1% 86.9ns ± 4% -6.89% (p=0.000 n=14+15)
name old alloc/op new alloc/op delta
UnmarshalString-8 192B ± 0% 160B ± 0% -16.67% (p=0.000 n=15+15)
UnmarshalFloat64-8 180B ± 0% 148B ± 0% -17.78% (p=0.000 n=15+15)
UnmarshalInt64-8 176B ± 0% 144B ± 0% -18.18% (p=0.000 n=15+15)
name old allocs/op new allocs/op delta
UnmarshalString-8 2.00 ± 0% 2.00 ± 0% ~ (all equal)
UnmarshalFloat64-8 2.00 ± 0% 2.00 ± 0% ~ (all equal)
UnmarshalInt64-8 1.00 ± 0% 1.00 ± 0% ~ (all equal)
Change-Id: I53f3f468e6c65f77a12e5138a2626455b197012d
Reviewed-on: https://go-review.googlesource.com/c/go/+/271338
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Daniel Martí <mvdan@mvdan.cc>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Daniel Martí <mvdan@mvdan.cc>
This test contained a data race.
On line 437, db.BeginTx starts a goroutine that runs tx.awaitDone,
which reads tx.keepConnOnRollback.
On line 445, the test writes to tx.keepConnOnRollback.
tx.awaitDone waits on ctx, but because ctx is timeout-based,
there's no ordering guarantee between the write and the read.
The race detector never caught this before
because the context package implementation of Done
contained enough synchronization to make it safe.
That synchronization is not package of the context API or guarantees,
and the first several releases it was not present.
Another commit soon will remove that synchronization,
exposing the latent data race.
To fix the race, emulate a time-based context
using an explicit cancellation-based context.
This gives us enough control to avoid the race.
Change-Id: I103fe9b987b1d4c02e7a20ac3c22a682652128b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/288493
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
The changes from the (reviewed) dev.regabi copy of call.go can be seen
by comparing patchset 1 and 4. The actual changes are removing the
"// REVIEW INCOMPLETE" marker, deleting some leftover handling of type
instantiation in Checker.call, and adding a comment that exprOrTypeList
should be refactored.
I started to refactor exprOrTypeList, but thought it best to mark this
code as reviewed before diverging from types2.
Change-Id: Icf7fbff5a8def49c5f1781472fd7ba7b73dd9a9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/295531
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>
Is and isExcludingLatin did not handle negative runes when dispatching
to is16. TestNegativeRune covers this along with the existing uint32
casts in IsGraphic, etc. (For tests, I picked the smallest non-Latin-1
code point in each range.)
Updates #43254
Change-Id: I17261b91f0d2b5b5125d19219411b45c480df74f
Reviewed-on: https://go-review.googlesource.com/c/go/+/280493
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Test NoRaceMutexPureHappensBefore in runtime/race/testdata/mutex_test.go
expects the second spawned goroutine to run after the first. The test
attempts to force this scheduling with a 10 millisecond wait. Following
a suggestion by Bryan Mills, we force this scheduling using a shared
variable whose access take place within the existing mutex.
Fixes#35745.
Change-Id: Ib23ec51492ecfeed4752e020401dd25755a669ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/291292
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This template is based on CL 248198 and previous ones like it.
Continue to eagerly include often-used sections, and clarify that
the TODO is about completing the section, or removing if it turns
out not to be needed.
Move the Go 1.16 release notes to x/website, since that's the new
home for past Go release notes as of CL 291711. They're added to
x/website in CL 295249.
'relnote -html' does not report any CLs with RELNOTE annotations
since 2021/02/01.
For #44513.
Updates #40700.
Change-Id: Idd389335500ec4dec2764cbbaa385918cc8a79ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/295209
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
If the race detector were runnable in dynamic linking mode,
then R15 would get clobbered. I don't think it is, so maybe
not a problem, but can't hurt to clean it up.
It also lets CL 283474 pass cleanly when checking the whole stdlib
(together with CL 288452).
Change-Id: I5a5021ecc7e7b8bed1cd3a7067c39b24c09e0783
Reviewed-on: https://go-review.googlesource.com/c/go/+/289270
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When in dynlink mode, reading a global can clobber R15.
Just to be safe, save R15 before checking the AVX state to see
if we need to VZEROUPPER or not.
This could cause a problem in buildmodes that aren't supported yet.
Change-Id: I8fda62d3fbe808584774fa5e8d9810a4612a84e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/288452
Trust: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
MOV*nop and MOV*reg seem superfluous. They are there to keep type
information around that would otherwise get thrown away. Not sure
what we need it for. I think our compiler needs a normalization of
how types are represented in SSA, especially after lowering.
MOV*nop gets in the way of some optimization rules firing, like for
load combining.
For now, just fold MOV*nop and MOV*const. It's certainly safe to
do that, as the type info on the MOV*const isn't ever useful.
R=go1.17
Change-Id: I3630a80afc2455a8e9cd9fde10c7abe05ddc3767
Reviewed-on: https://go-review.googlesource.com/c/go/+/276792
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
nowdays, in runtime/mgc.go,we can see the comment descrition : The fractional worker is necessary when GOMAXPROCS*gcBackgroundUtilization is not an integer.
but it not true such as GOMAXPROCS=5.
in the implemet of startCycle() , Fractional Mode happend only when
GOMAXPROCS<=3 or GOMAXPROCS=6. so utilization can closest to 25%.
Fixes#44380
Change-Id: Id0dd6d9f37759c2c9231f164a013a014216dd442
GitHub-Last-Rev: 5910e76324
GitHub-Pull-Request: golang/go#44381
Reviewed-on: https://go-review.googlesource.com/c/go/+/293630
Reviewed-by: Austin Clements <austin@google.com>
Trust: Michael Pratt <mpratt@google.com>
As done with other equality tests, zero extend before subtraction rather than
after (or in this case, at the same time). While at face value this appears to
require more instructions, in reality it allows for most sign extensions to
be completely eliminated due to correctly typed loads. Existing optimisations
(such as subtraction of zero) then become more effective.
This removes more than 10,000 instructions from the Go binary and in particular,
a writeBarrier check only requires three instructions (AUIPC, LWU, BNEZ) instead
of the current four (AUIPC, LWU, NEGW, BNEZ).
Change-Id: I7afdc1921c4916ddbd414c3b3f5c2089107ec016
Reviewed-on: https://go-review.googlesource.com/c/go/+/274066
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Changed calling convention to pre-multiply the argument by -100,
and then deleted the * 100 but not the negation in the windows/arm assembly.
Delete the negation.
Fixes the current all.bash breakage on windows/arm builder.
(Maybe that will uncover more.)
Change-Id: I13006a44866ecc007586deb180a49c038d70aa99
Reviewed-on: https://go-review.googlesource.com/c/go/+/295529
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This is partial plumbing recycled from the original register abi test work;
these are the parts that translate easily. Some other bits are deferred till
later when they are ready to be used.
For #40724.
Change-Id: Ica8c55a4526793446189725a2bc3839124feb38f
Reviewed-on: https://go-review.googlesource.com/c/go/+/260539
Trust: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Some bit test instruction generation stopped triggering after
the change to addressing modes. I suspect this was just because
ANDQload was being generated before the rewrite rules could discover
the BTQ. Fix that by decomposing the ANDQload when it is surrounded
by a TESTQ (thus re-enabling the BTQ rules).
Fixes#44228
Change-Id: I489b4a5a7eb01c65fc8db0753f8cec54097cadb2
Reviewed-on: https://go-review.googlesource.com/c/go/+/291749
Trust: Keith Randall <khr@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Previously, some special register uses are only guarded with ABI
wrapper generation (-abiwrap). This CL makes it also guarded with
the GOEXPERIMENT. This way we can enable only the wrapper
generation without fully the new ABI, for benchmarking purposes.
Change-Id: I90fc34afa1dc17c9c73e7b06e940e79e4c4bf7f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/295289
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Since allocation for p struct will be rounded up to the next size class,
the two relevant adjacent classes for this case are 9728 bytes and 10240 bytes.
A p is currently 10072 bytes, so it gets rounded up to 10240 bytes when we allocate one,
So the pad in p struct is unnecessary, eliminate it and add comments for
warning the false sharing.
Change-Id: Iae8b32931d1beddbfff1f58044d8401703da6407
Reviewed-on: https://go-review.googlesource.com/c/go/+/268759
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
GCC and Clang both set the SizeOfRawData field rather than the
VirtualSize field for communicating the size of the .bss section. As a
consequence, LLD does not look at VirtualSize and collapses the .bss
section into whatever is around it, resulting in runtime crashes. This
commit changes the logic so that if the requested "file size" is 0, then
the SizeOfRawData field is set rather than the VirtualSize field as the
sole length marker.
Fixes#44250.
Fixes#39326.
Updates #38755.
Updates #36439.
Updates #43800.
Change-Id: Ied89ddaa0a717fed840238244c6e4848845aeeb6
Reviewed-on: https://go-review.googlesource.com/c/go/+/291630
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Check that the target of a constant load is a register and add test coverage
for this error condition. While here, rename the RISC-V testdata and tests
to be consistent with other platforms.
Change-Id: I7fd0bfcee8cf9df0597d72e65cd74a2d0bfd349a
Reviewed-on: https://go-review.googlesource.com/c/go/+/292895
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This CL rebases CL 273694 on top of master with @mdempsky's permission.
For assertE2I and assertI2I, there's no need to pass through the
interface's data pointer: it's always going to come back unmodified.
For assertE2I2 and assertI2I2, there's no need for an extra bool
result parameter: it's redundant with testing the returned interface
value for nil.
Change-Id: Ic92d4409ad381952f875d3d74b8cf11c32702fa6
Reviewed-on: https://go-review.googlesource.com/c/go/+/292892
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The only different between selectnbrecv and selectnbrecv2 is the later
set the input pointer value by second return value from chanrecv.
So by making selectnbrecv return two values from chanrecv, we can get
rid of selectnbrecv2, the compiler can now call only selectnbrecv and
generate simpler code.
Change-Id: Ifaf6cf1314c4f47b06ed9606b1578319be808507
Reviewed-on: https://go-review.googlesource.com/c/go/+/292890
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently, we keep track of slice len by mapping from slice ID to
len/cap SSA value. However, slice len/cap can have multiple SSA values,
so when updating fact table for slice len/cap, we only update in one
place.
Instead, we can take advantage of the transitive relations provided by
poset. So all duplicated slice lens are set as equal to one another.
When updating fact table for one, that fact will be reflected to all
others. The same mechanism is applied for slice cap.
Removes 15 bounds checks from std/cmd.
Fixes#42603
Change-Id: I32c07968824cc33765b1e441b3ae2c4b5f5997c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/273670
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Type string printing special-cased printing of unsafe.Pointer because
it's a built-in type; yet it's declared in a package like any other
imported or used-defined type (unlike built-in types such as int).
Use the same mechanism for printing unsafe.Pointer like any other
(non-basic) type. This will make it possible to use the package
Qualifier if so desired.
Fixes#44515.
Change-Id: I0dd1026f850737ecfc4bb99135cfb8e3c18be9e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/295271
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/conversions.go
and conversions.go can be seen by comparing patchset 1 and 2. The actual
change is just removing the "// UNREVIEWED" marker.
Change-Id: I86d20d8100ec29fe3be996b975c9b4aff01be85e
Reviewed-on: https://go-review.googlesource.com/c/go/+/294509
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/issues_test.go
and issues_test.go can be seen by comparing patchset 1 and 3. The actual
change is just removing the "// UNREVIEWED" marker and making making
some minor code adjustments to match go/types's version more closely.
Change-Id: I26f3f700d12db69fc68161a6b0dc081a0e9cd0d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/294473
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
For import of functions with closures, the connections among closure
variables are constructed on-the-fly via CaptureName(). For multiple
nested closures, we need to temporarily set r.curfn to each closure we
construct, so that the processing of closure variables will be correct
for any nested closure inside that closure.
Fixes#44335
Change-Id: I34f99e2822250542528ff6b2232bf36756140868
Reviewed-on: https://go-review.googlesource.com/c/go/+/294212
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
On my machine (3.1 GHz Quad-Core Intel Core i7, macOS 10.15.7 10.15.7), go 1.15.6
benchstat:
name old time/op new time/op delta
SearchInts-8 20.3ns ± 1% 16.6ns ± 6% -18.37% (p=0.000 n=9+10)
Change-Id: I346e5955fd6df6ce10254b22267dbc8d5a2b16c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/279439
Reviewed-by: Ben Shi <powerman1st@163.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
The parser was returning the indexed operand when a slice or index or
instance expression was missing any index arguments (as in the
expression `a[]`). This can result in returning an *ast.Ident for the
LHS of the (invalid) assignment `a[] = ...` -- in this case parsing the
LHS as just `a`. Unfortunately, as the indexed operand `a` has already
been resolved, this results in a panic for duplicate resolution.
Fix this by instead returning an ast.BadExpr. This can suppress some
subsequent errors from the typechecker, but those errors may or may not
be correct anyway. Other interpretations, such as an *ast.IndexExpr with
bad or missing X, run into potential misinterpretations downstream (both
caused errors in go/types and/or gopls).
Fixes#44504
Change-Id: I5ca8bed4a1861bcc7db8898770b08937110981d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/295151
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>
In CL 288093 we reserve X15 as the zero register and use that to
zero values. It only covered zeroing generated in SSA but missed
zeroing the frame generated late in the compilation. The latter
still uses X0, but now DUFFZERO expects X15, so it doesn't
actually zero the frame. Change it to use X15.
Should fix#44333.
Change-Id: I239d2b78a5f6468bc86b70aecdd294045311759f
Reviewed-on: https://go-review.googlesource.com/c/go/+/295210
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
One CFGs that shortcircuit looks for is:
p q
\ /
b
/ \
t u
The test case creates a CFG like that in which p == t.
That caused the compiler to generate a (short-lived) invalid phi value.
Fix this with a relatively big hammer: Disallow single-length loops entirely.
This is probably overkill, but it such loops are very rare.
This doesn't change the generated code for anything in std.
It generates worse code for the test case:
It no longer compiles the entire function away.
Fixes#44465
Change-Id: Ib8cdcd6cc9d7f48b4dab253652038ace24eae152
Reviewed-on: https://go-review.googlesource.com/c/go/+/295130
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
This is no-functionality change to begin the process of supporting
more than 6 operands.
This rewrites the table to use named arguments, and removes default
initialized argument values. The following sed regexes rewrote the table:
s/{\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\)}/{as:\1,a1:\2,a2:\3,a3:\4,a4:\5,type_:\6,size:\7,param:\8}
s/a[1-4]: C_NONE, //g
s/, param: 0//
Change-Id: I5f4de9da75f2fb3964d625d6b4e2f1ce1e29cc47
Reviewed-on: https://go-review.googlesource.com/c/go/+/294189
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Change the TestInstallationImporter testpoint to query type
information for sort.Search instead of sort.Ints. The latter function
changed recently (1.16 timeframe), parameter "a" is now "x". A better
candidate for this sort of query is sort.Search, which has been stable
for a while.
Fixes#44425.
Change-Id: I314476eac0b0802f86f5cbce32195cab2926db83
Reviewed-on: https://go-review.googlesource.com/c/go/+/294290
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
DWARF generation uses variable source positions (file/line/col) as a
way to uniquely identify locals and parameters, as part of the process
of matching up post-optimization variables with the corresponding
pre-optimization versions (since the DWARF needs to be in terms of the
original source constructs).
This strategy can run into problems when compiling obfuscated or
machine-generated code, where you can in some circumstances wind up
with two local variables that appear to have the same name, file,
line, and column. This patch changes DWARF generation to skip over
such duplicates as opposed to issuing a fatal error (if an
obfuscation tool is in use, it is unlikely that a human being will be
able to make much sense of DWARF info in any case).
Fixes#44378.
Change-Id: I198022d184701aa9ec3dce42c005d29b72d2e321
Reviewed-on: https://go-review.googlesource.com/c/go/+/294289
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild
Gofmt and any other go/printer-using program will now:
- move //go:build and //+build lines to the appropriate file location
- if there's no //go:build line, add one derived from the // +build lines
- if there is a //go:build line, recompute and replace any // +build lines
to match what the //go:build line says
For Go 1.17.
Change-Id: Ide5cc3b4a07507ba9ed6f8b0de846e840876f49f
Reviewed-on: https://go-review.googlesource.com/c/go/+/240608
Trust: Russ Cox <rsc@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The spec states that a type "may" have a method set associated with it.
Yet every type has a method set, which may be empty. This is clarified
later in the same paragraph. Be clear in the first sentence as well.
Per the suggestion from https://github.com/DQNEO.
Fixes#44318.
Change-Id: I6097b1c7062853e404b7fead56d18a7f9c576fc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/292853
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In its final phase, the typechecker walks the types it produces to
ensure that no unexpanded type instances leak through the API. However,
this also walks shared types (such as those in the universe scope),
resulting in a potential data race during concurrent typechecking
passes.
Fix this by being careful not to write if nothing needs to be changed.
Since any shared types should already be sanitized, this should
eliminate data races.
For #44434
Change-Id: Iadb2e78863efe0e974e69a00e255f26cfaf9386a
Reviewed-on: https://go-review.googlesource.com/c/go/+/294411
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
By default, when typechecking a closure, tcClosure() creates a new
closure function. This should really be done separate from typechecking.
For now, we explicitly avoid creating a new closure function when
typechecking an inline body (in ImportedBody). However, the heuristic
for determining when we are typechecking an inline body was not correct
for double nested closures in an inline body, since CurFunc will then be
the inner closure, which has a body.
So, use a simple global variable to indicate when we typechecking an
inline body. The global variable is fine (just like ir.CurFunc), since
the front-end runs serially.
Fixes#44325
Change-Id: If2829fe1ebb195a7b1a240192b57fe6f04d1a36b
Reviewed-on: https://go-review.googlesource.com/c/go/+/294211
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
The codereview sync-branch command wants all involved
branches to have codereview.cfg, and this will help us when
we transition from master to main later this year.
Change-Id: Ia8e4c8b8c86864ed9d730e5d96be1ff386e2e1cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/294291
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
netbsd/amd64's Syscall9 changes SP using ADD and SUB,
which are treated as SPWRITEs (they are not accounted for
in the sp-adjust tracking, and there are too many functions that
would report mismatched stack adjustments at RET if they were).
A traceback starting in Syscall9 as saved by entersyscall complains
about the SPWRITE-ness unnecessarily, since the PC/SP are saved
at the start of the function. Ignore SPWRITE in that case.
netbsd/arm's Syscall6 also changes SP (R13), using a direct write.
So even if we could handle the ADD/SUB in the amd64 case or
rewrote that assembly, we'd still be stuck with a more difficult
problem in this case. Ignoring the SPWRITE fixes it.
Example crashes:
https://build.golang.org/log/160fc7b051a2cf90782b75a99984fff129329e66https://build.golang.org/log/7879e2fecdb400eee616294285e1f952e5b17301
Change-Id: I0c8e9696066e90dafed6d4a93d11697da23f0080
Reviewed-on: https://go-review.googlesource.com/c/go/+/294072
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
This is failing but only under the race detector.
It doesn't really seem fair to expect pprof to find
specific profile events with the race detector slowing
everything down anyway.
Change-Id: I4b353d3d63944c87884d117e07d119b2c7bf4684
Reviewed-on: https://go-review.googlesource.com/c/go/+/294071
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The regabi builders are unhappy about badctxt calling throw
calling systemstack calling gosave_systemstack_switch calling
badctxt, all nosplit, repeating. This wouldn't actually happen
since after one systemstack we'd end up on the system stack
and the next one wouldn't call gosave_systemstack_switch at all.
The badctxt call itself is in a very unlikely assertion failure
inside gosave_systemstack_switch.
Keep the assertion check but call runtime.abort instead on failure,
breaking the detected (but not real) cycle.
Change-Id: Iaf5c0fc065783b8c1c6d0f62d848f023a0714b96
Reviewed-on: https://go-review.googlesource.com/c/go/+/294069
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When generating DWARF inlined info records, it's possible to have a
local function whose only callsites are inlined away, meaning that we
emit an abstract function DIE but no regular subprogram DIE. When
emitting DWARF scope info we need to handle this case (specifically
when scoping PCs, check for the case that the func in question has
been entirely deleted).
Fixes#44344.
Change-Id: I9f5bc692f225aa4c5c23f7bd2e50bcf7fe4fc5f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/293309
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
An embedded struct field is embedded by mentioning its type.
The fact that the field name may be different and derived
from the type doesn't matter for the struct type.
Do print the embedded type rather than the derived field
name, as we have always done in the past. Remove the fancy
new code which was just plain wrong.
The struct output printing is only relevant for debugging
and test cases. Reverting to the original code (pre-generics)
fixes a couple of x/tools tests.
Unfortunately, the original code is (also) not correct for
embedded type aliases. Adjusted a gccgoimporter test
accordingly and filed issue #44410.
This is a follow-up on https://golang.org/cl/293961 which
addressed the issue only partially and left the incorrect
code in place.
Change-Id: Icb7a89c12ef7929c221fb1a5792f144f7fcd5855
Reviewed-on: https://go-review.googlesource.com/c/go/+/293962
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Before this CL, the parser consumed the next token following an invalid
selector expr no matter what it was. This leads to poor error recovery
when this next token is a closing delimiter or other reasonable element
of a stop set. As a side-effect, x/tools tests broke when parser logic
for type parameters was introduced, as they threw off the parser
synchronization to the point where the x/tools test bailed out.
This CL introduces a targeted fix that allows the x/tools tests to pass.
More general improvement for parser error recovery should be done for
go1.17.
Change-Id: I44d73d34b6063e62d16a23d24ab7cbce6500239d
Reviewed-on: https://go-review.googlesource.com/c/go/+/293792
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Prior to 1.16, go/types printed an embedded struct field by simply
printing its type, which may have included a package qualification.
Just printing the type is not useful with generic types and we now
must print the actual field name derived from the type - this leads
to different output for non-generic imported embedded types. Fix by
printing a package qualification in that case.
Change-Id: I2cb2484da7732428d13fdfb5fe4ec1fa1ee813a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/293961
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reqs currently combines requirements with upgrades and downgrades.
However, only Upgrade needs the Upgrade method, and only Downgrade
needs the Previous method.
When we eventually add lazy loading, the lazily-loaded module graph
will not be able to compute upgrades and downgrades, so the
implementation work from here to there will be clearer if we are
explicit about which are still needed.
For #36460
Change-Id: I7bf8c2a84ce6bc4ef493a383e3d26850e9a6a6c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/290771
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
It turns out that the existing call sites of the resolveCandidates
method pass only *either* a slice of queries or a slice of upgrades
(never both), and the behaviors triggered by the two parameters don't
overlap much at all. To clarify the two different operations, split
them into two separate methods.
For #36460
Change-Id: I64651637734fd44fea68740a3cdfbacfb73c19b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/289697
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
On my Surface Pro X running the insider preview,
running "netsh help" from Powershell started from the task bar works.
But running "powershell" at a cmd.exe prompt and then running
"netsh help" produces missing DLL errors.
These aren't our fault, so just skip the netsh-based tests if this happens.
Change-Id: I13a17e01143d823d3b5242d827db056bd253e3e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/293849
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
macOS tests have been disabled since CL 12429045 (Aug 2013).
At the time, macOS required a kernel patch to get a working profiler
(https://research.swtch.com/macpprof), which we didn't want
to require, of course.
macOS has improved - it no longer requires the kernel patch - but
we never updated the list of exceptions.
As far as I can tell, the builders have no problem passing the pprof test now.
(It is possible that the iOS builders have trouble, but that is now a different GOOS.)
Remove the exception for macOS. The test should now pass.
Fixes#6047.
Change-Id: Iab49036cacc1025e56f515bd19d084390c2f5357
Reviewed-on: https://go-review.googlesource.com/c/go/+/292229
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The Surface Pro X's 386 simulator is not completely faithful to a real 387.
The most egregious problem is that it computes Log2(8) as 2.9999999999999996,
but it has some other subtler problems as well. All the problems occur in
routines that we don't even bother with assembly for on amd64.
If the speed of Go code is OK on amd64 it should be OK on 386 too.
Just remove all the 386-only assembly functions.
This leaves Ceil, Floor, Trunc, Hypot, and Sqrt in 386 assembly,
all of which are also in assembly on amd64 and all of which pass
their tests on Surface Pro X.
Compared to amd64, the 386 port omits assembly for Min, Max, and Log.
It never had Min and Max, and this CL deletes Log because Log2 wasn't
even correct. (None of the other architectures have assembly Log either.)
Change-Id: I5eb6c61084467035269d4098a36001447b7a0601
Reviewed-on: https://go-review.googlesource.com/c/go/+/291229
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The assembly is mostly a straightforward conversion of the
equivalent arm assembly.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: I61b15d712ade4d3a7285c7680de8e0987aacba10
Reviewed-on: https://go-review.googlesource.com/c/go/+/288828
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This CL adds a few small files - defs, os, and rt0 - to start
on windows/arm64 support for the runtime.
It also copies sys_windows_arm.s to sys_windows_arm64.s,
with the addition of "#ifdef NOT_PORTED" around the entire file.
This is meant to make future CLs easier to review, since the
general pattern is to translate the 32-bit ARM assembly into
64-bit ARM assembly.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: I922037eb3890e77bac48281ecaa8e489595675be
Reviewed-on: https://go-review.googlesource.com/c/go/+/288827
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
types_windows_arm64.go is a copy of types_windows_amd64.go.
All that matters for these types seems to be that they are 64-bit vs 32-bit.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: Ia7788d6e88e5db899371c75dc7dea7d912a689ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/288825
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
We used to clear GOPATH in all the build scripts.
Clearing GOPATH is misleading at best, since you just end up
with the default GOPATH (%USERPROFILE%\go on Windows).
Unless that's your GOROOT, in which case you end up with a
fatal error from the go command (#43938).
run.bash changed to setting GOPATH=/dev/null, which has no
clear analogue on Windows.
run.rc still clears GOPATH.
Change them all to set GOPATH to a non-existent directory
/nonexist-gopath or c:\nonexist-gopath.
Change-Id: I51edd66d37ff6a891b0d0541d91ecba97fbbb03d
Reviewed-on: https://go-review.googlesource.com/c/go/+/288818
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
This matches the prints that deadcode prints later
as the algorithm progresses under -v=2.
It helps to see the initial conditions with -v=2 as well.
Change-Id: I06ae86fe9bd8314d003148f3d941832c9b10aef1
Reviewed-on: https://go-review.googlesource.com/c/go/+/288817
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
A bunch of places are a bit too picky about the architecture.
Simplify them.
Also use a large PEBASE for 64-bit systems.
This more closely matches what is usually used on Windows x86-64
and is required for Windows arm64.
Unfortunately, we still need a special case for x86-64 because
of some cgo relocations. This may be fixable separately.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I65212d28ad4d8c40e2b70dc29f7fce072babecb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/288816
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The files being deleted contain no code.
They exist because back when we used Makefiles
that listed all the Go sources to be compiled, we wrote
patterns like syscall_$GOOS_$GOARCH.go,
and it was easier to create dummy empty files
than introduce conditionals to not look for that
file on Windows.
Now that we have the go command instead,
we don't need those dummy files.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: Ie0066d1dd2bf09802c74c6a496276e8c593e4bc2
Reviewed-on: https://go-review.googlesource.com/c/go/+/288815
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Frame pointers were already enabled on linux, darwin, ios,
but not freebsd, android, openbsd, netbsd.
But the space was reserved on all platforms, leading to
two different arm64 framepointer conditions in different
parts of the code, one of which had no name
(framepointer_enabled || GOARCH == "arm64",
which might have been "framepointer_space_reserved").
So on the disabled systems, the stack layouts were still
set up for frame pointers and the only difference was not
actually maintaining the FP register in the generated code.
Reduce complexity by just enabling the frame pointer
completely on all the arm64 systems.
This commit passes on freebsd, android, netbsd.
I have not been able to try it on openbsd.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I83bd23369d24b76db4c6a648fa74f6917819a093
Reviewed-on: https://go-review.googlesource.com/c/go/+/288814
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Document the various hard-coded architecture checks
or remove them in favor of more general checks.
This should be a no-op now but will make the arm64 port
have fewer diffs.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: Ifd6b19e44e8c9ca4a0d2590f314928ce235821b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/288813
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Externalthreadhandler was not handling its own stack correctly.
It incorrectly referred to the saved LR slot (uninitialized, it turned out)
as holding the return value from the called function.
Externalthreadhandler is used to call two different functions:
profileloop1 and ctrlhandler1.
Profileloop1 does not return, so no harm done.
Ctrlhandler1 returns a boolean indicating whether the handler
took care of the control event (if true, no other handlers run).
It's hard to say exactly what uninitialized values are likely to
have been returned instead of ctrlhandler1's result, but it
probably wasn't helping matters.
Change-Id: Ia02f1c033df618cb82c2193b3a8241ed048a8b18
Reviewed-on: https://go-review.googlesource.com/c/go/+/288812
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
This code has clearly never run successfully,
since one of the “tail calls" calls the wrong function,
and both of them appear in functions with stack frames
that are never going to be properly unwound.
Probably there is no windows/arm under WINE at all.
But might as well fix the code.
Change-Id: I5fa62274b3661bc6bce098657b5bcf11d59655eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/288811
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
The isAbort check was wrong for non-x86 systems.
That was causing the exception chain to be passed back to Windows.
That was causing some other kind of fault - not sure what.
That was leading back to lastcontinuehandler to print a larger
stack trace, and then the throwing = 1 print added runtime.abort,
which made TestAbort pass even though it wasn't really working.
Recognize abort properly and handle it as Go, not as something
for Windows to try to handle.
Keep the throwing = 1 print, because more detail on throw is
always better.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: If614f4ab2884bd90410d29e28311bf969ceeac09
Reviewed-on: https://go-review.googlesource.com/c/go/+/288810
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
If traceback fails, it prints a helpful hex dump of the stack.
But the hex numbers have no 0x prefix, which might make it
a little unclear that they are hex.
We only print two per line, so there is plenty of room for the 0x.
Print it, which lets us delete a custom hex formatter.
Also, in the translated <name+off> hints, print off in hex
(with a 0x prefix). The offsets were previously decimal, which
could have been confused for hex since none of the hex had
0x prefixes. And decimal is kind of useless anyway since the
offsets shown in the main traceback are hex, so you can't
easily match them up without mental base conversions.
Just print hex everywhere, clearly marked by 0x.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I72d26a4e41ada38b620bf8fe3576d787a2e59b47
Reviewed-on: https://go-review.googlesource.com/c/go/+/288809
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The constant was wrong, and the “right” constant doesn't work either.
But with the actually-right constant (and possibly earlier fixes in this
stack as well), profiling now works.
Change-Id: If8caff1da556826db40961fb9bcfe2b1f31ea9f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/288808
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Also give up on the fiction that these files can be regenerated.
They contain many manual edits, and they're fairly small anyway.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: Ib4e4e20a43d8beb1d5390fd184160c33607641f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/288807
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The architecture-specific interpretation of m->tls[0]
is unnecessary and fragile. Delete it.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I927345e52fa2f1741d4914478a29d1fb8acb0dc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/288806
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This was added in 2018 to fix a runtime crash during unwind
during a unhandled-panic-induced crash.
(See https://golang.org/cl/90895 and #23576.)
Clearly we cannot unwind past this function, and the change
did stop the unwind. But it's not a top-of-stack function, and
the real issue is that SP is changed.
The new SPWRITE bit takes care of this instead, so we can drop
it from the topofstack function.
At this point the topofstack function is only checking the
TOPFRAME bit, so we can inline that into the one call site.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I856552298032770e48e06c95a20823a1dbd5e38c
Reviewed-on: https://go-review.googlesource.com/c/go/+/288805
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
I added morestack to this list in 2013 with an explanation
that they were needed if we “start a garbage collection on g0
during a stack split or unsplit”.
(https://golang.org/cl/11533043)
This explanation no longer applies for a handful of reasons,
most importantly that if we did stop a stack scan in the middle
of a call to morestack, we'd ignore pointers above the split,
which would lead to memory corruption. But we don't scan
goroutine stacks during morestack now, so that can't happen.
If we did see morestack during a GC, that would be a good time
to crash the program.
The real problem with morestack is during profiling, as noted
in the code review conversation during 2013. And in profiling
we just need to know to stop and not unwind further, which
the new SPWRITE bit will do for us.
So remove from topofstack and let the program crash if GC
sees morestack and otherwise let the SPWRITE stop morestack
unwinding during profiling.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I06d95920b18c599c7c46f64c21028104978215d7
Reviewed-on: https://go-review.googlesource.com/c/go/+/288804
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
I added mcall to this list in 2013 without explaining why.
(https://codereview.appspot.com/11085043/diff/61001/src/pkg/runtime/traceback_x86.c)
I suspect I was stopping crashes during profiling where the unwind
tried to walk up past mcall and got confused.
mcall is not something you can unwind past, because it switches
stacks, but it's also not something you should expect as a
standard top-of-stack frame. So if you do see it during say
a garbage collection stack walk, it would be important to crash
instead of silently stopping the walk prematurely.
This CL removes it from the topofstack list to avoid the silent stop.
Now that mcall is detected as SPWRITE, that will stop the
unwind (with a crash if encountered during GC, which we want).
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I666487ce24efd72292f2bc3eac7fe0477e16bddd
Reviewed-on: https://go-review.googlesource.com/c/go/+/288803
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
No change to actual runtime, but helps reduce the laundry list
of functions.
mcall, morestack, and asmcgocall are not actually top-of-frame,
so those need more attention in follow-up CLs.
mstart moved to assembly so that it can be marked TOPFRAME.
Since TOPFRAME also tells DWARF consumers not to unwind
this way, this change should also improve debuggers a
marginal amount.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: If1e0d46ca973de5e46b62948d076f675f285b5d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/288802
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The old code was very clever about predicting whether a traceback was safe.
That cleverness has not aged well. In particular, the setsSP function is missing
a bunch of functions that write to SP and will confuse traceback.
And one such function - jmpdefer - was handled as a special case in
gentraceback instead of simply listing it in setsSP.
Throw away all the clever prediction about whether traceback will crash.
Instead, make traceback NOT crash, by checking whether the function
being walked writes to SP.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I3d55fe257a22745e4919ac4dc9a9378c984ba0da
Reviewed-on: https://go-review.googlesource.com/c/go/+/288801
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The runtime traceback code has its own definition of which functions
mark the top frame of a stack, separate from the TOPFRAME bits that
exist in the assembly and are passed along in DWARF information.
It's error-prone and redundant to have two different sources of truth.
This CL provides the actual TOPFRAME bits to the runtime, so that
the runtime can use those bits instead of reinventing its own category.
This CL also adds a new bit, SPWRITE, which marks functions that
write directly to SP (anything but adding and subtracting constants).
Such functions must stop a traceback, because the traceback has no
way to rederive the SP on entry. Again, the runtime has its own definition
which is mostly correct, but also missing some functions. During ordinary
goroutine context switches, such functions do not appear on the stack,
so the incompleteness in the runtime usually doesn't matter.
But profiling signals can arrive at any moment, and the runtime may
crash during traceback if it attempts to unwind an SP-writing frame
and gets out-of-sync with the actual stack. The runtime contains code
to try to detect likely candidates but again it is incomplete.
Deriving the SPWRITE bit automatically from the actual assembly code
provides the complete truth, and passing it to the runtime lets the
runtime use it.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I227f53b23ac5b3dabfcc5e8ee3f00df4e113cf58
Reviewed-on: https://go-review.googlesource.com/c/go/+/288800
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
A g's sched.g is set in newproc1:
newg.sched.g = guintptr(unsafe.Pointer(newg))
After that, it never changes. Yet lots of assembly code does
"g.sched.g = g" unnecessarily. Remove all those lines to avoid
confusion about whether it ever changes.
Also, split gogo into two functions, one that does the nil g check
and a second that does the actual switch. This way, if the nil g check
fails, we get a stack trace showing the call stack that led to the failure.
(The SP write would otherwise cause the stack trace to abort.)
Also restore the proper nil g check in a handful of assembly functions.
(There is little point in checking for nil g *after* installing it as the real g.)
Change-Id: I22866b093f901f765de1d074e36eeec10366abfb
Reviewed-on: https://go-review.googlesource.com/c/go/+/292109
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Both asmcgocall and systemstack need to save the calling Go code's
context for use by traceback, but they do it differently.
Systemstack's appraoch is better, because it doesn't require a
special case in traceback.
So make them both use that.
While we are here, the fake mstart caller in systemstack is
no longer needed and can be removed.
(traceback knows to stop in systemstack because of the writes to SP.)
Also remove the fake mstarts in sys_windows_*.s.
And while we are there, fix the control flow guard code in sys_windows_arm.s.
The current code is using pointers to a stack frame that technically is gone
once we hit the RET instruction. Clearly it's working OK, but better not to depend
on data below SP being preserved, even for just a few instructions.
Store the value we need in other registers instead.
(This code is only used for pushing a sigpanic call, which does not
actually return to the site of the fault and therefore doesn't need to
preserve any of the registers.)
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: Id1e3ef5e54f7ad786e4b87043f2626eba7c3bbd9
Reviewed-on: https://go-review.googlesource.com/c/go/+/288799
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Large enum sets should be sorted by name when the
values don't matter, as they don't here. Do that.
Also replace the large switch with a map lookup.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: Ibe727b5d8866bf4c40c96020e1f4632bde7efd59
Reviewed-on: https://go-review.googlesource.com/c/go/+/288798
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This can happen on Windows when recording profile samples for system threads.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I5a7ba32b1900a69f3b7acada9cb6cf8396d8a03f
Reviewed-on: https://go-review.googlesource.com/c/go/+/288797
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The default GOROOT has nothing to do with system details.
Move it next to its one use in package runtime.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I1a601fad6335336b4616b834bb21bd8437ee1313
Reviewed-on: https://go-review.googlesource.com/c/go/+/288796
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Document what the values in internal/sys mean.
Remove various special cases for arm64 in the code using StackAlign.
Delete Uintreg - it was for GOARCH=amd64p32,
which was specific to GOOS=nacl and has been retired.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I40e8fa07b4e192298b6536b98a72a751951a4383
Reviewed-on: https://go-review.googlesource.com/c/go/+/288795
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is dead code and need not be ported to each architecture.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I2d0072b377f73e49d7158ea304670c26f5486c59
Reviewed-on: https://go-review.googlesource.com/c/go/+/288794
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
During a cgocallback, the runtime calls needm to get an m.
The calls made during needm cannot themselves assume that
there is an m or a g (which is attached to the m).
In the old days of making direct system calls, the only thing
you had to do for such functions was mark them //go:nosplit,
to avoid the use of g in the stack split prologue.
But now, on operating systems that make system calls through
shared libraries and use code that saves state in the g or m
before doing so, it's not safe to assume g exists. In fact, it is
not even safe to call getg(), because it might fault deferencing
the TLS storage to find the g pointer (that storage may not be
initialized yet, at least on Windows, and perhaps on other systems
in the future).
The specific routines that are problematic are usleep and osyield,
which are called during lock contention in lockextra, called
from needm.
All this is rather subtle and hidden, so in addition to fixing the
problem on Windows, this CL makes the fact of not running on
a g much clearer by introducing variants usleep_no_g and
osyield_no_g whose names should make clear that there is no g.
And then we can remove the various sketchy getg() == nil checks
in the existing routines.
As part of this cleanup, this CL also deletes onosstack on Windows.
onosstack is from back when the runtime was implemented in C.
It predates systemstack but does essentially the same thing.
Instead of having two different copies of this code, we can use
systemstack consistently. This way we need not port onosstack
to each architecture.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: I3352de1fd0a3c26267c6e209063e6e86abd26187
Reviewed-on: https://go-review.googlesource.com/c/go/+/288793
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
We print things like “exit status 3221225477”
but the standard Windows form is 0xc0000005.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
This CL is, however, not windows/arm64-specific.
It is cleanup meant to make the port (and future ports) easier.
Change-Id: Iefe447d4d1781b53bef9619f68d386f2866b2934
Reviewed-on: https://go-review.googlesource.com/c/go/+/288792
Trust: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A type may now have a type param in it, either because it has been
composed from a function type param, or it has been declared as or
derived from a reference to a generic type. No objects or types with
type params can be exported yet. No generic type has a runtime
descriptor (but will likely eventually be associated with a dictionary).
types.Type now has an RParam field, which for a Named type can specify
the type params (in order) that must be supplied to fully instantiate
the type. Also, there is a new flag HasTParam to indicate if there is
a type param (TTYPEPARAM) anywhere in the type.
An instantiated generic type (whether fully instantiated or
re-instantiated to new type params) is a defined type, even though there
was no explicit declaration. This allows us to handle recursive
instantiated types (and improves printing of types).
To avoid the need to transform later in the compiler, an instantiation
of a method of a generic type is immediately represented as a function
with the method as the first argument.
Added 5 tests on generic types to test/typeparams, including list.go,
which tests recursive generic types.
Change-Id: Ib7ff27abd369a06d1c8ea84edc6ca1fd74bbb7c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/292652
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Merge List:
+ 2021-02-18 eb982727e3 cmd/go/internal/mvs: fix Downgrade to match Algorithm 4
+ 2021-02-18 3b7277d365 cmd/go: add a script test for artifacts resulting from 'go get -u'
+ 2021-02-18 f3c2208e2c cmd/go: add script tests for potential upgrades due to downgrades
+ 2021-02-18 a5c8a15f64 cmd/go/internal/mvs: clarify and annotate test cases
+ 2021-02-18 a76efea1fe cmd/go/internal/mvs: don't emit duplicates from Req
+ 2021-02-18 609d82b289 cmd/dist: set GOARM=7 for windows/arm
+ 2021-02-18 f0be3cc547 runtime: unbreak linux/riscv64 following regabi merge
+ 2021-02-18 07ef313525 runtime/cgo: add cast in C code to avoid C compiler warning
Change-Id: I8e58ad1e82a9ea313a99c1b11df5b341f80680d4
mvs.Downgrade is pretty clearly intended to match Algorithm 4 from the
MVS blog post (https://research.swtch.com/vgo-mvs#algorithm_4).
Per the blog post:
“Downgrading one module may require downgrading other modules, but we
want to downgrade as few other modules as possible. … To avoid an
unnecessary downgrade to E 1.1, we must also add a new requirement on
E 1.2. We can apply Algorithm R to find the minimal set of new
requirements to write to go.mod.”
mvs.Downgrade does not match that behavior today: it fails to retain
the selected versions of transitive dependencies that are not implied
by downgraded direct dependencies of the target (module E in the
post). This bug is currently masked by the fact that we only call
Downgrade today with a *modload.mvsReqs, for which the Required method
happens to return the complete build list — rather than only the
direct dependencies as documented for the mvs.Reqs interface.
For #36460
Change-Id: If9c8f413b156b5f67c02787d9359394e169951b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/287633
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The changes between (equivalent, and reviewed) go/types/typestring_test.go
and typestring_test.go can be seen by comparing patchset 1 and 2. The actual
change is just removing the "// UNREVIEWED" marker.
Change-Id: I66150c0ab738763d2d8b94483ef8314cbe28a374
Reviewed-on: https://go-review.googlesource.com/c/go/+/293473
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/typestring.go
and typestring.go can be seen by comparing patchset 1 and 3. The actual
change is just removing the "// UNREVIEWED" marker plus an adjustment
to writeTParamList (we now always write type constraints).
Change-Id: Ieb109c17756addc954e1ca0da606fa5b335ff30d
Reviewed-on: https://go-review.googlesource.com/c/go/+/293472
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/type.go
and type.go can be seen by comparing patchset 1 and 3. The actual
change is just removing the "// UNREVIEWED" marker and some
comment adjustments.
Change-Id: Ied0e2f942bc96a9fcae0466761cfaa60a87668db
Reviewed-on: https://go-review.googlesource.com/c/go/+/293471
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This removes the need for the aType embedded type and brings the types2.Type
API in sync with the go/types.Type API.
For reasons not fully understood yet, introducing the new under function
causes a very long initialization cycle error, which doesn't exist in
go/types. For now, circumvent the problem through a helper function variable.
This CL also eliminates superflous (former) Under() method calls
inside optype calls (optype takes care of this).
Plus some minor misc. cleanups and comment adjustments.
Change-Id: I86e13ccf6f0b34d7496240ace61a1c84856b6033
Reviewed-on: https://go-review.googlesource.com/c/go/+/293470
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
This removes two more converter methods in favor of functions.
This further reduces the API surface of types2.Type and matches
the approach taken in go/types.
Change-Id: I3cdd54c5e0d1e7664a69f3697fc081a66315b969
Reviewed-on: https://go-review.googlesource.com/c/go/+/293292
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This change replaces methods with functions to reduce the API surface of
types2.Type and to match the approach taken in go/types. The converter
methods for Named and TypeParam will be addressed in a follow-up CL.
Also: Fixed behavior of optype to return the underlying type for
arguments that are not type parameters.
Change-Id: Ia369c796754bc33bbaf0c9c8478badecb729279b
Reviewed-on: https://go-review.googlesource.com/c/go/+/293291
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Modify go/parser to consistently represent type instantiation as an
ast.IndexExpr, rather than use an ast.CallExpr (with Brackets:true) for
instantiations with multiple type parameters. To enable this, introduce
a new ast expr type: ListExpr.
This brings go/types in line with types2, with the exception of a small
change to funcInst to eliminate redundant errors if values are
erroneously used as types. In a subsequent CL, call.go and expr.go will
be marked as reviewed.
This also catches some type instance syntax using '()' that was
previously accepted incorrectly. Tests are updated accordingly.
Change-Id: I30cd0181c7608f1be7486a9a8b63df993b412e85
Reviewed-on: https://go-review.googlesource.com/c/go/+/293010
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>
Req is supposed to return “a minimal requirement list”
that includes each of the module paths listed in base.
Currently, if base contains duplicates Req emits duplicates,
and a list containing duplicates is certainly not minimal.
That, in turn, requires callers to be careful to deduplicate the base
slice, and there are multiple callers that are already quite
complicated to reason about even without the added complication of
deduplicating slices.
For #36460
Change-Id: I391a1dc0641fe1dd424c16b7a1082da0d00c7292
Reviewed-on: https://go-review.googlesource.com/c/go/+/287632
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
GOARM=6 executables fail to launch on windows/arm, so set this to ARMv7
like we do for Android.
This CL is part of a stack adding windows/arm64
support (#36439), intended to land in the Go 1.17 cycle.
Change-Id: Ifa13685e7ab6edd367f3dfec10296e376319dbd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/291629
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is a port of CL 290471 to go/types. However, this change preserves
the existing check for constant types in recordTypeAndValue, which uses
is(..., isConstType) rather than the isConstType predicate. In types2,
this code path is not hit with type parameters because convertUntyped
walks the type list in order before calling updateExprType with the type
parameter, at which point the expression type would have already been
recorded as the first element of the type list -- probably something
that should be corrected.
Longer term, I believe we actually could allow const type parameters if
the optype is a sum of constant types.
Change-Id: Iaa91ffa740b5f08a5696bd96918a866bffd7aef6
Reviewed-on: https://go-review.googlesource.com/c/go/+/291323
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>
Unbreak the linux/riscv64 port by storing the zero value register to memory,
rather than the current code that is moving a zero intermediate to the stack
pointer register (ideally this should be caught by the assembler). This was
broken in CL#272568.
On riscv64 a zero immediate value cannot be moved directly to memory, rather
a register needs to be loaded with zero and then stored. Alternatively, the
the zero value register (aka X0) can be used directly.
Change-Id: Id57121541d50c9993cec5c2270b638b184ab9bc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/292894
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This was a mostly clean merge, with the exception of codereview.cfg and
changes in src/go/types.
codereview.cfg for dev.typeparams is preserved in this CL. It should be
deleted before merging back to master.
The go/types changes were merged manually. For the most part this
involved taking the union of patches, with the following exceptions:
+ declInfo.aliasPos is removed, as it is not necessary in
dev.typeparams where we have access to the full TypeSpec.
+ Checker.overflow is updated to use the asBasic converter.
+ A TODO is added to errorcodes.go to ensure that go1.16 error codes
are preserved.
Change-Id: If9595196852e2163e27a9478df1e7b2c3704947d
Disable -G=3 tests on the std go tests, in order to see if -G=3 is
causing the flakiness for the dev.typeparams builder, as opposed to
other changes in typeparams branch. It's possible that -G=3 is using
more CPU/RAM that causes flakiness, as opposed to more specific bugs.
Change-Id: I610bce2aabd26b2b1fddc5e63f85ffe4e958e0d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/292850
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
This CL merges the dev.regabi branch to the master branch.
In the dev.regabi branch we have refactored the compiler, and laid
some preliminary work for enabling a register-based ABI (issue #40724),
including improved late call/return lowering, improved ABI wrapper
generation, reflect call prepared for the new ABI, and reserving
special registers in the internal ABI. The actual register-based ABI
has not been enabled for the moment. The ABI-related changes are behind
GOEXPERIMENT=regabi and currently off by default.
Updates #40724, #44222.
Fixes#44224.
Change-Id: Id5de9f734d14099267ab717167aaaeef31fdba70
Currently, we call Warnl in SSA backend when we see a function
(defined or called) with regparams pragma. Calling Warnl in
concurrent environment is racy. As the debugging output is
temporary, for testing purposes we just pass -c=1. We'll remove
the pragma and the debugging print some time soon.
Change-Id: I6f925a665b953259453fc458490c5ff91f67c91a
Reviewed-on: https://go-review.googlesource.com/c/go/+/291710
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
This is a port of CL 289570 to go/types. It has some notable differences
with that CL:
+ A new _BadDecl error code is added, to indicate declarations with bad
syntax.
+ declInfo is updated hold not an 'alias' bool, but an aliasPos
token.Pos to identify the location of the type aliasing '=' token.
This allows for error messages to be accurately placed on the '='
For #31793
Change-Id: Ib15969f9cd5be30228b7a4c6406f978d6fc58018
Reviewed-on: https://go-review.googlesource.com/c/go/+/291318
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>
Currently these two functions assume that constants in internal/abi are
set correctly, but we actually just made them zero if
GOEXPERIMENT_REGABI is set. This means reflectcall is broken. Fix it by
stubbing out these routines even if GOEXPERIMENT_REGABI is set.
Change-Id: I4c8df6d6af28562c5bb7b85f48c03d37daa9ee0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/292650
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
This change sets the register count constants to zero for the
GOEXPERIMENT regabi because currently the users of it (i.e. reflect)
will be broken, since they expect Go functions that implement the new
ABI.
Change-Id: Id3e874c61821a36605eb4e1cccdee36a2759f303
Reviewed-on: https://go-review.googlesource.com/c/go/+/292649
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Currently, in the trampoline generation pass we expect packages
are laid out in dependency order, so a cross-package jump always
has a known target address so we can check if a trampoline is
needed. With linknames, there can be cycles in the package
dependency graph, making this algorithm no longer work. For them,
as the target address is unkown we conservatively generate a
trampoline. This may generate unnecessary trampolines (if the
packages turn out laid together), but package cycles are extremely
rare so this is fine.
Updates #44073.
Change-Id: I2dc2998edacbda27d726fc79452313a21d07787a
Reviewed-on: https://go-review.googlesource.com/c/go/+/292490
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
The package documentation referenced sample metadata that was removed in CL 282632. Update this documentation to be less specific
about what metadata is available.
Additionally, the documentation on the Sample type referred to Descriptions instead of All as the source of metrics names.
Fixes#44280.
Change-Id: I24fc63a744bf498cb4cd5bda56c1599f6dd75929
Reviewed-on: https://go-review.googlesource.com/c/go/+/292309
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This change adds support for the new register ABI on amd64 to
reflect.(Value).Call. If internal/abi's register counts are non-zero,
reflect will try to set up arguments in registers on the Call path.
Note that because the register ABI becomes ABI0 with zero registers
available, this should keep working as it did before.
This change does not add any tests for the register ABI case because
there's no way to do so at the moment.
For #40724.
Change-Id: I8aa089a5aa5a31b72e56b3d9388dd3f82203985b
Reviewed-on: https://go-review.googlesource.com/c/go/+/272568
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
In net/http package, the ServeContent/ServeFile doesn't check the I/O
timeout error from chunkWriter or *net.TCPConn, which means that both
HTTP status and headers might be missing when WriteTimeout happens. If
the poll.SendFile() doesn't check the *poll.FD state before sending
data, the client will only receive the response body with status and
report "malformed http response/status code".
This patch is to enable netpollcheckerr before sendfile, which should
align with normal *poll.FD.Write() and Splice().
Fixes#43822
Change-Id: I32517e3f261bab883a58b577b813ef189214b954
Reviewed-on: https://go-review.googlesource.com/c/go/+/285914
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
They have moved to x/website in CL 291693.
The docs that are left are the ones that are edited at the same time
as development in this repository and are tied to the specific version
of Go being developed. Those are:
- the language spec
- the memory model
- the assembler manual
- the current release's release notes
Change-Id: I437c4d33ada1b1716b1919c3c939c2cacf407e83
Reviewed-on: https://go-review.googlesource.com/c/go/+/291711
Trust: Russ Cox <rsc@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
On current Linux kernels copy_file_range does not correctly handle
files in certain special file systems, such as /proc. For those file
systems it fails to copy any data and returns zero. This breaks Go's
io.Copy for those files.
Fix the problem by assuming that if copy_file_range returns 0 the
first time it is called on a file, that that file is not supported.
In that case fall back to just using read. This will force an extra
system call when using io.Copy to copy a zero-sized normal file,
but at least it will work correctly.
For #36817Fixes#44272
Change-Id: I02e81872cb70fda0ce5485e2ea712f219132e614
Reviewed-on: https://go-review.googlesource.com/c/go/+/291989
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
For the command
go vet -?
the output was,
usage: go vet [-n] [-x] [-vettool prog] [build flags] [vet flags] [packages]
Run 'go help vet' for details.
Run 'go tool vet -help' for the vet tool's flags.
but "go help vet" is perfunctory at best. (That's another issue I'm
working on—see https://go-review.googlesource.com/c/tools/+/291909—
but vendoring is required to sort that out.) Add another line and rewrite
a bit to make it actually helpful:
usage: go vet [-n] [-x] [-vettool prog] [build flags] [vet flags] [packages]
Run 'go help vet' for details.
Run 'go tool vet help' for a full list of flags and analyzers.
Run 'go tool vet -help' for an overview.
Change-Id: I9d8580f0573321a57d55875ac3185988ce3eaf64
Reviewed-on: https://go-review.googlesource.com/c/go/+/291929
Trust: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is a port of CL 289509 to go/types. It differs from that CL in
codes added to errors, to fit the new factoring of check_test.go, and to
allow go/types to import regexp in deps_test.go
For #31793
Change-Id: Ia9e4c7f5aac1493001189184227c2ebc79a76e77
Reviewed-on: https://go-review.googlesource.com/c/go/+/291317
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 is a port of CL 289049 to go/types. In that CL, tests were written
using the ability of tests/run.go to generate test packages dynamically.
For this CL, similar functionality is added to the go/types errmap
tests: tests are refactored to decouple the loading of source code from
the filesystem, so that tests for long constants may be generated
dynamically rather than checked-in as a large testdata file.
Change-Id: I92c7cb61a8d42c6593570ef7ae0af86b501fa34e
Reviewed-on: https://go-review.googlesource.com/c/go/+/290949
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>
The changes between (equivalent, and reviewed) go/types/resolver_test.go
and resolver_test.go can be seen by comparing patchset 1 and 2. The actual
change is just removing the "// UNREVIEWED" marker.
Change-Id: Ibd5850f0d68e393d81e55651bffc886d71665545
Reviewed-on: https://go-review.googlesource.com/c/go/+/291180
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/errors_test.go
and errors_test.go can be seen by comparing patchset 1 and 2. The actual
change is just removing the "// UNREVIEWED" marker.
Change-Id: I74de039b9e655445f0407a0203ac52a95c6c8a40
Reviewed-on: https://go-review.googlesource.com/c/go/+/291179
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/universe.go
and universe.go can be seen by comparing patchset 1 and 2. The actual
change is just removing the "// UNREVIEWED" marker.
Change-Id: I217a4ace016129e661b4a43821c6b306812850b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/291178
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/sizes_test.go
and sizes_test.go can be seen by comparing patchset 1 and 2. The actual
change is just removing the "// UNREVIEWED" marker.
Change-Id: I36a9a8a9e0e5a869af392a6d04b50c166c8dbedf
Reviewed-on: https://go-review.googlesource.com/c/go/+/291177
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/sizes.go
and sizes.go can be seen by comparing patchset 1 and 2. The actual
change is just removing the "// UNREVIEWED" marker.
Change-Id: Iacdcffe56023ec53bfaaac8fb112f813a7de0a95
Reviewed-on: https://go-review.googlesource.com/c/go/+/291176
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
The changes between (equivalent, and reviewed) go/types/return.go
and return.go can be seen by comparing patchset 1 and 2. The actual
change is just removing the "// UNREVIEWED" marker.
Change-Id: I7bb3201abec75043804296d6c37307fd243d58f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/291175
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/object_test.go
and object_test.go can be seen by comparing patchset 1 and 2. The actual
change is just removing the "// UNREVIEWED" marker.
Change-Id: I0ebc564fb8edf42c901bf3bf3bae242760aa7c0c
Reviewed-on: https://go-review.googlesource.com/c/go/+/291174
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/object.go
and object.go can be seen by comparing patchset 1 and 2. The actual
change is just removing the "// UNREVIEWED" marker.
Change-Id: I0fcc08c19c94a60f642036697ccd12f0667d22cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/291173
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/labels.go
and labels.go can be seen by comparing patchset 1 and 2. The actual
change is just removing the "// UNREVIEWED" marker.
Change-Id: I8f1a9927beadff7ac851681739902c13300b6c39
Reviewed-on: https://go-review.googlesource.com/c/go/+/291172
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/infer.go
and infer.go can be seen by comparing patchset 1 and 2. The actual
change is just removing the "// UNREVIEWED" marker and fixing a
few comments.
Change-Id: Ieb0c07c325a2e446550f85b159f99d4dfe5f1d5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/291171
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
The changes between (equivalent, and reviewed) go/types/builtin_test.go
and builtin_test.go can be seen by comparing patchset 1 and 2. The actual
change is just removing the "// UNREVIEWED" marker.
Change-Id: Ic40d1a9b2f1465c5335bd69e9a0b265ab694c3ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/291170
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/builtin.go
and builtin.go can be seen by comparing patchset 1 and 2. The actual
change is just removing the "// UNREVIEWED" marker.
Change-Id: Ibecf2b5bc982f6bf92310267b9f06b588b7148a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/291169
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Conflicts:
- src/cmd/compile/internal/gc/walk.go
gc/walk.go is changed in CL 290950 on the master branch but
deleted in the dev.regabi branch and moved over to the walk
package. This CL includes porting CL 290950 over to the new
walk.
Merge List:
+ 2021-02-12 ff0e93ea31 doc/go1.16: note that package path elements beginning with '.' are disallowed
+ 2021-02-11 249da7ec02 CONTRIBUTORS: update for the Go 1.16 release
+ 2021-02-11 864d4f1c6b cmd/go: multiple small 'go help' fixes
+ 2021-02-11 26ceae85a8 spec: More precise wording in section on function calls.
+ 2021-02-11 930c2c9a68 cmd/go: reject embedded files that can't be packed into modules
+ 2021-02-11 e5b08e6d5c io/fs: allow backslash in ValidPath, reject in os.DirFS.Open
+ 2021-02-10 ed8079096f cmd/compile: mark concrete call of reflect.(*rtype).Method as REFLECTMETHOD
+ 2021-02-09 e9c9683597 cmd/go: suppress errors from 'go get -d' for packages that only conditionally exist
+ 2021-02-09 e0ac989cf3 archive/tar: detect out of bounds accesses in PAX records resulting from padded lengths
+ 2021-02-09 c9d6f45fec runtime/metrics: fix a couple of documentation typpos
+ 2021-02-09 cea4e21b52 io/fs: backslash is always a glob meta character
+ 2021-02-08 dc725bfb3c doc/go1.16: mention new vet check for asn1.Unmarshal
Change-Id: Ib28fffa7dfbff7f6cdbfaf4a304757fead7bbf19
- Create the stencil name using targ.Type.String(), which handles cases
where, for example, a type argument is a pointer to a named type,
etc. *obj.
- Set name.Def properly for a new stenciled func (have the symbol point
back to the associated function node). Will be required when exporting.
- Add missing copying of Func field when making copies of Name nodes.
(On purpose (it seems), Name nodes don't have a copy() function, so
we have to copy all the needed fields explicitly.)
- Deal with nil type in subster.node(), which is the type of the return
value for a function that doesn't return anything.
- Fix min to match standard want/go form, and add in float tests. Changed
Got -> got in bunch of other typeparam tests.
- Add new tests index.go, settable.go, and smallest.go (similar to
examples in the type param proposal), some of which need the above
changes.
Change-Id: I09a72302bc1fd3635a326da92405222afa222e85
Reviewed-on: https://go-review.googlesource.com/c/go/+/291109
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This update was created using the updatecontrib command:
go get golang.org/x/build/cmd/updatecontrib
cd gotip
updatecontrib
With manual changes based on publicly available information
to canonicalize letter case and formatting for a few names.
For #12042.
Change-Id: I030b77e8ebcc7fe02106f0f264acdfb0b56e20d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/291189
Trust: Carlos Amedee <carlos@golang.org>
Run-TryBot: Carlos Amedee <carlos@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
* Link to privacy policies for proxy.golang.org and sum.golang.org in
'go help modules'. It's important that both policies are linked from
the go command's documentation.
* Fix wording and typo in 'go help vcs' following comments in CL 290992,
which adds reference documentation for GOVCS.
* Fix whitespace on GOVCS in 'go help environment'.
For #41730
Change-Id: I86abceacd4962b748361244026f219157c9285e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/291230
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
If the file won't be packed into a module,
don't put those files into embeds.
Otherwise people will be surprised when things work
locally but not when imported by another module.
Observed on CL 290709
Change-Id: Ia0ef7d0e0f5e42473c2b774e57c843e68a365bc7
Reviewed-on: https://go-review.googlesource.com/c/go/+/290809
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Rejecting backslash introduces problems with presenting
underlying OS file systems that contain names with backslash.
Rejecting backslash also does not Windows-proof the syntax,
because colon can also be a path separator. And we are not
going to reject colon from all names. So don't reject backslash
either.
There is a similar problem on Windows with names containing
slashes, but those are more difficult (though not impossible)
to create.
Also document and enforce that paths must be UTF-8.
Fixes#44166.
Change-Id: Iac7a9a268025c1fd31010dbaf3f51e1660c7ae2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/290709
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
For functions that call reflect.Type.Method (or MethodByName), we
mark it as REFLECTMETHOD, which tells the linker that methods
can be retrieved via reflection and the linker keeps all exported
methods live. Currently, this marking expects exactly the
interface call reflect.Type.Method (or MethodByName). But now the
compiler can devirtualize that call to a concrete call
reflect.(*rtype).Method (or MethodByName), which is not handled
and causing the linker to discard methods too aggressively.
Handle the latter in this CL.
Fixes#44207.
Change-Id: Ia4060472dbff6ab6a83d2ca8e60a3e3f180ee832
Reviewed-on: https://go-review.googlesource.com/c/go/+/290950
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Add respective check to type checker.
Enables another excluded test in test/run.go.
This CL completes the currently required checks for
language compatibility in types2.
Updates #31793.
Change-Id: Icececff9e6023d38f600c93bcb54cdcafcf501b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/290911
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
If ABI wrappers are enabled, we should not see ABI aliases at
link time. Stop resolving them. One exception is shared linkage,
where we still use ABI aliases as we don't always know the ABI
for symbols from shared libraries.
Change-Id: Ia89a788094382adeb4c4ef9b0312aa6e8c2f79ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/290032
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
- Have to delay the extra transformation on methods invoked on a type
param, since the actual transformation (including path through
embedded fields) will depend on the instantiated type. I am currently
doing the transformation during the stencil substitution phase. We
probably should have a separate pass after noder2 and stenciling,
which drives the extra transformations that were in the old
typechecker.
- We handle method values (that are not called) and method calls. We
don't currently handle method expressions.
- Handle type substitution in function types, which is needed for
function args in generic functions.
- Added stringer.go and map.go tests, testing the above changes
(including constraints with embedded interfaces).
Change-Id: I3831a937d2b8814150f75bebf9f23ab10b93fa00
Reviewed-on: https://go-review.googlesource.com/c/go/+/290550
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
This is a port of CL 288633 to go/types. It differs from that CL
in the implementation of opName, which now uses ast Exprs.
Additionally, a couple tests had to be updated:
+ TestEvalArith is updated to not overflow.
+ stmt0.src is updated to have an error positioned on the '<<'
operator.
Change-Id: I628357c33a1e7b0bb5bb7de5736f1fb10ce404e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/290630
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 is a port of CL 287832 for go/types. It differs from that CL in its
handling of position data. Unlike the syntax package, which has a
unified Operation node, go/types checks operations for ast.UnaryExpr,
IncDecStmt, and BinaryExpr. It was simpler to keep the existing position
logic. Notably, this correctly puts the errors on the operator.
Change-Id: Id1e3aefe863da225eb0a9b3628cfc8a5684c0c4f
Reviewed-on: https://go-review.googlesource.com/c/go/+/290569
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
This is a port of CL 287494 to go/types. The additional checks in
test/fixedbugs are included, though they won't be executed by go/types.
Support for errorcheckdir checks will be added to go/types in a later
CL.
Change-Id: I37e202ea5daf7d7b8fc6ae93a4c4dbd11762480f
Reviewed-on: https://go-review.googlesource.com/c/go/+/290570
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Handles the case in which padding of a PAX record's length field
violates invariants about the formatting of record, whereby it no
longer matches the prescribed format:
"%d %s=%s\n", <length>, <keyword>, <value>
as per:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_03
0-padding, and paddings of other sorts weren't handled and we assumed
that only non-padded decimal lengths would be passed in.
Added test cases to ensure that the parsing still proceeds as expected.
The prior crashing repro:
0000000000000000000000000000000030 mtime=1432668921.098285006\n30 ctime=2147483649.15163319
exposed the fallacy in the code, that assumed that the length would ALWAYS be a
non-padded decimal length string.
This bug has existed since Go1.1 as per CL 6700047.
Thanks to Josh Bleecher Snyder for fuzzing this package, and thanks to Tom
Thorogood for advocacy, raising parity with GNU Tar, but for providing more test cases.
Fixes#40196
Change-Id: I32e0af4887bc9221481bd9e8a5120a79f177f08c
Reviewed-on: https://go-review.googlesource.com/c/go/+/289629
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Joe Tsai <thebrokentoaster@gmail.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Joe Tsai <thebrokentoaster@gmail.com>
This involved a couple non-trivial fixes in go/types:
- move the check for main function signature to resolver.go, to be
consistent with init. Also, update uses of _InvalidInitSig to
_InvalidInitDecl, consistent with what we decided for dev.regabi.
- Update some tests in api_test.go which newly fail after CL 289715
(fixing reporting of untyped nil) In all cases but one, these updates
were consistent with types2. However, in one case types2 seems to be
able to resolve more type information than go/types for a broken
package. I left a TODO to investigate this further.
Change-Id: I8244b7c81654194edd5af8de689a13c262117dff
- Handle generic function calling itself or another generic function in
stenciling. This is easy - after it is created, just scan an
instantiated generic function for function instantiations (that may
needed to be stenciled), just like non-generic functions. The types
in the function instantiation will already have been set by the
stenciling.
- Handle OTYPE nodes in subster.node() (allows for generic type
conversions).
- Eliminated some duplicated work in subster.typ().
- Added new test case fact.go that tests a generic function calling
itself, and simple generic type conversions.
- Cause an error if a generic function is to be exported (which we
don't handle yet).
- Fixed some suggested changes in the add.go test case that I missed in
the last review.
Change-Id: I5d61704254c27962f358d5a3d2e0c62a5099f148
Reviewed-on: https://go-review.googlesource.com/c/go/+/290469
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Now that we have a g register, just use it.
Note: functions that can be called from ABI0 context (e.g.
morestack) is unchanged. Functions that switch g is also
unchanged, because we need to set the new g in both the register
and TLS.
TODO: other OSes.
Change-Id: I692a82a7caa8417ff620a59676a6275f56747b94
Reviewed-on: https://go-review.googlesource.com/c/go/+/289718
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This is a proof-of-concept change for using the g register on
AMD64. getg is now lowered to R14 in the new ABI. The g register
is not yet used in all places where it can be used (e.g. stack
bounds check, runtime assembly code).
Change-Id: I10123ddf38e31782cf58bafcdff170aee0ff0d1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/289196
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
medianBucket can return if the total is greater than thresh.
However, if a histogram has no counts, total and thresh
will both be zero and cause panic.
Adding an equal sign to prevent the potential panic.
Fixes#44148
Change-Id: Ifb8a781990f490d142ae7c035b4e01d6a07ae04d
Reviewed-on: https://go-review.googlesource.com/c/go/+/290171
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Change Plan 9 fork/exec to use the O_CLOEXEC file
descriptor, instead of relying on spooky at a
distance.
Historically, Plan 9 has set the O_CLOEXEC flag on
the underlying channels in the kernel, rather
than the file descriptors -- if two fds pointed
at a single channel, as with dup, changing the
flags on one of them would be observable on the
other.
The per-Chan semantics are ok, if unexpected,
when a chan is only handled within a single
process, but this isn't always the case.
Forked processes share Chans, but even more of
a problem is the interaction between /srv and
OCEXEC, which can lead to unexectedly closed
file descriptors in completely unrelated
proceses. For example:
func exists() bool {
// If some other thread execs here,
// we don't want to leak the fd, so
// open it O_CLOEXEC
fd := Open("/srv/foo", O_CLOEXEC)
if fd != -1 {
Close(fd)
return true
}
return false
}
would close the connection to any file descriptor
(maybe even for the root fs) in ALL other processes
that have it open if an exec were to happen(!),
which is quite undesriable.
As a result, 9front will be changing this behavior
for the next release.
Go is the only code observed so far that relies on
this behavior on purpose, and It's easy to make the
code work with both semantics: simply using the file
descriptor that was opened with O_CEXEC instead of
throwing it away.
So we do that here.
Fixes#43524
Change-Id: I4887f5c934a5e63e5e6c1bb59878a325abc928d3
GitHub-Last-Rev: 96bb21bd1e
GitHub-Pull-Request: golang/go#43533
Reviewed-on: https://go-review.googlesource.com/c/go/+/281833
Reviewed-by: David du Colombier <0intro@gmail.com>
Reviewed-by: Richard Miller <millerresearch@gmail.com>
Reviewed-by: Jacob Moody <j4kem00dy@gmail.com>
Run-TryBot: David du Colombier <0intro@gmail.com>
Trust: Ian Lance Taylor <iant@golang.org>
In shared build mode and linkage, currently we assume all
function symbols are ABI0 (except for generated type algorithm
functions), and alias them to ABIInternal. When the two ABIs
actually differ (as it is now), this is not actually correct.
This CL resolves symbol ABI based on their mangled names.
If the symbol's name has a ".abi0" or ".abiinternal" suffix, it
is of the corresponding ABI. The symbol without the suffix is
the other ABI. For functions without ABI wrapper generated,
only one ABI exists but we don't know what it is, so we still
use alias (for now).
Change-Id: I2165f149bc83d513e81eb1eb4ee95464335b0e75
Reviewed-on: https://go-review.googlesource.com/c/go/+/289289
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
racecall can be called in ABIInternal context (e.g. raceread
calling racecalladdr calling racecall) without wrapper. racecall
calls C code, which doesn't preserve our special registers. Set
them explicitly in racecall upon returning from C.
Change-Id: Ic990479c1fca6bb8a3b151325c7a89be8331a530
Reviewed-on: https://go-review.googlesource.com/c/go/+/289709
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
racecallbackthunk is called from C, and it needs to follow C ABI.
The assembly code preserves C callee-save registers. It must not
be called via wrappers, which may not preserve those registers.
Change-Id: Icd72c399f4424d73c4882860d85057fe2671f6aa
Reviewed-on: https://go-review.googlesource.com/c/go/+/289194
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Allow full compilation and running of simple programs with generic
functions by stenciling on the fly the needed generic functions. Deal
with some simple derived types based on type params.
Include a few new typeparam tests min.go and add.go which involve
fully compiling and running simple generic code.
Change-Id: Ifc2a64ecacdbd860faaeee800e2ef49ffef9df5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/289630
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Currently, when using cgo, the g pointer is set via a separate
call to setg_gcc or with inline assembly in threadentry. This CL
changes it to call setg_gcc in crosscall_amd64, like other g-
register platforms. When we have an actual g register on AMD64,
we'll need to set the register immediately before calling into
Go.
Change-Id: Ib1171e05cd0dabba3b7d12e072084d141051cf3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/289192
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Add the Config.Lang field which may be set to a Go version string,
such as "go1.12". This is a string rather than explicit semantic
version numbers (such as {1, 12}) for API robustness; a string
is more flexible should we need more or different information.
Add -lang flag to types2 package for use with (manual) testing
when running "go test -run Check$ -lang=... -files=...".
While changing flags, look for comma-separated (rather than space-
separated) files when providing the -file flag.
Check that numeric constant literals, signed shift counts are
accepted according to the selected language version.
Type alias declarations and overlapping embedded interfaces are
not yet checked.
Updates #31793.
Change-Id: I9ff238ed38a88f377eb2267dc3e8816b89a40635
Reviewed-on: https://go-review.googlesource.com/c/go/+/289509
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This matches the compiler's existing limitations and thus ensures
that types2 reports the same errors for oversize integer constants.
Change-Id: I4fb7c83f3af69098d96f7b6c53dbe3eaf6ea9ee4
Reviewed-on: https://go-review.googlesource.com/c/go/+/288633
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This is a port of CL 279424, which didn't make it into master in time
for go1.16. Move it to dev.regabi so that it may be merged.
Notably, this port no longer removes the _InvalidInitSig error code,
instead opting to deprecate it. Now that error codes are 'locked in' for
go1.16, even if their API may not yet be exposed, we should follow the
practice of not changing their values. In the future, code generation
can make it easier to keep error code values constant.
For #43308
Change-Id: I5260b93fd063393d38d6458e45a67e7f9b7426ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/289714
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>
Symbol's Attributes and ABI are in the same word. In the
concurrent backend, we may read one symbol's ABI (the callee)
while setting its attributes in another goroutine.
Fix racecompile build.
Change-Id: I500e869bafdd72080119ab243db94eee3afcf926
Reviewed-on: https://go-review.googlesource.com/c/go/+/289290
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
This is a port of CL 274615, adapted to go/types. The only change was in
the positioning of expected errors in vardecl.src: in go/types they are
positioned on the identifier.
Change-Id: Iab03265a7c4287749373e4380c6db6a95f262f30
Reviewed-on: https://go-review.googlesource.com/c/go/+/289712
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>
In ABIInternal, reserve X15 as constant zero, and use it to zero
memory. (Maybe there can be more use of it?)
The register is zeroed when transition to ABIInternal from ABI0.
Caveat: using X15 generates longer instructions than using X0.
Maybe we want to use X0?
Change-Id: I12d5ee92a01fc0b59dad4e5ab023ac71bc2a8b7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/288093
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Mark the syscall wrappers as ABIInternal, as they have addresses
taken from Go code, and it is important to call to them without
wrappers.
Previously, the wrapper is just a single JMP instruction, which
makes it not matter. In the next CL we'll make the wrapper
actually have a frame. The real wrappers will mess up things
such as stack alignment for C ABI.
This doesn't look really nice, but I don't know how we can do
better...
TODO: other OSes.
Change-Id: Ifb3920494990a7775e3e6902fbcaf137df3cc653
Reviewed-on: https://go-review.googlesource.com/c/go/+/288092
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
The compiler uses 512 bit of precision for untyped constant
arithmetic but didn't restrict the length of incoming constant
literals in any way, possibly opening the door for excessively
long constants that could bring compilation to a crawl.
Add a simple check that refuses excessively long constants.
Add test.
Change-Id: I797cb2a8e677b8da2864eb92d686d271ab8a004d
Reviewed-on: https://go-review.googlesource.com/c/go/+/289049
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
There appears to be a typo in the description of
the recursive division algorithm.
Two things seem suspicious with the original comment:
1. It is talking about choosing s, but s doesn't
appear anywhere in the equation.
2. The math in the equation is incorrect.
Where
B = len(v)/2
s = B - 1
Proof that it is incorrect:
len(v) - B >= B + 1
len(v) - len(v)/2 >= len(v)/2 + 1
This doesn't hold if len(v) is even, e.g. 10:
10 - 10/2 >= 10/2 + 1
10 - 5 >= 5 + 1
5 >= 6 // this is false
The new equation will be the following,
which will be mathematically correct:
len(v) - s >= B + 1
len(v) - (len(v)/2 - 1) >= len(v)/2 + 1
len(v) - len(v)/2 + 1 >= len(v)/2 + 1
len(v) - len(v)/2 >= len(v)/2
This holds if len(v) is even or odd.
e.g. 10
10 - 10/2 >= 10/2
10 - 5 >= 5
5 >= 5
e.g. 11
11 - 11/2 >= 11/2
11 - 5 >= 5
6 >= 5
Change-Id: If77ce09286cf7038637b5dfd0fb7d4f828023f56
Reviewed-on: https://go-review.googlesource.com/c/go/+/287372
Run-TryBot: Katie Hockman <katie@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Trust: Katie Hockman <katie@golang.org>
The compiler chooses the literal value export format by type
not by constant.Kind. That is, a floating-point constant is
always exported as a (big) float value, not a (big) rational
value, even though the internal representation may be that
of a rational number. (This is a possibility now that the
compiler also uses the go/constant package.)
Naturally, during import, a floating-point value is read as
a float and represented as a (big) float in go/constant.
The types2 importer (based on the go/types importer) read
the floating-point number elements (mantissa, exponent) but
then constructed the float go/constant value through a series
of elementary operations, typically leading to a rational,
but sometimes even an integer number (e.g. for math.MaxFloat64).
There is no problem with that (the value is the same) but if
we want to impose bitsize limits on overlarge integer values
we quickly run into trouble with large floats represented as
integers.
This change matches the code importing float literals with
the code used by the compiler.
Note: At some point we may want to relax the import/export code
for constant values and export them by representation rather than
by type. As is, we lose accuracy since all floating-point point
values, even the ones internally represented as rational numbers
end up being exported as floating-point numbers.
Change-Id: Ic751b2046a0fd047f751da3d35cbef0a1b5fea3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/288632
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Expresses things more clearly, especially in cases like 'f := min[int]'
where we create a xsgeneric function instantiation, but don't immediately
call it.
min[int](2, 3) now looks like:
. CALLFUNC tc(1) Use:1 int # min1.go:11 int
. . FUNCINST tc(1) FUNC-func(int, int) int # min1.go:11 FUNC-func(int, int) int
. . . NAME-main.min tc(1) Class:PFUNC Offset:0 Used FUNC-func[T](T, T) T # min1.go:3
. . FUNCINST-Targs
. . . TYPE .int Offset:0 type int
. CALLFUNC-Args
. . LITERAL-2 tc(1) int # min1.go:11
. . LITERAL-3 tc(1) int # min1.go:11
Remove the targs parameter from ir.NewCallExpr(), not needed anymore,
since type arguments are included in the FUNCINST.
Change-Id: I23438b75288330475294d7ace239ba64acfa641e
Reviewed-on: https://go-review.googlesource.com/c/go/+/288951
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Will now run "go tool compile -G=2 -W=2" on a simple generic function
with multiple type parameters and a call to that function with multiple
explicit type arguments.
We will likely move to have a separate function/type instantiation node,
in order distinguish these cases from normal index expressions.
Change-Id: I0a571902d63785cc06240ed4ba0495923403b511
Reviewed-on: https://go-review.googlesource.com/c/go/+/288433
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The example, var v, ok T1 = x.(T), can be interpreted as type T1 interface{} or type T = bool; type T1 = T.
Separating the example would help understanding for readers.
Change-Id: I179f4564e67f4d503815d29307df2cebb50c82f9
GitHub-Last-Rev: b34fffb6bb
GitHub-Pull-Request: golang/go#44040
Reviewed-on: https://go-review.googlesource.com/c/go/+/288472
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Robert Griesemer <gri@golang.org>
In the linker's deadcode pass we decode type symbols for
interface satisfaction analysis. When linking against Go shared
libraries, the type symbol may come from a shared library, so it
doesn't have data in the current module being linked, so we cannot
decode it. We already have code to skip DYNIMPORT symbols. However,
this doesn't actually work, because at that point the type symbols'
names haven't been mangled, whereas they may be mangled in the
shared library. So the symbol definition (in shared library) and
reference (in current module) haven't been connected.
Skip decoding type symbols of type Sxxx (along with DYNIMPORT)
when linkShared.
Note: we cannot skip all type symbols, as we still need to mark
unexported methods defined in the current module.
Fixes#44031.
Change-Id: I833d19a060c94edbd6fc448172358f9a7d760657
Reviewed-on: https://go-review.googlesource.com/c/go/+/288496
Trust: Cherry Zhang <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Will now run "go tool compile -G=2 -W=2" on a simple generic function
with one type parameter and a call to that function with one explicit
type argument. Next change will handle multiple type arguments.
Change-Id: Ia7d17ea2a02bf99bd50e673ac80ae4aad4c48440
Reviewed-on: https://go-review.googlesource.com/c/go/+/288432
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
CL 279423 introduced a regression in this test as it incorrectly laid
out various instructions. In the case of arm, the second instruction
was overwriting the first. In the case of 386, amd64 and s390x, the
instructions were being appended to the end of the slice after 64
zero bytes.
This was causing test failures on "linux/s390x on z13".
Fixes#44028
Change-Id: Id136212dabdae27db7e91904b0df6a3a9d2f4af4
Reviewed-on: https://go-review.googlesource.com/c/go/+/288278
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Also, make some fmt changes so that the type parameters and the
typeparam type are displayed in -W=2.
You can now parse a simple generic function (but not generic calls or generic
types) and print out the noder IR via 'go tool compile -G=2 -W=2 func.go'
Change-Id: I1f070fc4a96174a447763ad37999e61c25905901
Reviewed-on: https://go-review.googlesource.com/c/go/+/287833
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Factor out the existing "constant representation" check after
untyped constant arithmetic and combine with an overflow check.
Use a better heuristic for determining the error position if we
know the error is for a constant operand that is the result of an
arithmetic expression.
Related cleanups.
With this change, untyped constant arithmetic reports an error
when (integer) constants become too large (> 2048 bits). Before,
such arithmetic was only limited by space and time.
Change-Id: Id3cea66c8ba697ff4c7fd1e848f350d9713e3c75
Reviewed-on: https://go-review.googlesource.com/c/go/+/287832
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
memclrNoHeapPointers is the underlying implementation of
typedmemclr and memclrHasPointers, so it still needs to write
pointer-aligned words atomically. Document this requirement.
Updates #41428.
Change-Id: Ice00dee5de7a96a50e51ff019fcef069e8a8406a
Reviewed-on: https://go-review.googlesource.com/c/go/+/287692
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Even though builtin.go is generated, there's no need for
it to be so huge in terms code size. Nor does ultimate
speed matter here.
Added two simple helper functions that are not inlined,
which reduce the amount of code generated for this file
from 77881 bytes to 27641 bytes of assembly (per compiler
-S output) and reduce the compile binary by ~140KiB
(of course that's insignificant given the 22MiB file size).
Change-Id: I3058ec62788b33eaeff2f9d5fe975b8e41cbf172
Reviewed-on: https://go-review.googlesource.com/c/go/+/287772
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
We are focusing on generic functions first, and ignoring type lists for
now.
The signatures of types.NewSignature() and ir.NewCallExpr() changed (with
addition of type args/params).
Change-Id: I57480be3d1f65690b2946e15dd74929bf42873f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/287416
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com>
This call was changed to os.ReadFile in CL 266365, but the test also
builds that source file using gccgo if present, and released versions
of gccgo do not yet support ioutil.ReadFile.
Manually tested with gccgo gccgo 10.2.1 (see #35786).
Fixes#43974.
Updates #42026.
Change-Id: Ic4ca0848d3ca324e2ab10fd14ad867f21e0898e3
Reviewed-on: https://go-review.googlesource.com/c/go/+/287613
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The syscall10/syscall10X implementation uses an incorrect stack offset for
arguments a7 to a10. Correct this so that the syscall arguments work as
intended.
Updates #36435Fixes#43927
Change-Id: Ia7ae6cc8c89f50acfd951c0f271f3b3309934499
Reviewed-on: https://go-review.googlesource.com/c/go/+/287252
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When people want deterministic/single-process builds, they probably
assume that GOMAXPROCS=1 will do that. It currently does not,
neither for build parallelism nor for compiler internal parallelism.
(Current incantation for that is "go build -p=1 -gcflags=all=-c=1 ... ")
This CL makes
"GOMAXPROCS=1 go build ..."
behave like
"go build -p=1 -gcflags=all=-c=1 ... "
RELNOTE=yes
Change-Id: I9cfe50b7deee7334d2f1057b58385f6c98547b9f
Reviewed-on: https://go-review.googlesource.com/c/go/+/284695
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
We add entries to the defer list at panic/goexit time on-the-fly for
frames with open-coded defers. We do this so that we can correctly
process open-coded defers and non-open-coded defers in the correct order
during panics/goexits. But we need to remove entries for open-coded
defers from the defer list when there is a recover, since those entries
may never get removed otherwise and will get stale, since their
corresponding defers may now be processed normally (inline).
This bug here is that we were only removing higher-up stale entries
during a recover if all defers in the current frame were done. But we
could have more defers in the current frame (as the new test case
shows). In this case, we need to leave the current defer entry around
for use by deferreturn, but still remove any stale entries further along
the chain.
For bug 43921, simple change that we should abort the removal loop for
any defer entry that is started (i.e. in process by a still
not-recovered outer panic), even if it is not an open-coded defer.
This change does not fix bug 43920, which looks to be a more complex fix.
Fixes#43882Fixes#43921
Change-Id: Ie05b2fa26973aa26b25c8899a2abc916090ee4f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/286712
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
1) Rather than map-iterate through all file scopes and collect unused
packages, collect all imports in the Checker.imports list so that
errors are reported in source order.
2) From cmd/compile, borrow the idea of a "dotImportRefs" map to map
dot-imported objects to the package they were dot-imported through
(we call the map "dotImportMap").
3) From cmd/compile, borrow the "pkgnotused" function
(called Checker.errorUnusedPkg in this code) and clean up
unused package error reporting.
4) Adjust unused package error message to match compiler message exactly.
5) Enable one more excluded test case in test/run.go.
Change-Id: I4e4e55512a6043a7fd54f576c7441e3dd4077d6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/287072
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
With CGO disabled, the test suite tries to run the following and fail:
CGO_ENABLED=0 go test -run=TestScript/link_syso_issue33139 cmd/go
go test proxy running at GOPROXY=http://127.0.0.1:38829/mod
--- FAIL: TestScript (0.01s)
--- FAIL: TestScript/link_syso_issue33139 (0.01s)
script_test.go:215:
# Test that we can use the external linker with a host syso file that is
# embedded in a package, that is referenced by a Go assembly function.
# See issue 33139. (0.000s)
# External linking is not supported on linux/ppc64.
# See: https://github.com/golang/go/issues/8912 (0.000s)
# External linking is not supported on linux/riscv64.
# See: https://github.com/golang/go/issues/36739 (0.001s)
> [linux] [riscv64] skip
> cc -c -o syso/objTestImpl.syso syso/src/objTestImpl.c
FAIL: testdata/script/link_syso_issue33139.txt:15:
unexpected error starting command:
fork/exec /dev/null: permission denied
CC was set to /dev/null (during build) in the scenario mentioned above
This patch replaces [!exec:cc] with [!cgo] because we care about the
availability of the 'cc' builtin and not the 'cc' executable in $PATH
Change-Id: Ifbd2441f5f8e903ca3da213aba76f44c2e2eebab
GitHub-Last-Rev: 3b743787d0
GitHub-Pull-Request: golang/go#43912
Reviewed-on: https://go-review.googlesource.com/c/go/+/286633
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The mkasm_darwin.go file was renamed to mkasm.go in CL 270380, with OpenBSD
support being added. The mkasm_openbsd.go file should not have been merged,
so remove it. Fix up references to mkasm_$GOOS.go and provide $GOOS as an
argument on invocation.
Updates #36435
Change-Id: I868d3f2146973d026e6a663d437749dbb6b312ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/286812
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The recent refactoring of SelectorExpr code to helpers broke the
handling of MethodExprs when there is an embedded field involved (e.g.
test/method7.go, line 48). If there is an embedded field involved, the
node op seen in DotMethod() is an ODOT rather than an OTYPE. Also, the
receiver type of the result should be the original type, but the new
code was using the last type after following the embedding path.
Change-Id: I13f7ea6448b03d3e8f974103ee3a027219ca8388
Reviewed-on: https://go-review.googlesource.com/c/go/+/286176
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
go/constant represents a Float constant either as a rational number
(if numerator and denominator are small enough), or, as a "catch-all",
as a arbitrary-precision floating-point number.
This CL cleans up some of these transitions by factoring out more
of the decision logic and documents the rationale between the state
transitions better.
This CL also simplifies some unrelated code that was overly complex.
Updates #43908.
Change-Id: Iccdd2d6b7fb7ed13d68ed5e6d992d1bc56a065bb
Reviewed-on: https://go-review.googlesource.com/c/go/+/286572
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently, types2 sometimes produces constant.Values with a Kind
different than the untyped constant type's Is{Integer,Float,Complex}
info, which irgen expects to always match.
While we mull how best to proceed in #43891, this CL adapts irgen to
types2's current behavior. In particular, fixedbugs/issue11945.go now
passes with -G=3.
Updates #43891.
Change-Id: I24823a32ff49af6045a032d3903dbb55cbec6bef
Reviewed-on: https://go-review.googlesource.com/c/go/+/286652
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
NewFile requires the file descriptor to be either closed
through the returned File instance, or to stay valid at least
until the finalizer runs during garbage collection.
These requirements are easily violated when file descriptors
are closed via unix.Close, or when the *File returned by
NewFile is garbage collected while the underlying file descriptor is
still in use.
This commit adds further documentation for NewFile and Fd, making it
explicit that using naked file descriptors is subject to constraints
due to garbage collection of File objects.
Fixes#43863
Change-Id: I49ea1f0054eb2d2a72b616450c8e83476f4d07fb
GitHub-Last-Rev: 180d0130ae
GitHub-Pull-Request: golang/go#43867
Reviewed-on: https://go-review.googlesource.com/c/go/+/286032
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
This merge involved two merge conflicts:
1. walk's ascompatee code has been substantially refactored on
dev.regabi, so CL 285633 is ported to the new style.
2. The os.TestDirFS workaround added in CL 286213 can be removed now
that #42637 has been fixed by CL 285720.
Conflicts:
- src/cmd/compile/internal/gc/walk.go
- src/os/os_test.go
Merge List:
+ 2021-01-25 bf0f7c9d78 doc/go1.16: mention os.DirFS in os section
+ 2021-01-25 deaf29a8a8 cmd/compile: fix order-of-assignment issue w/ defers
+ 2021-01-25 ad2ca26a52 doc/go1.16: mention os.DirEntry and types moved from os to io/fs
+ 2021-01-25 a51921fa5b doc/go1.16: mention new testing/iotest functions
+ 2021-01-25 e6b6d107f7 doc/go1.16: mention deprecation of io/ioutil
+ 2021-01-25 96a276363b doc/go1.16: mention go/build changes
+ 2021-01-25 3d85c69a0b html/template: revert "avoid race when escaping updates template"
+ 2021-01-25 54514c6b28 cmd/go: fix TestScript/cgo_path, cgo_path_space when CC set
+ 2021-01-25 6de8443f3b doc/asm: add a section on go_asm.h, clean up go_tls.h section
+ 2021-01-25 54b251f542 lib/time, time/tzdata: update tzdata to 2021a
+ 2021-01-25 ff82cc971a os: force consistent mtime before running fstest on directory on Windows
+ 2021-01-25 044f937a73 doc/go1.16: fix WalkDir and Walk links
+ 2021-01-23 b634f5d97a doc/go1.16: add crypto/x509 memory optimization
+ 2021-01-23 9897655c61 doc/go1.16: reword ambiguously parsable sentence
+ 2021-01-23 cd99385ff4 cmd/internal/obj/arm64: fix VMOVQ instruction encoding error
+ 2021-01-23 66ee8b158f runtime: restore cgo_import_dynamic for libc.so on openbsd
+ 2021-01-22 25c39e4fb5 io/ioutil: fix example test for WriteFile to allow it to run in the playground
+ 2021-01-22 eb21b31e48 runtime: define dummy msanmove
+ 2021-01-22 3a778ff50f runtime: check for g0 stack last in signal handler
+ 2021-01-22 a2cef9b544 cmd/go: don't lookup the path for CC when invoking cgo
Change-Id: I651949f9eb18b57e3c996c4f3b2b3bf458bc5d97
The race reported in issue #41167 was detected only because the
ReadWriter used in test code happened to be a bytes.Buffer whose
Read and Write operate (unsafely) on shared state. This is not the
case in any realistic scenario where the FastCGI protocol is spoken
over sockets or pairs of pipes.
Since tests that use nopWriteCloser don't care about any output
generate by child.Serve(), we change nopWriteCloser to provide
a dummy Write method.
Remove the locking added in CL 252417, since it causes a deadlock
during write as reported in #43901. The race in tests no longer
happens thanks to the aforementioned change to nopWriteCloser.
Fixes#43901.
Updates #41167.
Change-Id: I8cf31088a71253c34056698f8e2ad0bee9fcf6c6
GitHub-Last-Rev: b06d8377fd
GitHub-Pull-Request: golang/go#43027
Reviewed-on: https://go-review.googlesource.com/c/go/+/275692
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
CL 261677 fixed a logic issue in walk's alias detection, where it was
checking the RHS expression instead of the LHS expression when trying
to determine the kind of assignment. However, correcting this exposed
a latent issue with assigning to result parameters in functions with
defers, where an assignment could become visible earlier than intended
if a later expression could panic.
Fixes#43835.
Change-Id: I061ced125e3896e26d65f45b28c99db2c8a74a8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/285633
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Floating-point constants are represented as rational numbers when
possible (i.e., when numerators and denominators are not too large).
If we convert to floats when not necessary, we risk losing precision.
This is the minimal fix for the specific issue, but it's too aggressive:
If the numbers are too large, we still want to convert to floats.
Will address in a separate CL that also does a few related cleanups.
Fixes#43908.
Change-Id: Id575e34fa18361a347c43701cfb4dd7221997f66
Reviewed-on: https://go-review.googlesource.com/c/go/+/286552
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This reverts CLs 274450 and 279492, except for the new tests.
The new race test is changed to skip, as it now fails.
We can try again for 1.17.
Original CL descriptions:
html/template: attach functions to namespace
The text/template functions are stored in a data structure shared by
all related templates, so do the same with the original, unwrapped,
functions on the html/template side.
html/template: avoid race when escaping updates template
For #39807Fixes#43855
Change-Id: I2ce91321ada06ea496a982aefe170eb5af9ba847
Reviewed-on: https://go-review.googlesource.com/c/go/+/285957
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
This adds a document specifying the internal ABI (specifically the
calling convention). This document lives in the Go tree (rather than
the proposal repository) because the intent is for it to track the
reality in the compiler.
Updates #40724.
Change-Id: I583190080cd7d8cb1084f616fd1384d0f1f25725
Reviewed-on: https://go-review.googlesource.com/c/go/+/285292
Trust: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Currently the only mention of go_asm.h is buried in a confusing
section about the runtime-specific go_tls.h header. We actually want
people to use go_asm.h, so this CL adds a section with a proper
discussion of this header. As part of this, we remove the discussion
of go_asm.h from the go_tls.h section and clean up what remains.
I stumbled on this when working on the internal ABI specification. I
wanted to refer to stable documentation on how to access struct fields
from assembly and found there was none.
Change-Id: I0d53741e7685e65794611939e76285f7c82e1d65
Reviewed-on: https://go-review.googlesource.com/c/go/+/286052
Trust: Austin Clements <austin@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
This allows more precision and matches types2's behavior.
For backwards compatibility with gcimporter, for now we still need to
write out declared constants as limited-precision floating-point
values. To ensure consistent behavior of constant arithmetic whether
it spans package boundaries or not, we include the full-precision
rational representation in the compiler's extension section of the
export data.
Also, this CL simply uses the math/big.Rat.String text representation
as the encoding. This is inefficient, but because it's only in the
compiler's extension section, we can easily revisit this in the
future.
Declaring exported untyped float and complex constants isn't very
common anyway. Within the standard library, only package math declares
any at all, containing just 15. And those 15 are only imported a total
of 12 times elsewhere in the standard library.
Change-Id: I85ea23ab712e93fd3b68e52d60cbedce9be696a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/286215
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This test is causing nearly every trybot run on dev.regabi and
dev.typeparams to fail. It's already a release blocker for Go 1.16, so
the failures on the development branches is entirely noise; and
because it causes the trybots to short-circuit, it risks masking
actual Windows-specific failures.
This CL disables the test until a proper solution is decided upon and
implemented for Go 1.16.
Updates #42637.
Change-Id: Ibc85edaed591f1c125cf0b210867aa89d2b0a4b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/286213
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
The race detector on ppc64le corrupts command-line arguments lists if
they contain an empty string, and cmd/go often generates compiler
argument lists containing `-D ""`. Since this is equivalent to not
specifying the `-D` flag at all, just do that. This allows using a
race-detector-enabled cmd/compile on ppc64le.
Updates #43883.
Change-Id: Ifac5cd9a44932129438b9b0b3ecc6101ad3716b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/286173
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
FindFileNext sometimes returns a different mtime than looking at the
file directly, because the MFT on NTFS is written to lazily. In order to
keep these in sync, we use GetFileInformationByHandle to get the actual
mtime, and then write it back to the file explicitly.
Fixes#42637.
Change-Id: I774016d3ac55d0dc9b0f9c1b681516c33ba0d28a
Reviewed-on: https://go-review.googlesource.com/c/go/+/285720
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Eager re-sync-branch to keep Git history reasonably accurate, since
Git lacks a better way of encoding partial merges like CL 286172.
Conflicts:
- src/cmd/compile/internal/inline/inl.go
- src/cmd/compile/internal/noder/import.go
- src/cmd/compile/internal/noder/noder.go
Merge List:
+ 2021-01-25 063c72f06d [dev.regabi] cmd/compile: backport changes from dev.typeparams (9456804)
+ 2021-01-23 d05d6fab32 [dev.regabi] cmd/compile: replace ir.Name map with ir.NameSet for SSA 2
+ 2021-01-23 48badc5fa8 [dev.regabi] cmd/compile: fix escape analysis problem with closures
+ 2021-01-23 51e1819a8d [dev.regabi] cmd/compile: scan body of closure in tooHairy to check for disallowed nodes
Change-Id: I48c0435f7aaf56f4aec26518a7459e9d95a51e9c
This CL backports a bunch of changes that landed on dev.typeparams,
but are not dependent on types2 or generics. By backporting, we reduce
the divergence between development branches, hopefully improving test
coverage and reducing risk of merge conflicts.
Updates #43866.
Change-Id: I382510855c9b5fac52b17066e44a00bd07fe86f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/286172
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
The VMOVQ instruction moves a 128-bit constant into a V register, as 128-bit
constant can't be loaded into a register directly, we split it into two 64-bit
constants and load it from constant pool. Currently we add the 128-bit constant
to literal pool by calling the 'addpool' function twice, this is not the right
way because it doesn't guarantee the two DWORD instructions are consecutive,
and the second call of addpool will overwrite the p.Pool field,resulting in a
wrong PC-relative offset value of the Prog.
This CL renames the flag LFROM3 to LFROM128, and adds a new function addpool128
to add a 128-bit constant to the literal pool.
Change-Id: I616f043c99a9a18a663f8768842cc980de2e6f79
Reviewed-on: https://go-review.googlesource.com/c/go/+/282334
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: eric fang <eric.fang@arm.com>
Trust: eric fang <eric.fang@arm.com>
This was removed in change 285692, however we need to explicitly pull libc.so
in when libpthread.so is being used. The current code works on openbsd/amd64
since we pull libc.so in via runtime/sys_openbsd2.go, however openbsd/arm64
does not do this currently.
Change-Id: Ibe93d936a22e69e2fe12620f6d27ccca7a91dba5
Reviewed-on: https://go-review.googlesource.com/c/go/+/285912
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
In reflect.methodWrapper, we call escape analysis without including the
full batch of dependent functions, including the closure functions.
Because of this, we haven't created locations for the params/local
variables of a closure when we are processing a function that
inlines that closure. (Whereas in the normal compilation of the
function, we do call with the full batch.) To deal with this, I am
creating locations for the params/local variables of a closure when
needed.
Without this fix, the new test closure6.go would fail.
Updates #43818
Change-Id: I5f91cfb6f35efe2937ef88cbcc468e403e0da9ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/285677
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Note: This invalidates the implementation of MethodSet further (it
also has not been updated to accomodate for type parameters). But
types2 doesn't make use of it. We should remove it.
Change-Id: Ia2601bdd59b3f3ee0b72bc2512153c42bf5053b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/285994
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
As with CL 285875, this required resolving some conflicts around
handling of //go:embed directives. Still further work is needed to
reject uses of //go:embed in files that don't import "embed", so this
is left as a TODO. (When this code was written for dev.typeparams, we
were still leaning towards not requiring the "embed" import.)
Also, the recent support for inlining closures (CL 283112) interacts
poorly with -G=3 mode. There are some known issues with this code
already (#43818), so for now this CL disables inlining of closures
when in -G=3 mode with a TODO to revisit this once closure inlining is
working fully.
Conflicts:
- src/cmd/compile/internal/noder/noder.go
- src/cmd/compile/internal/typecheck/dcl.go
- src/cmd/compile/internal/typecheck/func.go
- test/run.go
Merge List:
+ 2021-01-22 7e0a81d280 [dev.regabi] all: merge master (dab3e5a) into dev.regabi
+ 2021-01-22 dab3e5affe runtime: switch runtime to libc for openbsd/amd64
+ 2021-01-22 a1b53d85da cmd/go: add documentation for test and xtest fields output by go list
+ 2021-01-22 b268b60774 runtime: remove pthread_kill/pthread_self for openbsd
+ 2021-01-22 ec4051763d runtime: fix typo in mgcscavenge.go
+ 2021-01-22 7ece3a7b17 net/http: fix flaky TestDisableKeepAliveUpgrade
+ 2021-01-22 50cba0506f time: clarify Timer.Reset behavior on AfterFunc Timers
+ 2021-01-22 cf10e69f17 doc/go1.16: mention net/http.Transport.GetProxyConnectHeader
+ 2021-01-22 ec1b945265 doc/go1.16: mention path/filepath.WalkDir
+ 2021-01-22 11def3d40b doc/go1.16: mention syscall.AllThreadsSyscall
+ 2021-01-21 07b0235609 doc/go1.16: add notes about package-specific fs.FS changes
+ 2021-01-21 e2b4f1fea5 doc/go1.16: minor formatting fix
+ 2021-01-21 9f43a9e07b doc/go1.16: mention new debug/elf constants
+ 2021-01-21 3c2f11ba5b cmd/go: overwrite program name with full path
+ 2021-01-21 953d1feca9 all: introduce and use internal/execabs
+ 2021-01-21 b186e4d70d cmd/go: add test case for cgo CC setting
+ 2021-01-21 5a8a2265fb cmd/cgo: report exec errors a bit more clearly
+ 2021-01-21 46e2e2e9d9 cmd/go: pass resolved CC, GCCGO to cgo
+ 2021-01-21 3d40895e36 runtime: switch openbsd/arm64 to pthreads
+ 2021-01-21 d95ca91380 crypto/elliptic: fix P-224 field reduction
+ 2021-01-21 d7e71c01ad [dev.regabi] cmd/compile: replace ir.Name map with ir.NameSet for dwarf
+ 2021-01-21 5248f59a22 [dev.regabi] cmd/compile: replace ir.Name map with ir.NameSet for SSA
+ 2021-01-21 970d8b6cb2 [dev.regabi] cmd/compile: replace ir.Name map with ir.NameSet in inlining
+ 2021-01-21 68a4664475 [dev.regabi] cmd/compile: remove tempAssigns in walkCall1
+ 2021-01-21 fd9a391cdd [dev.regabi] cmd/compile: remove CallExpr.Rargs
+ 2021-01-21 19a6db6b63 [dev.regabi] cmd/compile: make sure mkcall* passed non-nil init
+ 2021-01-21 9f036844db [dev.regabi] cmd/compile: use ir.DoChildren directly in inlining
+ 2021-01-21 213c3905e9 [dev.regabi] cmd/compile: use node walked flag to prevent double walk for walkSelect
+ 2021-01-20 1760d736f6 [dev.regabi] cmd/compile: exporting, importing, and inlining functions with OCLOSURE
+ 2021-01-20 ecf4ebf100 cmd/internal/moddeps: check content of all modules in GOROOT
+ 2021-01-20 92cb157cf3 [dev.regabi] cmd/compile: late expansion of return values
+ 2021-01-20 d2d155d1ae runtime: don't adjust timer pp field in timerWaiting status
+ 2021-01-20 803d18fc6c cmd/go: set Incomplete field on go list output if no files match embed
+ 2021-01-20 6e243ce71d cmd/go: have go mod vendor copy embedded files in subdirs
+ 2021-01-20 be28e5abc5 cmd/go: fix mod_get_fallback test
+ 2021-01-20 928bda4f4a runtime: convert openbsd/amd64 locking to libc
+ 2021-01-19 824f2d635c cmd/go: allow go fmt to complete when embedded file is missing
+ 2021-01-19 0575e35e50 cmd/compile: require 'go 1.16' go.mod line for //go:embed
+ 2021-01-19 9423d50d53 [dev.regabi] cmd/compile: use '%q' for printing rune values less than 128
+ 2021-01-19 ccb2e90688 cmd/link: exit before Asmb2 if error
+ 2021-01-19 ca5774a5a5 embed: treat uninitialized FS as empty
+ 2021-01-19 d047c91a6c cmd/link,runtime: switch openbsd/amd64 to pthreads
+ 2021-01-19 61debffd97 runtime: factor out usesLibcall
+ 2021-01-19 9fed39d281 runtime: factor out mStackIsSystemAllocated
+ 2021-01-19 a2f825c542 [dev.regabi] cmd/compile: directly create go.map and go.track symbols
+ 2021-01-19 4a4212c0e5 [dev.regabi] cmd/compile: refactor Linksym creation
+ 2021-01-19 4f5c603c0f [dev.regabi] cmd/compile: cleanup callTargetLSym
+ 2021-01-18 dbab079835 runtime: free Windows event handles after last lock is dropped
+ 2021-01-18 5a8fbb0d2d os: do not close syscall.Stdin in TestReadStdin
+ 2021-01-18 422f38fb6c [dev.regabi] cmd/compile: move stack objects to liveness
+ 2021-01-18 6113db0bb4 [dev.regabi] cmd/compile: convert OPANIC argument to interface{} during typecheck
+ 2021-01-18 4c835f9169 [dev.regabi] cmd/compile: use LinksymOffsetExpr in TypePtr/ItabAddr
+ 2021-01-18 0ffa1ead6e [dev.regabi] cmd/compile: use *obj.LSym instead of *ir.Name for staticdata functions
+ 2021-01-17 7e0fa38aad [dev.regabi] cmd/compile: remove unneeded packages from ir.Pkgs
+ 2021-01-17 99a5db11ac [dev.regabi] cmd/compile: use LinksymOffsetExpr in walkConvInterface
+ 2021-01-17 87845d14f9 [dev.regabi] cmd/compile: add ir.TailCallStmt
+ 2021-01-17 e3027c6828 [dev.regabi] cmd/compile: fix linux-amd64-noopt builder
+ 2021-01-17 59ff93fe64 [dev.regabi] cmd/compile: rename NameOffsetExpr to LinksymOffsetExpr
+ 2021-01-17 82b9cae700 [dev.regabi] cmd/compile: change ir.NameOffsetExpr to use *obj.LSym instead of *Name
+ 2021-01-17 88956fc4b1 [dev.regabi] cmd/compile: stop analyze NameOffsetExpr.Name_ in escape analysis
+ 2021-01-17 7ce2a8383d [dev.regabi] cmd/compile: simplify stack temp initialization
+ 2021-01-17 ba0e8a92fa [dev.regabi] cmd/compile: refactor temp construction in walk
+ 2021-01-17 78e5aabcdb [dev.regabi] cmd/compile: replace Node.HasCall with walk.mayCall
+ 2021-01-16 6de9423445 [dev.regabi] cmd/compile: cleanup OAS2FUNC ordering
+ 2021-01-16 a956a0e909 [dev.regabi] cmd/compile, runtime: fix up comments/error messages from recent renames
+ 2021-01-16 ab3b67abfd [dev.regabi] cmd/compile: remove ONEWOBJ
+ 2021-01-16 c9b1445ac8 [dev.regabi] cmd/compile: remove TypeAssertExpr {Src,Dst}Type fields
+ 2021-01-15 682a1d2176 runtime: detect errors in DuplicateHandle
+ 2021-01-15 9f83418b83 cmd/link: remove GOROOT write in TestBuildForTvOS
+ 2021-01-15 ec9470162f cmd/compile: allow embed into any string or byte slice type
+ 2021-01-15 54198b04db cmd/compile: disallow embed of var inside func
+ 2021-01-15 b386c735e7 cmd/go: fix go generate docs
+ 2021-01-15 bb5075a525 syscall: remove RtlGenRandom and move it into internal/syscall
+ 2021-01-15 1deae0b597 os: invoke processKiller synchronously in testKillProcess
+ 2021-01-15 03a875137f [dev.regabi] cmd/compile: unexport reflectdata.WriteType
+ 2021-01-15 14537e6e54 [dev.regabi] cmd/compile: move stkobj symbol generation to SSA
+ 2021-01-15 ab523fc510 [dev.regabi] cmd/compile: don't promote Byval CaptureVars if Addrtaken
+ 2021-01-15 ff196c3e84 crypto/x509: update iOS bundled roots to version 55188.40.9
+ 2021-01-15 b7a698c73f [dev.regabi] test: disable test on windows because expected contains path separators.
+ 2021-01-15 4be7af23f9 [dev.regabi] cmd/compile: fix ICE during ir.Dump
+ 2021-01-14 e125ccd10e cmd/go: in 'go mod edit', validate versions given to -retract and -exclude
+ 2021-01-14 eb330020dc cmd/dist, cmd/go: pass -arch for C compilation on Darwin
+ 2021-01-14 84e8a06f62 cmd/cgo: remove unnecessary space in cgo export header
+ 2021-01-14 0c86b999c3 cmd/test2json: document passing -test.paniconexit0
+ 2021-01-14 9135795891 cmd/go/internal/load: report positions for embed errors
+ 2021-01-14 35b9c66601 [dev.regabi] cmd/compile,cmd/link: additional code review suggestions for CL 270863
+ 2021-01-14 d9b79e53bb cmd/compile: fix wrong complement for arm64 floating-point comparisons
+ 2021-01-14 c73232d08f cmd/go/internal/load: refactor setErrorPos to PackageError.setPos
+ 2021-01-14 6aa28d3e06 go/build: report positions for go:embed directives
+ 2021-01-14 9734fd482d [dev.regabi] cmd/compile: use node walked flag to prevent double walk for walkSwitch
+ 2021-01-14 f97983249a [dev.regabi] cmd/compile: move more PAUTOHEAP to SSA construction
+ 2021-01-14 4476300425 [dev.regabi] cmd/compile: use byte for CallExpr.Use
+ 2021-01-14 5a5ab24689 [dev.regabi] cmd/compile: do not rely on CallExpr.Rargs for detect already walked calls
+ 2021-01-14 983ac4b086 [dev.regabi] cmd/compile: fix ICE when initializing blank vars
+ 2021-01-13 7eb31d999c cmd/go: add hints to more missing sum error messages
+ 2021-01-13 d6d4673728 [dev.regabi] cmd/compile: fix GOEXPERIMENT=regabi builder
+ 2021-01-13 c41b999ad4 [dev.regabi] cmd/compile: refactor abiutils from "gc" into new "abi"
+ 2021-01-13 861707a8c8 [dev.regabi] cmd/compile: added limited //go:registerparams pragma for new ABI dev
+ 2021-01-13 c1370e918f [dev.regabi] cmd/compile: add code to support register ABI spills around morestack calls
+ 2021-01-13 2abd24f3b7 [dev.regabi] test: make run.go error messages slightly more informative
+ 2021-01-13 9a19481acb [dev.regabi] cmd/compile: make ordering for InvertFlags more stable
+ 2021-01-12 ba76567bc2 cmd/go/internal/modload: delete unused *mvsReqs.next method
+ 2021-01-12 665def2c11 encoding/asn1: document unmarshaling behavior for IMPLICIT string fields
+ 2021-01-11 81ea89adf3 cmd/go: fix non-script staleness checks interacting badly with GOFLAGS
+ 2021-01-11 759309029f doc: update editors.html for Go 1.16
+ 2021-01-11 c3b4c7093a cmd/internal/objfile: don't require runtime.symtab symbol for XCOFF
+ 2021-01-08 59bfc18e34 cmd/go: add hint to read 'go help vcs' to GOVCS errors
+ 2021-01-08 cd6f3a54e4 cmd/go: revise 'go help' documentation for modules
+ 2021-01-08 6192b98751 cmd/go: make hints in error messages more consistent
+ 2021-01-08 25886cf4bd cmd/go: preserve sums for indirect deps fetched by 'go mod download'
+ 2021-01-08 6250833911 runtime/metrics: mark histogram metrics as cumulative
+ 2021-01-08 8f6a9acbb3 runtime/metrics: remove unused StopTheWorld Description field
+ 2021-01-08 6598c65646 cmd/compile: fix exponential-time init-cycle reporting
+ 2021-01-08 fefad1dc85 test: fix timeout code for invoking compiler
+ 2021-01-08 6728118e0a cmd/go: pass signals forward during "go tool"
+ 2021-01-08 e65c543f3c go/build/constraint: add parser for build tag constraint expressions
+ 2021-01-08 0c5afc4fb7 testing/fstest,os: clarify racy behavior of TestFS
+ 2021-01-08 32afcc9436 runtime/metrics: change unit on *-by-size metrics to match bucket unit
+ 2021-01-08 c6513bca5a io/fs: minor corrections to Glob doc
+ 2021-01-08 304f769ffc cmd/compile: don't short-circuit copies whose source is volatile
+ 2021-01-08 ae97717133 runtime,runtime/metrics: use explicit histogram boundaries
+ 2021-01-08 a9ccd2d795 go/build: skip string literal while findEmbed
+ 2021-01-08 d92f8add32 archive/tar: fix typo in comment
+ 2021-01-08 cab1202183 cmd/link: accept extra blocks in TestFallocate
+ 2021-01-08 ee4d32249b io/fs: minor corrections to Glob release date
+ 2021-01-08 54bd1ccce2 cmd: update to latest golang.org/x/tools
+ 2021-01-07 9ec21a8f34 Revert "reflect: support multiple keys in struct tags"
+ 2021-01-07 091414b5b7 io/fs: correct WalkDirFunc documentation
+ 2021-01-07 9b55088d6b doc/go1.16: add release note for disallowing non-ASCII import paths
+ 2021-01-07 fa90aaca7d cmd/compile: fix late expand_calls leaf type for OpStructSelect/OpArraySelect
+ 2021-01-07 7cee66d4cb cmd/go: add documentation for Embed fields in go list output
+ 2021-01-07 e60cffa4ca html/template: attach functions to namespace
+ 2021-01-07 6da2d3b7d7 cmd/link: fix typo in asm.go
+ 2021-01-07 df81a15819 runtime: check mips64 VDSO clock_gettime return code
+ 2021-01-06 4787e906cf crypto/x509: rollback new CertificateRequest fields
+ 2021-01-06 c9658bee93 cmd/go: make module suggestion more friendly
+ 2021-01-06 4c668b25c6 runtime/metrics: fix panic message for Float64Histogram
+ 2021-01-06 d2131704a6 net/http/httputil: fix deadlock in DumpRequestOut
+ 2021-01-05 3e1e13ce6d cmd/go: set cfg.BuildMod to "readonly" by default with no module root
+ 2021-01-05 0b0d004983 cmd/go: pass embedcfg to gccgo if supported
+ 2021-01-05 1b85e7c057 cmd/go: don't scan gccgo standard library packages for imports
+ 2021-01-05 6b37b15d95 runtime: don't take allglock in tracebackothers
+ 2021-01-04 9eef49cfa6 math/rand: fix typo in comment
+ 2021-01-04 b01fb2af9e testing/fstest: fix typo in error message
+ 2021-01-01 3dd5867605 doc: 2021 is the Year of the Gopher
+ 2020-12-31 95ce805d14 io/fs: remove darwin/arm64 special condition
+ 2020-12-30 20d0991b86 lib/time, time/tzdata: update tzdata to 2020f
+ 2020-12-30 ed301733bb misc/cgo/testcarchive: remove special flags for Darwin/ARM
+ 2020-12-30 0ae2e032f2 misc/cgo/test: enable TestCrossPackageTests on darwin/arm64
+ 2020-12-29 780b4de16b misc/ios: fix wording for command line instructions
+ 2020-12-29 b4a71c95d2 doc/go1.16: reference misc/ios/README for how to build iOS programs
+ 2020-12-29 f83e0f6616 misc/ios: add to README how to build ios executables
+ 2020-12-28 4fd9455882 io/fs: fix typo in comment
Change-Id: If24bb93f1e1e7deb1d92ba223c85940ab93b2732
Several of the bugs in #43818 are because we were not scanning the body
of an possibly inlined closure in tooHairy(). I think this scanning got
lost in the rebase past some of the ir changes. This fixes the issue
related to the SELRECV2 and the bug reported from cuonglm. There is at
least one other bug related to escape analysis which I'll fix in another
change.
Change-Id: I8f38cd12a287881155403bbabbc540ed5fc2248e
Reviewed-on: https://go-review.googlesource.com/c/go/+/285676
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The example for WriteFile assumed the existence of a testdata/ directory, which is not present on the playground. The example now writes the file to the current working directory, rather than to testdata/.
Fixes#32916
Change-Id: I577caac7e67ba9d9941b2dd19346ad5ff61e78d9
GitHub-Last-Rev: 40f14e0adc
GitHub-Pull-Request: golang/go#43757
Reviewed-on: https://go-review.googlesource.com/c/go/+/284452
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
In msan mode we instrument code with msan* functions, including
msanmove. In some configurations the code is instrumented by the
compiler but msan is not actually linked in, so we need dummy
definitions for those functions so the program links. msanmove is
newly added in CL 270859 but a dummy definition in msan0.go was
not added, causing link failures. Add it.
Change-Id: I91f8e749919f57f1182e90b43412b0282cf4767c
Reviewed-on: https://go-review.googlesource.com/c/go/+/285955
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In the signal handler, we adjust gsingal's stack to the stack
where the signal is delivered. TSAN may deliver signals to the
g0 stack, so we have a special case for the g0 stack. However,
we don't have very good accuracy in determining the g0 stack's
bounds, as it is system allocated and we don't know where it is
exactly. If g0.stack.lo is too low, the condition may be
triggered incorrectly, where we thought the signal is delivered to
the g0 stack but it is actually not. In this case, as the stack
bounds is actually wrong, when the stack grows, it may go below
the (inaccurate) lower bound, causing "morestack on gsignal"
crash.
Check for g0 stack last to avoid this situation. There could still
be false positives, but for those cases we'll crash either way.
(If we could in some way determine the g0 stack bounds accurately,
this would not matter (but probably doesn't hurt).)
Fixes#43853.
Change-Id: I759717c5aa2b0deb83ffb23e57b7625a6b249ee8
Reviewed-on: https://go-review.googlesource.com/c/go/+/285772
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Previously, if CC was a path without separators (like gcc or clang),
we'd look it up in PATH in cmd/go using internal/execabs.LookPath,
then pass the resolved path to cgo in CC.
This caused a regression: if the directory in PATH containing CC has a
space, cgo splits it and interprets it as multiple arguments.
With this change, cmd/go no longer resolves CC before invoking
cgo. cgo does the path lookup on each invocation. This reverts the
security fix CL 284780, but that was redundant with the addition of
internal/execabs (CL 955304), which still protects us.
Fixes#43808
Updates #41400
Change-Id: I65d91a1e303856df8653881eb6e2e75a3bf95c49
Reviewed-on: https://go-review.googlesource.com/c/go/+/285873
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This merge had two conflicts to resolve:
1. The embed code on master had somewhat substantially diverged, so
this CL tediously backported the changes to dev.regabi. In particular,
I went through all of the embed changes to gc/{embed,noder,syntax}.go
and made sure the analogous code on dev.regabi in noder/noder.go and
staticdata/embed.go mirrors it.
2. The init-cycle reporting code on master was extended slightly to
track already visited declarations to avoid exponential behavior. The
same fix is applied on dev.regabi, just using ir.NameSet instead of
map[ir.Node]bool.
Conflicts:
- src/cmd/compile/internal/gc/embed.go
- src/cmd/compile/internal/gc/noder.go
- src/cmd/compile/internal/gc/syntax.go
- src/cmd/compile/internal/pkginit/initorder.go
- src/embed/internal/embedtest/embed_test.go
- src/go/types/stdlib_test.go
Merge List:
+ 2021-01-22 dab3e5affe runtime: switch runtime to libc for openbsd/amd64
+ 2021-01-22 a1b53d85da cmd/go: add documentation for test and xtest fields output by go list
+ 2021-01-22 b268b60774 runtime: remove pthread_kill/pthread_self for openbsd
+ 2021-01-22 ec4051763d runtime: fix typo in mgcscavenge.go
+ 2021-01-22 7ece3a7b17 net/http: fix flaky TestDisableKeepAliveUpgrade
+ 2021-01-22 50cba0506f time: clarify Timer.Reset behavior on AfterFunc Timers
+ 2021-01-22 cf10e69f17 doc/go1.16: mention net/http.Transport.GetProxyConnectHeader
+ 2021-01-22 ec1b945265 doc/go1.16: mention path/filepath.WalkDir
+ 2021-01-22 11def3d40b doc/go1.16: mention syscall.AllThreadsSyscall
+ 2021-01-21 07b0235609 doc/go1.16: add notes about package-specific fs.FS changes
+ 2021-01-21 e2b4f1fea5 doc/go1.16: minor formatting fix
+ 2021-01-21 9f43a9e07b doc/go1.16: mention new debug/elf constants
+ 2021-01-21 3c2f11ba5b cmd/go: overwrite program name with full path
+ 2021-01-21 953d1feca9 all: introduce and use internal/execabs
+ 2021-01-21 b186e4d70d cmd/go: add test case for cgo CC setting
+ 2021-01-21 5a8a2265fb cmd/cgo: report exec errors a bit more clearly
+ 2021-01-21 46e2e2e9d9 cmd/go: pass resolved CC, GCCGO to cgo
+ 2021-01-21 3d40895e36 runtime: switch openbsd/arm64 to pthreads
+ 2021-01-21 d95ca91380 crypto/elliptic: fix P-224 field reduction
+ 2021-01-20 ecf4ebf100 cmd/internal/moddeps: check content of all modules in GOROOT
+ 2021-01-20 d2d155d1ae runtime: don't adjust timer pp field in timerWaiting status
+ 2021-01-20 803d18fc6c cmd/go: set Incomplete field on go list output if no files match embed
+ 2021-01-20 6e243ce71d cmd/go: have go mod vendor copy embedded files in subdirs
+ 2021-01-20 be28e5abc5 cmd/go: fix mod_get_fallback test
+ 2021-01-20 928bda4f4a runtime: convert openbsd/amd64 locking to libc
+ 2021-01-19 824f2d635c cmd/go: allow go fmt to complete when embedded file is missing
+ 2021-01-19 0575e35e50 cmd/compile: require 'go 1.16' go.mod line for //go:embed
+ 2021-01-19 ccb2e90688 cmd/link: exit before Asmb2 if error
+ 2021-01-19 ca5774a5a5 embed: treat uninitialized FS as empty
+ 2021-01-19 d047c91a6c cmd/link,runtime: switch openbsd/amd64 to pthreads
+ 2021-01-19 61debffd97 runtime: factor out usesLibcall
+ 2021-01-19 9fed39d281 runtime: factor out mStackIsSystemAllocated
+ 2021-01-18 dbab079835 runtime: free Windows event handles after last lock is dropped
+ 2021-01-18 5a8fbb0d2d os: do not close syscall.Stdin in TestReadStdin
+ 2021-01-15 682a1d2176 runtime: detect errors in DuplicateHandle
+ 2021-01-15 9f83418b83 cmd/link: remove GOROOT write in TestBuildForTvOS
+ 2021-01-15 ec9470162f cmd/compile: allow embed into any string or byte slice type
+ 2021-01-15 54198b04db cmd/compile: disallow embed of var inside func
+ 2021-01-15 b386c735e7 cmd/go: fix go generate docs
+ 2021-01-15 bb5075a525 syscall: remove RtlGenRandom and move it into internal/syscall
+ 2021-01-15 1deae0b597 os: invoke processKiller synchronously in testKillProcess
+ 2021-01-15 ff196c3e84 crypto/x509: update iOS bundled roots to version 55188.40.9
+ 2021-01-14 e125ccd10e cmd/go: in 'go mod edit', validate versions given to -retract and -exclude
+ 2021-01-14 eb330020dc cmd/dist, cmd/go: pass -arch for C compilation on Darwin
+ 2021-01-14 84e8a06f62 cmd/cgo: remove unnecessary space in cgo export header
+ 2021-01-14 0c86b999c3 cmd/test2json: document passing -test.paniconexit0
+ 2021-01-14 9135795891 cmd/go/internal/load: report positions for embed errors
+ 2021-01-14 d9b79e53bb cmd/compile: fix wrong complement for arm64 floating-point comparisons
+ 2021-01-14 c73232d08f cmd/go/internal/load: refactor setErrorPos to PackageError.setPos
+ 2021-01-14 6aa28d3e06 go/build: report positions for go:embed directives
+ 2021-01-13 7eb31d999c cmd/go: add hints to more missing sum error messages
+ 2021-01-12 ba76567bc2 cmd/go/internal/modload: delete unused *mvsReqs.next method
+ 2021-01-12 665def2c11 encoding/asn1: document unmarshaling behavior for IMPLICIT string fields
+ 2021-01-11 81ea89adf3 cmd/go: fix non-script staleness checks interacting badly with GOFLAGS
+ 2021-01-11 759309029f doc: update editors.html for Go 1.16
+ 2021-01-11 c3b4c7093a cmd/internal/objfile: don't require runtime.symtab symbol for XCOFF
+ 2021-01-08 59bfc18e34 cmd/go: add hint to read 'go help vcs' to GOVCS errors
+ 2021-01-08 cd6f3a54e4 cmd/go: revise 'go help' documentation for modules
+ 2021-01-08 6192b98751 cmd/go: make hints in error messages more consistent
+ 2021-01-08 25886cf4bd cmd/go: preserve sums for indirect deps fetched by 'go mod download'
+ 2021-01-08 6250833911 runtime/metrics: mark histogram metrics as cumulative
+ 2021-01-08 8f6a9acbb3 runtime/metrics: remove unused StopTheWorld Description field
+ 2021-01-08 6598c65646 cmd/compile: fix exponential-time init-cycle reporting
+ 2021-01-08 fefad1dc85 test: fix timeout code for invoking compiler
+ 2021-01-08 6728118e0a cmd/go: pass signals forward during "go tool"
+ 2021-01-08 e65c543f3c go/build/constraint: add parser for build tag constraint expressions
+ 2021-01-08 0c5afc4fb7 testing/fstest,os: clarify racy behavior of TestFS
+ 2021-01-08 32afcc9436 runtime/metrics: change unit on *-by-size metrics to match bucket unit
+ 2021-01-08 c6513bca5a io/fs: minor corrections to Glob doc
+ 2021-01-08 304f769ffc cmd/compile: don't short-circuit copies whose source is volatile
+ 2021-01-08 ae97717133 runtime,runtime/metrics: use explicit histogram boundaries
+ 2021-01-08 a9ccd2d795 go/build: skip string literal while findEmbed
+ 2021-01-08 d92f8add32 archive/tar: fix typo in comment
+ 2021-01-08 cab1202183 cmd/link: accept extra blocks in TestFallocate
+ 2021-01-08 ee4d32249b io/fs: minor corrections to Glob release date
+ 2021-01-08 54bd1ccce2 cmd: update to latest golang.org/x/tools
+ 2021-01-07 9ec21a8f34 Revert "reflect: support multiple keys in struct tags"
+ 2021-01-07 091414b5b7 io/fs: correct WalkDirFunc documentation
+ 2021-01-07 9b55088d6b doc/go1.16: add release note for disallowing non-ASCII import paths
+ 2021-01-07 fa90aaca7d cmd/compile: fix late expand_calls leaf type for OpStructSelect/OpArraySelect
+ 2021-01-07 7cee66d4cb cmd/go: add documentation for Embed fields in go list output
+ 2021-01-07 e60cffa4ca html/template: attach functions to namespace
+ 2021-01-07 6da2d3b7d7 cmd/link: fix typo in asm.go
+ 2021-01-07 df81a15819 runtime: check mips64 VDSO clock_gettime return code
+ 2021-01-06 4787e906cf crypto/x509: rollback new CertificateRequest fields
+ 2021-01-06 c9658bee93 cmd/go: make module suggestion more friendly
+ 2021-01-06 4c668b25c6 runtime/metrics: fix panic message for Float64Histogram
+ 2021-01-06 d2131704a6 net/http/httputil: fix deadlock in DumpRequestOut
+ 2021-01-05 3e1e13ce6d cmd/go: set cfg.BuildMod to "readonly" by default with no module root
+ 2021-01-05 0b0d004983 cmd/go: pass embedcfg to gccgo if supported
+ 2021-01-05 1b85e7c057 cmd/go: don't scan gccgo standard library packages for imports
+ 2021-01-05 6b37b15d95 runtime: don't take allglock in tracebackothers
+ 2021-01-04 9eef49cfa6 math/rand: fix typo in comment
+ 2021-01-04 b01fb2af9e testing/fstest: fix typo in error message
+ 2021-01-01 3dd5867605 doc: 2021 is the Year of the Gopher
+ 2020-12-31 95ce805d14 io/fs: remove darwin/arm64 special condition
+ 2020-12-30 20d0991b86 lib/time, time/tzdata: update tzdata to 2020f
+ 2020-12-30 ed301733bb misc/cgo/testcarchive: remove special flags for Darwin/ARM
+ 2020-12-30 0ae2e032f2 misc/cgo/test: enable TestCrossPackageTests on darwin/arm64
+ 2020-12-29 780b4de16b misc/ios: fix wording for command line instructions
+ 2020-12-29 b4a71c95d2 doc/go1.16: reference misc/ios/README for how to build iOS programs
+ 2020-12-29 f83e0f6616 misc/ios: add to README how to build ios executables
+ 2020-12-28 4fd9455882 io/fs: fix typo in comment
Change-Id: I2f257bbc5fbb05f15c2d959f8cfe0ce13b083538
The previous code was stylized after noder, which was written when it
was more idiomatic to simple create a gc.Node and then populate and
shuffle around its fields as appropriate.
Now with package ir, it's somewhat nicer to compute all the fields up
front and pass them to the constructor functions, rather than passing
nil and populating the fields afterwards.
Net addition of lines of code, but I think the new code is overall
still somewhat simpler, and will be easier to refactor out into code
for helpers.go.
Change-Id: I8c6f6b65e0a8317129655a0fc493d8af75527b97
Reviewed-on: https://go-review.googlesource.com/c/go/+/285732
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
The TestEmbedPatterns, TestEmbedFiles, XTestEmbedPatterns, and
XTestEmbedFiles fields were left out of golang.org/cl/282195 which was
supposed to document the embed fields available in the go list
output. Add documentation for them in this CL.
Fixes#43081
Change-Id: Ifc256c476daec7c0f0e2c41f86b82f958b3e2b1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/284258
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This CL imports tests for the go/types API from the dev.go2go branch.
Only parse type parameters for packages with a magic prefix, with the
rationale that while generics are in preview, we want existing
(non-generic) tests to exercise the default mode.
Change-Id: I8ae0d8769b997a8a93b708453a1afaecb262244d
Reviewed-on: https://go-review.googlesource.com/c/go/+/284693
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
By using the types2 Selection information, we can create ODOT, ODOTPTR,
OCALLPART, ODOTMETH, ODOTINTER, and OMETHEXPR nodes directly in noder,
so we don't have to do that functionality in typecheck.go. Intermediate
nodes are created as needed for embedded fields. Don't have to typecheck
the results of g.selectorExpr(), because we set the types of all the
needed nodes.
There is one bug remaining in 'go test reflect' that will be fixed when dev.regabi is merged.
Change-Id: I4599d43197783e318610deb2f208137f9344ab63
Reviewed-on: https://go-review.googlesource.com/c/go/+/285373
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The types2.Config.IgnoreBranches flag mistakenly excluded a
set of label-unrelated branch checks. After fixing this and
also adjusting some error messages to match the existing
compiler errors, more errorcheck tests pass now with the -G
option.
Renamed IngnoreBranches to IgnoreLabels since its controlling
label checks, not all branch statement (such as continue, etc)
checks.
Change-Id: I0819f56eb132ce76c9a9628d8942af756691065a
Reviewed-on: https://go-review.googlesource.com/c/go/+/285652
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This patch fixes two independent bugs in p224Contract, the function that
performs the final complete reduction in the P-224 field. Incorrect
outputs due to these bugs were observable from a high-level
P224().ScalarMult() call.
The first bug was in the calculation of out3GT. That mask was supposed
to be all ones if the third limb of the value is greater than the third
limb of P (out[3] > 0xffff000). Instead, it was also set if they are
equal. That meant that if the third limb was equal, the value was always
considered greater than or equal to P, even when the three bottom limbs
were all zero. There is exactly one affected value, P - 1, which would
trigger the subtraction by P even if it's lower than P already.
The second bug was more easily hit, and is the one that caused the known
high-level incorrect output: after the conditional subtraction by P, a
potential underflow of the lowest limb was not handled. Any values that
trigger the subtraction by P (values between P and 2^224-1, and P - 1
due to the bug above) but have a zero lowest limb would produce invalid
outputs. Those conditions apply to the intermediate representation
before the subtraction, so they are hard to trace to precise inputs.
This patch also adds a test suite for the P-224 field arithmetic,
including a custom fuzzer that automatically explores potential edge
cases by combining limb values that have various meanings in the code.
contractMatchesBigInt in TestP224Contract finds the second bug in less
than a second without being tailored to it, and could eventually find
the first one too by combining 0, (1 << 28) - 1, and the difference of
(1 << 28) and (1 << 12).
The incorrect P224().ScalarMult() output was found by the
elliptic-curve-differential-fuzzer project running on OSS-Fuzz and
reported by Philippe Antoine (Catena cyber).
Fixes CVE-2021-3114
Fixes#43786
Change-Id: I50176602d544de3da854270d66a293bcaca57ad7
Reviewed-on: https://go-review.googlesource.com/c/go/+/284779
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Represent x++/-- as x +=/-= with the RHS of the assignment being nil
rather than syntax.ImplicitOne.
Dependent code already had to check for syntax.ImplicitOne, but
then shared some existing code for regular assignment operations.
Now always handle this case fully explicit, which simplifies the
code.
Change-Id: I28c7918153c27cbbf97b041d0c85ff027c58687c
Reviewed-on: https://go-review.googlesource.com/c/go/+/285172
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This CL updates irgen to directly set the type for a bunch of basic
expressions that are easy to handle already. Trickier rewrites are
still handled with typecheck.Expr, but responsibility of calling that
is pushed down to the conversion of individual operations.
Change-Id: I774ac6ab4c72ad854860ab5c741867dd42a066b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/285058
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
For the predeclared "delete" function, types2 was checking that the
second argument was assignable to the map's key type, but not actually
updating the Types map as appropriate. So this could leave untyped
constants in the AST.
The error "cannot convert" is somewhat less precise than the previous
"not assignable" error, but it's consistent with how types2 reports
other erroneous assignments of untyped constants.
Change-Id: Ic3ca3a3611ad0e4646c050e93088cdf992234e5f
Reviewed-on: https://go-review.googlesource.com/c/go/+/285059
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
I have exporting, importing, and inlining of functions with closures
working in all cases (issue #28727). all.bash runs successfully without
errors.
Approach:
- Write out the Func type, Dcls, ClosureVars, and Body when exporting
an OCLOSURE.
- When importing an OCLOSURE, read in the type, dcls, closure vars,
and body, and then do roughly equivalent code to (*noder).funcLit
- During inlining of a closure within inlined function, create new
nodes for all params and local variables (including closure
variables), so they can have a new Curfn and some other field
values. Must substitute not only on the Nbody of the closure, but
also the Type, Cvars, and Dcl fields.
Fixes#28727
Change-Id: I4da1e2567c3fa31a5121afbe82dc4e5ee32b3170
Reviewed-on: https://go-review.googlesource.com/c/go/+/283112
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
This CL moves qualified identifier handling into expr0 with other
selector expressions, rather than as a completely separate special
case handled up front. This has a few benefits:
1. It's marginally simpler/cleaner.
2. It allows extra checking for imported objects that they have the
same type that types2 thought they had.
3. For imported, untyped constants, we now instead handle them with
the "tv.Value != nil" case. In particular, this ensures that they've
always already been coerced to the appropriate concrete type by
types2.
Change-Id: Ibf44ae6901db36aa5251f70934616e9fcbd1cbc5
Reviewed-on: https://go-review.googlesource.com/c/go/+/285053
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Expand the scope of the TestAllDependenciesVendored test to check
that all modules in GOROOT are tidy, that packages are vendored,
the vendor content matches the upstream copy exactly, and that
bundled packages are re-generated (using x/tools/cmd/bundle at
the version selected in cmd module; this is deterministic and
guaranteed to be updated over time).
This is done in a conceptually simple way:
1. Make a temporary copy of the entire GOROOT tree (except .git),
one that is safe to modify.
2. Run a list of high-level commands, the same commands we expect
Go developers should be able to run in a normal complete GOROOT
tree to make it clean and tidy.
3. Diff the end result with the original GOROOT tree being tested
to catch any unexpected differences.
The current set of commands that are run require the cmd/go command,
and a functional compiler itself (because re-generating the syscall
package involves a directive like //go:generate go run [...]). As a
result, copying a large majority of the GOROOT tree is a requirement.
Instead of looking for the few files or directories that can we can
get away not copying (e.g., the testdata directories aren't strictly
needed at this time), we opt not to optimize and just do the simple
copy. This is motivated by these reasons:
• We end up having a complete, normal GOROOT tree, one that happens
to be located at another path. There's a very high likelihood that
module management/code generation commands, both the ones we run
today and any additional ones that we might want to add in the
future, will result in correct results even as the Go project
evolves over time.
• Having a completely stand-alone copy of the GOROOT tree without
symlinks minimizes the risk of some of the module management/code
generation commands, either now or in the future, from modifying
the user's original GOROOT tree, something that should not happen
during test execution. Overlays achieved with symlinks work well
when we can guarantee only new files are added, but that isn't
the case here.
• Copying the entire GOROOT (without .git), takes around 5 seconds
on a fairly modern computer with an SSD. The most we can save is
a couple of seconds.
(We make some minor exceptions: the GOROOT/.git directory isn't copied,
and GOROOT/{bin,pkg} are deemed safe to share and thus symlink instead
of copying. If these optimizations cease to be viable to make, we'll
need to remove them.)
Since this functionality is fairly expensive to execute and requires
network access, it runs only when the test is executed without -short
flag. The previous behavior of the TestAllDependenciesVendored test is
kept in -short test mode. all.bash runs package tests with -short flag,
so its behavior is unchanged. The expectation is that the new test will
run on some of the longtest builders to catch problems. Users can invoke
the test manually 'go test cmd/internal/moddeps' (and it's run as part
of 'go test cmd', again, only when -short flag isn't provided).
On a 2017 MacBook Pro, a successful long test takes under 15 seconds,
which should be within scope of all long tests that are selected by
'go test std cmd'. We may further adjust when and where the test runs
by default based on our experience.
Fixes#36852.
Fixes#41409.
Fixes#43687.
Updates #43440.
Change-Id: I9eb85205fec7ec62e3f867831a0a82e3c767f618
Reviewed-on: https://go-review.googlesource.com/c/go/+/283643
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
By-hand rebase of earlier CL, because that was easier than
letting git try to figure things out.
This will naively insert self-moves; in the case that these
involve memory, the expander detects these and removes them
and their vardefs.
Change-Id: Icf72575eb7ae4a186b0de462bc8cf0bedc84d3e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/279519
Trust: David Chase <drchase@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Before this CL, the following sequence was possible:
* GC scavenger starts and sets up scavenge.timer
* GC calls readyForScavenger, but sysmon is sleeping
* program calls runtime.GOMAXPROCS to shrink number of processors
* procresize destroys a P, the one that scavenge.timer is on
* (*pp).destroy calls moveTimers, which gets to the scavenger timer
* scavenger timer is timerWaiting, and moveTimers clears t.pp
* sysmon wakes up and calls wakeScavenger
* wakeScavengers calls stopTimer on scavenger.timer, still timerWaiting
* stopTimer calls deltimer which loads t.pp, which is still nil
* stopTimer tries to increment deletedTimers on nil t.pp, and crashes
The point of vulnerability is the time that t.pp is set to nil by
moveTimers and the time that t.pp is set to non-nil by moveTimers,
which is a few instructions at most. So it's not likely and in
particular is quite unlikely on x86. But with a more relaxed memory
model the area of vulnerability can be somewhat larger. This appears
to tbe the cause of two builder failures in a few months on linux-mips.
This CL fixes the problem by making moveTimers change the status from
timerWaiting to timerMoving while t.pp is clear. That will cause
deltimer to wait until the status is back to timerWaiting, at which
point t.pp has been set again.
Fixes#43712
Change-Id: I66838319ecfbf15be66c1fac88d9bd40e2295852
Reviewed-on: https://go-review.googlesource.com/c/go/+/284775
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
If a package vendored with go mod vendor depends on embedded
files contained in subdirectories, copy them into the the
corresponding place in the module's vendor tree. (Embeds in
parent directories are disallowed by the embed pattern rules, and
embeds in the same directory are copied because go mod vendor
already copies the non-go files in the package's own directory).
Export the vendor pattern expansion code in internal/load so
internal/modcmd's vendor code can use it.
Fixes#43077
Change-Id: I61edb344d73df590574a6498ffb6069e8d72a147
Reviewed-on: https://go-review.googlesource.com/c/go/+/283641
Trust: Michael Matloob <matloob@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Add tests from the dev.go2go branch, modified to eliminate support for
parenthesized type embedding and method type parameters. For the most
part these tests were made to pass via the fixes from preceding CLs in
this stack.
While integrating support for type parameters with the changes to
go/types in master, a decision was made to temporarily use an error code
of 0 for new error messages. Now that these messages are actually
emitted during checking of test packages, it is a test failure for them
to have an error code of 0. To satisfy the test, create a new temporary
error code '_Todo', which represents an error code that has not yet been
assigned. _Todo is added only where it was necessary to make tests pass:
many error codes were left as 0, meaning we don't have any tests that
produce them. This marker may help us produce more comprehensive tests
in the future.
Finally, each package checked by testDir was made into a subtest, for
the ease of running individual packages while debugging test failures.
This seemed worth keeping.
Change-Id: Iba421b797e9fb11af664a73902f67d6c4f30ecad
Reviewed-on: https://go-review.googlesource.com/c/go/+/283854
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
Some logic was missing in the merge from dev.go2go to deal with untyped
conversion of generic types. Part of this was due to the complexity of
the merge, as untyped conversion had been refactored on master.
Rather than back out the refactoring of untyped conversion, in this CL I
have decided to take it one step further. It was always problematic that
isRepresentable and canConvertUntyped mutated their arguments. In
retrospect the refactoring was perhaps too conservative.
This CL performs the following refactoring:
+ Replace 'isRepresentable' with 'representation': a Checker method
produces the rounded representation of an untyped constant operand as
a target type.
+ Make some functions return error codes rather than errors, and factor
out the construction of the error message for invalid conversion.
This avoided some indirect code.
+ Replace implicitType with implicitTypeAndValue, and have it handle
the case of a constant basic operand, returning the rounded value.
+ Eliminate canConvertUntyped, lifting the logic to update expr types
and values to the two callers.
+ Add handling for Sum types in implicitTypeAndValue. Here, the
decision was made to depart from dev.go2go (and types2), and produce
a Sum type as output. This seemed most correct on first principles,
and tests still passed (though some logic for recording types had to
be updated to allow for Sum types).
Change-Id: Ic93901f69e6671b83b14ee2bf185a4ed767e31ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/284256
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
With this CL, the type reported for uses of the predeclared
identifier nil changes from untyped nil to the type of the
context within which nil is used, matching the behaviour of
types2 for other untyped types.
If an untyped nil value is assigned or converted to an
interface, the nil expression is given the interface type.
The predicate TypeAndValue.IsNil doesn't change in behavior,
it still reports whether the relevant expression is a (typed
or untyped) nil value.
Change-Id: Id766468f3f3f2a53e4c55e1e6cd521e459c4a94f
Reviewed-on: https://go-review.googlesource.com/c/go/+/284218
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Strip annotations from errors before emitting them. This is a partial
merge from dev.go2go: the Error.Full field is omitted for now, and
stripAnnotations is integrated with the updated error handling from
master.
Change-Id: Ia24d66b691a10d90b258b0b688d50c6b176bd629
Reviewed-on: https://go-review.googlesource.com/c/go/+/284253
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
Unify methods in Checker.missingMethod. This code was accidentally
dropped from the merge, while dropping support for method type
parameters, but is needed for checking implementations of generic
interfaces.
Put the logic back, including checks that are only needed for method
type parameters. It makes the code no simpler to assume that method type
parameters are disallowed, and we have checks elsewhere that produce
errors for methods with type parameters.
Change-Id: I91f0c9d3e04537fdb9f7ae23a4ce4cec9f1da10e
Reviewed-on: https://go-review.googlesource.com/c/go/+/284252
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
It should be an invariant that the parser does not produce ast.CallExprs
with Brackets == true unless parsing with ParseTypeParams.
Fix the one case where this invariant was violated, and add a test for
errors produced in valid generic code when ParseTypeParams is unset. We
did have some coverage of errors in short_test.go, but I find them to be
easier to read in a testdata file and would like to gradually migrate
them there.
Change-Id: If2d174377087daa1b820cabc2b5bf8bcb0b39d8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/284192
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
If we see the exact same types2.Type a second time, we can map it to
the same *types.Type instance. Not strictly necessary, but reduces
memory usage and plays better with the rest of the compiler given the
current state of things.
Change-Id: I53686d072c7c7834b0c97417bc8d5f2cd24572b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/284692
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This will produce better errors when earlier versions of
Go compile code using //go:embed. (The import will cause
a compilation error but then the go command will add to
the output that the Go toolchain in use looks too old
and maybe that's the problem.)
This CL also adds a test for disallowing embed of a var inside a func.
It's a bit too difficult to rebase down into that CL.
The build system configuration check is delayed in order to
make it possible to use errorcheck for these tests.
Change-Id: I12ece4ff2d8d53380b63f54866e8f3497657d54c
Reviewed-on: https://go-review.googlesource.com/c/go/+/282718
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
If there are already errors emitted, don't run the Asmb2 pass
and just exit. At the point of Asmb2 relocations are already
resolved and errors should have been reported, if any. Asmb2 is
unlikely to emit additional useful users errors. Instead, the
invalid input may cause inconsistencies and crash the linker, or
it may emit some internal errors which are more confusing than
helpful. Exit on error before Asmb2.
Fixes#43748.
Change-Id: Icf6e27f2eef5b6259e921ec0e64bebad5dd805f8
Reviewed-on: https://go-review.googlesource.com/c/go/+/284576
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Rather than repeat long lists of GOOS values, factor out the code that checks
if a runtime starts on a system allocated stack. Note that this adds aix to
one case, which appears to have been previously missed.
Change-Id: I5cecb0bb47dd79cde8d723e5a42ba541e43cbfff
Reviewed-on: https://go-review.googlesource.com/c/go/+/250179
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Go Bot <gobot@golang.org>
These symbols are implementation details and don't correspond to Go
source symbols, so directly create them as linker symbols and get rid
of their pseudo packages.
Passes toolstash -cmp w/ -gcflags=all=-abiwrap.
Change-Id: I2e97374c21f3e909f6d350f15e7a5ed3574cadf4
Reviewed-on: https://go-review.googlesource.com/c/go/+/284372
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Currently there's a lot of logic within package types for creating
Linksyms. This CL pulls it out into base, where it can be more easily
reused by other compiler code that shouldn't need to depend on package
types.
Package base probably isn't the best place for this, but it's
convenient because it's a package that types already depends on. It's
also where the Ctxt object lives, which these functions depend upon.
Passes toolstash -cmp w/ -gcflags=all=-abiwrap.
Change-Id: I50d8b7e4596955205036969eab24d7dab053b363
Reviewed-on: https://go-review.googlesource.com/c/go/+/284231
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Now that TailCallStmt carries an *ir.Name instead of a *types.Sym,
callTargetLSym can be similarly updated to take the target function as
an *ir.Name.
This inches us closer towards being able to move Linksym and other
properties from *types.Sym to *ir.Name, where they belong.
Passes toolstash -cmp w/ -gcflags=all=-abiwrap.
Change-Id: I091da290751970eba8ed0438f66d6cca88b665a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/284228
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Calls to lock may need to use global members of mOS that also need to be
cleaned up before the thread exits. Before this commit, these resources
would leak. Moving them to be cleaned up in unminit, however, would race
with gstack on unix. So this creates a new helper, mdestroy, to release
resources that must be destroyed only after locks are no longer
required. We also move highResTimer lifetime to the same semantics,
since it doesn't help to constantly acquire and release the timer object
during dropm.
Updates #43720.
Change-Id: Ib3f598f3fda1b2bbcb608099616fa4f85bc1c289
Reviewed-on: https://go-review.googlesource.com/c/go/+/284137
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
By calling NewConsoleFile on syscall.Stdin, we wind up closing it when
the function returns, which causes errors when all the tests are run in
a loop. To fix this, we instead create a duplicate handle of stdin.
Fixes#43720.
Change-Id: Ie6426e6306c7e1e39601794f4ff48bbf2fe67502
Reviewed-on: https://go-review.googlesource.com/c/go/+/284140
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Currently, typecheck leaves arguments to OPANIC as their original
type. This CL changes it to insert implicit OCONVIFACE operations to
convert arguments to `interface{}` like how any other function call
would be handled.
No immediate benefits, other than getting to remove a tiny bit of
special-case logic in order.go's handling of OPANICs. Instead, the
generic code path for handling OCONVIFACE is used, if necessary.
Longer term, this should be marginally helpful for #43753, as it
reduces the number of cases where we need values to be addressable for
runtime calls.
However, this does require adding some hacks to appease existing
tests:
1. We need yet another kludge in inline budgeting, to ensure that
reflect.flag.mustBe stays inlinable for cmd/compile/internal/test's
TestIntendedInlining.
2. Since the OCONVIFACE expressions are now being introduced during
typecheck, they're now visible to escape analysis. So expressions like
"panic(1)" are now seen as "panic(interface{}(1))", and escape
analysis warns that the "interface{}(1)" escapes to the heap. These
have always escaped to heap, just now we're accurately reporting about
it.
(Also, unfortunately fmt.go hides implicit conversions by default in
diagnostics messages, so instead of reporting "interface{}(1) escapes
to heap", it actually reports "1 escapes to heap", which is
confusing. However, this confusing messaging also isn't new.)
Change-Id: Icedf60e1d2e464e219441b8d1233a313770272af
Reviewed-on: https://go-review.googlesource.com/c/go/+/284412
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Matthew Dempsky <mdempsky@google.com>
ir.Pkgs.Itablink isn't used anymore. (I don't recall what it was ever
used for.)
ir.Pkgs.Race and ir.Pkgs.Msan are only needed in exactly only place,
so just create them on demand there, the same way that we create
"main" on demand.
Change-Id: I3474bb949f71cd40c7a462b9f4a369adeacde0d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/284230
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
This CL splits out ORETJMP as a new TailCallStmt node, separate from
the other BranchStmt nodes. In doing so, this allows us to change it
from identifying a function by *types.Sym to identifying one by
directly pointing to the *ir.Func.
While here, also rename the operation to OTAILCALL.
Passes toolstash -cmp.
Change-Id: I273e6ea5d92bf3005ae02fb59b3240a190a6cf1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/284227
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
CL 284223 tightened down the allowed expressions in mayCall, but
evidently a little too tight. The linux-amd64-noopt builder does in
fact see expressions with non-empty Init lists in arguments list.
Since I believe these can only appear on the RHS of LogicalExpr
expressions, this CL relaxes that one case.
Change-Id: I1e6bbd0449778c40ed2610b3e1ef6a825a84ada7
Reviewed-on: https://go-review.googlesource.com/c/go/+/284226
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
After CL 284220, we now only need to detect expressions that contain
function calls in the arguments list of further function calls. So we
can simplify Node.HasCall/fncall/etc a lot.
Instead of incrementally tracking whether an expression contains
function calls all throughout walk, simply check once at the point of
using an expression as a function call argument. Since any expression
checked here will itself become a function call argument, it won't be
checked again because we'll short circuit at the enclosing function
call.
Also, restructure the recursive walk code to use mayCall, and trim
down the list of acceptable expressions. It should be okay to be
stricter, since we'll now only see function call arguments and after
they've already been walked.
It's possible I was overly aggressive removing Ops here. But if so,
we'll get an ICE, and it'll be easy to re-add them. I think this is
better than the alternative of accidentally allowing expressions
through that risk silently clobbering the stack.
Passes toolstash -cmp.
Change-Id: I585ef35dcccd9f4018e4bf2c3f9ccb1514a826f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/284223
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Currently, to ensure OAS2FUNC results are assigned in the correct
order, they're always assigned to temporary variables. However, these
temporary variables are typed based on the destination type, which may
require an interface conversion. This means walk may have to then
introduce a second set of temporaries to ensure result parameters are
all copied out of the results area, before it emits calls to runtime
conversion functions.
That's just silly. Instead, this CL changes order to allocate the
result temporaries with the same type as the function returns in the
first place, and then assign them one at a time to their destinations,
with conversions as needed.
While here, also fix an order-of-evaluation issue with has-ok
assignments that I almost added to multi-value function call
assignments, and add tests for each.
Change-Id: I9f4e962425fe3c5e3305adbbfeae2c7f253ec365
Reviewed-on: https://go-review.googlesource.com/c/go/+/284220
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Tests should avoid writing to GOROOT when possible. Such writes
would fail if GOROOT is non-writeable, and it can interfere with
other tests that don't expect GOROOT to change during test execution.
Updates #28387.
Change-Id: I7d72614f218df3375540f5c2f9c9f8c11034f602
Reviewed-on: https://go-review.googlesource.com/c/go/+/284293
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The current implementation requires saying "string" or "[]byte"
and disallows aliases, defined types, and even "[]uint8".
This was not 100% intended and mostly just fell out of when
the checks were being done in the implementation (too early,
before typechecking).
After discussion on #43217 (forked into #43602),
the consensus was to allow all string and byte slice types,
same as we do for string conversions in the language itself.
This CL does that.
It's more code than you'd expect because the decision has
to be delayed until after typechecking.
But it also more closely aligns with the version that's
already on dev.regabi.
Fixes#43602.
Change-Id: Iba919cfadfbd5d7116f2bf47e2512fb1d5c36731
Reviewed-on: https://go-review.googlesource.com/c/go/+/282715
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Allowing embedding into []byte inside a func creates an
unfortunate problem: either all calls start with the same
underlying data and can see each other's changes to the
underlying data (surprising and racy!) or all calls start
by making their own copy of the underlying data
(surprising and expensive!).
After discussion on #43216, the consensus was to remove
support for all vars embedded inside functions.
Fixes#43216.
Change-Id: I01e62b5f0dcd9e8566c6d2286218e97803f54704
Reviewed-on: https://go-review.googlesource.com/c/go/+/282714
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The docs were never updated for the change to the placement
of the DO NOT EDIT line.
Also, the description of the DO NOT EDIT line interrupted the
description of the //go:generate line, which made for some
confusing references in the text that followed. Move it lower.
Fixes#41196.
Change-Id: I6af2a199fa98d45f5ccac7cdf7e9e54257699e61
Reviewed-on: https://go-review.googlesource.com/c/go/+/283633
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This fixes an inconsistency where the type for nil in code such as
var x unsafe.Pointer = nil
and in conversions of the form
T(nil)
(where T is a pointer, function, slice, map, channel, interface, or
unsafe.Pointer) was reported as (converted to) the respective type.
For all other operations that accept a nil value, we don't do this
conversion for nil.
(We never change the type of the untyped nil value, in contrast to
other untyped values where we give the values context-specific types.)
It may still be useful to change this behavior and - consistently -
report a converted nil type like we do for any other type, but for
now this CL simply fixes the existing inconsistency.
Added tests and fixed existing test harness.
Updates #13061.
Change-Id: Ia82832845c096e3cbc4a239ba3d6c8b9a9d274c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/284052
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
There's on need to expose this to the frozen syscall package, and it
also doesn't need to be unsafe. So we move it into internal/syscall and
have the generator make a safer function signature.
Fixes#43704.
Change-Id: Iccae69dc273a0aa97ee6846eb537f1dc1412f2de
Reviewed-on: https://go-review.googlesource.com/c/go/+/283992
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Previously, testKillProcess needlessly invoked processKiller in a
separate goroutine and failed to wait for that goroutine to complete,
causing the calls to t.Fatalf in that goroutine to potentially occur
after the test function had already returned.
Fixes#43722
Change-Id: I5d03cb24af51bb73f0ff96419dac57ec39776967
Reviewed-on: https://go-review.googlesource.com/c/go/+/284153
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
WriteType isn't safe for direct concurrent use, and users should
instead use TypeLinksym or another higher-level API provided by
reflectdata. After the previous CL, there are no remaining uses of
WriteType elsewhere in the compiler, so unexport it to keep it that
way.
For #43701.
[git-generate]
cd src/cmd/compile/internal/reflectdata
rf '
mv WriteType writeType
'
Change-Id: I294a78be570a47feb38a1ad4eaae7723653d5991
Reviewed-on: https://go-review.googlesource.com/c/go/+/284077
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The code for allocating linksyms and recording that we need runtime
type descriptors is now concurrent-safe, so move it to where those
symbols are actually needed to reduce complexity and risk of failing
to generate all needed symbols in advance.
For #43701.
Change-Id: I759d2508213ac9a4e0b504b51a75fa10dfa37a8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/284076
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Matthew Dempsky <mdempsky@google.com>
We decide during escape analysis whether to pass closure variables by
value or reference. One of the factors that's considered is whether a
variable has had its address taken.
However, this analysis is based only on the user-written source code,
whereas order+walk may introduce rewrites that take the address of a
variable (e.g., passing a uint16 key by reference to the size-generic
map runtime builtins).
Typically this would be harmless, albeit suboptimal. But in #43701 it
manifested as needing a stack object for a function where we didn't
realize we needed one up front when we generate symbols.
Probably we should just generate symbols on demand, now that those
routines are all concurrent-safe, but this is a first fix.
Thanks to Alberto Donizetti for reporting the issue, and Cuong Manh Le
for initial investigation.
Fixes#43701.
Change-Id: I16d87e9150723dcb16de7b43f2a8f3cd807a9437
Reviewed-on: https://go-review.googlesource.com/c/go/+/284075
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
fmt.go:dumpNodeHeader uses reflection to call all "func() bool"-typed
methods on Nodes during printing, but the OnStack method that I added
in CL 283233 isn't meant to be called on non-variables.
dumpNodeHeader does already guard against panics, as happen in some
other accessors, but not against Fatalf, as I was using in OnStack. So
simply change OnStack to use panic too.
Thanks to drchase@ for the report.
Change-Id: I0cfac84a96292193401a32fc5e7fd3c48773e008
Reviewed-on: https://go-review.googlesource.com/c/go/+/284074
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
On Apple Silicon Mac, the C compiler has an annoying default
target selection, depending on the ancestor processes'
architecture. In particular, if the shell or IDE is x86, when
running "go build" even with a native ARM64 Go toolchain, the C
compiler defaults to x86, causing build failures. We pass "-arch"
flag explicitly to avoid this situation.
Fixes#43692.
Fixes#43476.
Updates golang/vscode-go#1087.
Change-Id: I80b6a116a114e11e273c6886e377a1cc969fa3f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/283812
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The cgo header has an unnecessary space in the exported function
definition on non-windows goos.
This was introduced in go1.16 so it would be good to fix it before
release.
Example:
// Current behavior, notice there is an unecessary space
// between extern and void
extern void Foo();
// With this CL
extern void Foo();
Change-Id: Ic2c21f8d806fe35a7be7183dbfe35ac605b6e4f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/283892
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Katie Hockman <katie@golang.org>
This partially addresses the issue below: In many (all) cases we want to
handle invalid ... use in the parser as a syntax error; but this ensures
that we get a decent error if we get here anyway.
Updates #43680.
Change-Id: I93af43a5f5741d8bc76e7a13c0db75e6edf43111
Reviewed-on: https://go-review.googlesource.com/c/go/+/283475
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This patch pulls in a few additional changes requested by code
reviewers for CL 270863 that were accidentally left out. Specifically,
guarding use of ORETJMP to insure it is not used when building dynlink
on ppc64le, and a tweaking the command line flags used to control
wrapper generation.
Change-Id: I4f96462e570180887eb8693e11badd83d142710a
Reviewed-on: https://go-review.googlesource.com/c/go/+/279527
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Than McIntosh <thanm@google.com>
Consider the following example,
func test(a, b float64, x uint64) uint64 {
if a < b {
x = 0
}
return x
}
func main() {
fmt.Println(test(1, math.NaN(), 123))
}
The output is 0, but the expectation is 123.
This is because the rewrite rule
(CSEL [cc] (MOVDconst [0]) y flag) => (CSEL0 [arm64Negate(cc)] y flag)
converts
FCMP NaN, 1
CSEL MI, 0, 123, R0 // if 1 < NaN then R0 = 0 else R0 = 123
to
FCMP NaN, 1
CSEL GE, 123, 0, R0 // if 1 >= NaN then R0 = 123 else R0 = 0
But both 1 < NaN and 1 >= NaN are false. So the output is 0, not 123.
The root cause is arm64Negate not handle negation of floating comparison
correctly. According to the ARM manual, the meaning of MI, GE, and PL
are
MI: Less than
GE: Greater than or equal to
PL: Greater than, equal to, or unordered
Because NaN cannot be compared with other numbers, the result of such
comparison is unordered. So when NaN is involved, unlike integer, the
result of !(a < b) is not a >= b, it is a >= b || a is NaN || b is NaN.
This is exactly what PL means. We add NotLessThanF to represent PL. Then
the negation of LessThanF is NotLessThanF rather than GreaterEqualF. The
same reason for the other floating comparison operations.
Fixes#43619
Change-Id: Ia511b0027ad067436bace9fbfd261dbeaae01bcd
Reviewed-on: https://go-review.googlesource.com/c/go/+/283572
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Keith Randall <khr@golang.org>
Renamed setErrorPos to setPos, made it a method of PackageError,
and removed its Package parameter and return value. This makes it
more clear that setPos modifies PackageError and does not create a new
Package.
Change-Id: I26c58d3d456c7c18a5c2598e1e8e158b1e6b4b36
Reviewed-on: https://go-review.googlesource.com/c/go/+/283637
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This CL moves almost all PAUTOHEAP handling code to SSA construction.
Instead of changing Names to PAUTOHEAP, escape analysis now only sets
n.Esc() to ir.EscHeap, and SSA handles creating the "&x"
pseudo-variables and associating them via Heapaddr.
This CL also gets rid of n.Stackcopy, which was used to distinguish
the heap copy of a parameter used within a function from the stack
copy used in the function calling convention. In practice, this is
always obvious from context: liveness and function prologue/epilogue
want to know about the stack copies, and everywhere else wants the
heap copy.
Hopefully moving all parameter/result handling into SSA helps with
making the register ABI stuff easier.
Also, the only remaining uses of PAUTOHEAP are now for closure
variables, so I intend to rename it to PCLOSUREVAR or get rid of those
altogether too. But this CL is already big and scary enough.
Change-Id: Ief5ef6205041b9d0ee445314310c0c5a98187e77
Reviewed-on: https://go-review.googlesource.com/c/go/+/283233
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
Currently, there's an awkward issue with walk pass. When walking the AST
tree, the compiler generate code for runtime functions (using mkcall* variants),
add/modify the AST tree and walk new generated tree again. This causes the
double walking on some CallExpr, which is relying on checking Rargs to prevent
that. But checking Rargs has its own issue as well.
For functions that does not have arguments, this check is failed, and we
still double walk the CallExpr node.
This CL change the way that compiler detects double walking, by using
separated field instead of relying on Rargs. In perfect world, we should make
the compiler walks the AST tree just once, but it's not safe to do that at
this moment.
Passes toolstash -cmp.
Change-Id: Ifdd1e0f98940ddb1f574af2da2ac7f005b5fcadd
Reviewed-on: https://go-review.googlesource.com/c/go/+/283672
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This CL adds "irgen", a new noding implementation that utilizes types2
to guide IR construction. Notably, it completely skips dealing with
constant and type expressions (aside from using ir.TypeNode to
interoperate with the types1 typechecker), because types2 already
handled those. It also omits any syntax checking, trusting that types2
already rejected any errors.
It currently still utilizes the types1 typechecker for the desugaring
operations it handles (e.g., turning OAS2 into OAS2FUNC/etc, inserting
implicit conversions, rewriting f(g()) functions, and so on). However,
the IR is constructed in a fully incremental fashion, so it should be
easy to now piecemeal replace those dependencies as needed.
Nearly all of "go test std cmd" passes with -G=3 enabled by
default. The main remaining blocker is the number of test/run.go
failures. There also appear to be cases where types2 does not provide
us with position information. These will be iterated upon.
Portions and ideas from Dan Scales's CL 276653.
Change-Id: Ic99e8f2d0267b0312d30c10d5d043f5817a59c9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/281932
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
CL 278914 introduced NameOffsetExpr to avoid copying ONAME nodes and
hacking up their offsets, but evidently staticinit subtly depended on
the prior behavior to allow dynamic initialization of blank variables.
This CL refactors the code somewhat to avoid using NameOffsetExpr with
blank variables, and to instead create dynamic assignments directly to
the global blank node. It also adds a check to NewNameOffsetExpr to
guard against misuse like this, since I suspect there could be other
cases still lurking within staticinit. (This code is overdue for an
makeover anyway.)
Thanks to thanm@ for bisect and test case minimization.
Fixes#43677.
Change-Id: Ic71cb5d6698382feb9548dc3bb9fd606b207a172
Reviewed-on: https://go-review.googlesource.com/c/go/+/283537
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
When a command fails due to a module zip sum missing from go.sum,
if the module is in the build list, the go command will print a
'go mod download' command the user can run to fix it.
Previously, a hint was only printed if the module provided a package
in 'all'. We don't print a 'go get' hint, since we may not want to add
a new requirement to go.mod.
Fixes#43572
Change-Id: I88c61b1b42ad56c04e4482f6a1bb97ce758aaeff
Reviewed-on: https://go-review.googlesource.com/c/go/+/282712
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
I misread the FIXME comment in InitLSym the first time. It's referring
to how InitLSym is supposed to be called exactly once per
function (see function documentation), but this is evidently not
actually the case currently in GOEXPERIMENT=regabi mode.
So just move the NeedFuncSym call below the GOEXPERIMENT=regabi
workaround.
Also, to fix the linux-arm64-{aws,packet} builders, move the call to
reflectdata.WriteFuncSyms() to after the second batch of functions are
compiled. This is necessary to make sure we catch all the funcsyms
that can be added by late function compilation.
Change-Id: I6d6396d48e2ee29c1fb007fa2b99e065b36375db
Reviewed-on: https://go-review.googlesource.com/c/go/+/283552
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Needs to be visible to ssagen, and might as well start clean to avoid
creating a lot of accidental dependencies.
Added some methods for export.
Decided to use a pointer instead of value for ABIConfig uses.
Tests ended up separate from abiutil itself; otherwise there are import cycles.
Change-Id: I5570e1e6a463e303c5e2dc84e8dd4125e7c1adcc
Reviewed-on: https://go-review.googlesource.com/c/go/+/282614
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
This only works for functions; if you try it with a method, it will
fail. It does work for both local package and imports. For now,
it tells you when it thinks it sees either a declaration or a call of
such a function (this will normally be silent since no existing
code uses this pragma).
Note: it appears to be really darn hard to figure out if this
pragma was set for a method, and the method's call site. Better
ir.Node wranglers than I might be able to make headway, but it
seemed unnecessary for this experiment.
Change-Id: I601c2ddd124457bf6d62f714d7ac871705743c0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/279521
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
This is a selected copy from the register ABI experiment CL, focused
on the files and data structures that handle spilling around morestack.
Unnecessary code from the experiment was removed, other code was adapted.
Would it make sense to leave comments in the experiment as pieces are
brought over?
Experiment CL (for comparison purposes)
https://go-review.googlesource.com/c/go/+/28832
Change-Id: I92136f070351d4fcca1407b52ecf9b80898fed95
Reviewed-on: https://go-review.googlesource.com/c/go/+/279520
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Current many architectures use a rule along the lines of
// Canonicalize the order of arguments to comparisons - helps with CSE.
((CMP|CMPW) x y) && x.ID > y.ID => (InvertFlags ((CMP|CMPW) y x))
to normalize comparisons as much as possible for CSE. Replace the
ID comparison with something less variable across compiler changes.
This helps avoid spurious failures in some of the codegen-comparison
tests (though the current choice of comparison is sensitive to Op
ordering).
Two tests changed to accommodate modified instruction choice.
Change-Id: Ib35f450bd2bae9d4f9f7838ceaf7ec682bcf1e1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/280155
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The closure's type always matches the corresponding function's type,
so just use one instance rather than carrying around two. Simplifies
construction of closures, rewriting them during walk, and shrinks
memory usage.
Passes toolstash -cmp.
Change-Id: I83b8b8f435b02ab25a30fb7aa15d5ec7ad97189d
Reviewed-on: https://go-review.googlesource.com/c/go/+/283152
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
We used to transform directly called closures in a separate pass
before walk, because we couldn't guarantee whether we'd see the
closure call or the closure itself first. As of the last CL, this
ordering is always guaranteed, so we can rewrite calls and the closure
at the same time.
Change-Id: Ia6f4d504c24795e41500108589b53395d301123b
Reviewed-on: https://go-review.googlesource.com/c/go/+/283315
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
This CL reorders function compilation to ensure that functions are
always compiled before any enclosed function literals. The primary
goal of this is to reduce the risk of race conditions that arise due
to compilation of function literals needing to inspect data from their
closure variables. However, a pleasant side effect is that it allows
skipping the redundant, separate compilation of function literals that
were inlined into their enclosing function.
Change-Id: I03ee96212988cb578c2452162b7e99cc5e92918f
Reviewed-on: https://go-review.googlesource.com/c/go/+/282892
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
The compiler currently has two modes for compilation: one where it
compiles each function as it sees them, and another where it enqueues
them all into a work queue. A subsequent CL is going to reorder
function compilation to ensure that functions are always compiled
before any non-trivial function literals they enclose, and this will
be easier if we always use the compile work queue.
Also, fewer compilation modes makes things simpler to reason about.
Change-Id: Ie090e81f7476c49486296f2b90911fa0a466a5dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/283313
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
InitLSym is where we're now generating ABI wrappers, so it seems as
good a place as any to make sure we're generating the degenerate
closure wrappers for declared functions and methods.
Change-Id: I097f34bbcee65dee87a97f9ed6f3f38e4cf2e2b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/283312
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Historically, inline function bodies were exported as plain Go source
code, and symbol mangling was a convenient hack because it allowed
variables to be re-imported with largely the same names as they were
originally exported as.
However, nowadays we use a binary format that's more easily extended,
so we can simply serialize all of a function's declared objects up
front, and then refer to them by index later on. This also allows us
to easily report unmangled names all the time (e.g., error message
from issue7921.go).
Fixes#43633.
Change-Id: I46c88f5a47cb921f70ab140976ba9ddce38df216
Reviewed-on: https://go-review.googlesource.com/c/go/+/283193
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
This CL refactors noder's package import logic so it's easier to reuse
with types2 and gcimports. In particular, this allows the types2
integration to now support vendored packages.
Change-Id: I1fd98ad612b4683d2e1ac640839e64de1fa7324b
Reviewed-on: https://go-review.googlesource.com/c/go/+/282919
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
This CL extracts and simplifies noder's DWARF scope tracking code to
make it easier for reuse by irgen.
The previous code tried to be really clever about avoid recording
multiple scope boundaries at the same position (as happens at the end
of "if" and "for" statements). I had a really hard time remember how
this code worked exactly, so I've reimplemented a simpler algorithm
that just tracks all scope marks, and then compacts them at the end
before saving them to the ir.Func.
Passes toolstash -cmp.
Change-Id: Ibeb37997b77dc5179360d7db557c82ae1682e127
Reviewed-on: https://go-review.googlesource.com/c/go/+/282918
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Escape analysis needs to know the index of result parameters for
recording escape-flow information. It currently relies on Vargen for
this, but it can easily figure this out for itself. So just do that
instead, so that we can remove Vargen.
Passes toolstash -cmp.
For #43633.
Change-Id: I65dedc2d73bc25e85ff400f308e50b73dc503630
Reviewed-on: https://go-review.googlesource.com/c/go/+/283192
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
This CL adds an implementation of types2.Sizes that calculates sizes
using the same sizing algorithm as cmd/compile. In particular, it
matches how cmd/compile pads structures and includes padding in size
calculations.
Change-Id: I4dd8e51f95c90f9d7bd1e7463e40edcd3955a219
Reviewed-on: https://go-review.googlesource.com/c/go/+/282915
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This CL implements a number of minor fixes that were discovered in
getting -G=3 working for running all.bash.
1. Field tags were handled incorrectly. If a struct type had some
fields with tags, but later fields without tags, the trailing tag-less
fields would all copy the tag of the last tagged field. Fixed by
simply reinitializing `tag` to "" for each field visited.
2. Change the ending of switch case clause scopes from the end of the
last statement to the next "case" token or the switch-ending "}"
token. I don't think this is strictly necessary, but it matches my
intuition about where case-clause scopes end and cmd/compile's current
scoping logic (admittedly influenced by the former).
3. Change select statements to correctly use the scope of each
individual communication clause, instead of the scope of the entire
select statement. This issue appears to be due to the original
go/types code being written to rebind "s" from the *SelectStmt to the
Stmt in the range loop, and then being further asserted to "clause" of
type *CommClause. In most places within the loop body, "clause" was
used, but the rebound "s" identifier was used for the scope
boundaries.
However, in the syntax AST, SelectStmt directly contains a
[]*CommClause (rather than a *BlockStmt, with []Stmt), so no assertion
is necessary and instead of rebinding "s", the range loop was updated
to directly declare "clause".
4. The end position for increment/decrement statements (x++/x--) was
incorrectly calculated. Within the syntax AST, these are represented
as "x += ImplicitOne", and for AssignStmts types2 calculated the end
position as the end position of the RHS operand. But ImplicitOne
doesn't have any position information.
To workaround this, this CL detects ImplicitOne and then computes the
end position of the LHS operand instead, and then adds 2. In practice
this should be correct, though it could be wrong for ill-formatted
statements like "x ++".
Change-Id: I13d4830af39cb3f3b9f0d996672869d3db047ed2
Reviewed-on: https://go-review.googlesource.com/c/go/+/282914
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Walk already explicitly calculates the size of all expression types,
to make sure they're known before SSA generation (which is concurrent,
and thus not safe to modify shared state like types). Might as well
compute all local variable sizes too, to be consistent.
Reduces the burden of the frontend to make sure it's calculated the
size of types that only the backend cares about.
Passes toolstash -cmp.
Change-Id: I68bcca67b4640bfc875467e4ed4d47104b1932f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/282912
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Import logic for typechecking statements involving generics from the
dev.go2go branch. Notably, range type checking was simplified in
dev.go2go, resulting in the removal of the _InvalidChanRange error code.
Change-Id: I84c2665226c2b9b74e85f7fb6df257b0a292e5d3
Reviewed-on: https://go-review.googlesource.com/c/go/+/282120
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
This change imports assignments.go, builtins.go, call.go,
conversions.go, and expr.go from the dev.go2go branch.
Changes from dev.go2go:
- Update error positions and codes.
- Fix some failing tests due to error message changes.
- Fix a bug in exprInternal where normal IndexExpr checking wasn't
proceeding in the case of a non-generic indexed func.
- Fix the type of the second operand in commaerr expressions to be
universeError. We should add tests in a later CL.
This code was mostly reviewed, but call.go and expr.go were marked
incomplete. Additionally, these two files had notably diverged from
types2, requiring further understanding.
The dev.go2go branch significantly simplified the type checking of
arguments, resulting in the removal of the _InvalidDotDotDot operand
error code.
Change-Id: Iba2cef95e17bfaa6da6d4eb94c2e2ce1c691ac44
Reviewed-on: https://go-review.googlesource.com/c/go/+/282193
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
For some reason (that I didn't look into), externally linked
AIX binaries don't have runtime.symtab symbol. Since recent Go
releases (Go 1.3 maybe?), that symbol is empty and not necessary
anyway. Don't require it.
Fixes#40972.
Change-Id: I73a1f0142195ea6debdba8a4f6e12cadc3980dc5
Reviewed-on: https://go-review.googlesource.com/c/go/+/279995
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
For function literals that aren't inlined or directly called, we need
to pass their arguments via a closure struct. This also means we need
to rewrite uses of closure variables to access from this closure
struct.
Currently we do this rewrite in a pass before walking begins. This CL
moves the code to SSA construction instead, alongside binding other
input parameters.
Change-Id: I13538ef3394e2d6f75d5b7b2d0adbb00db812dc2
Reviewed-on: https://go-review.googlesource.com/c/go/+/281352
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Currently, during walk we rewrite PAUTOHEAP uses into derefs of their
corresponding Heapaddr, but we can easily do this instead during SSA
construction. This does involve updating two test cases:
* nilptr3.go
This file had a test that we emit a "removed nil check" diagnostic for
the implicit dereference from accessing a PAUTOHEAP variable. This CL
removes this diagnostic, since it's not really useful to end users:
from the user's point of view, there's no pointer anyway, so they
needn't care about whether we check for nil or not. That's a purely
internal detail. And with the PAUTOHEAP dereference handled during SSA
construction, we can more robustly ensure this happens, rather than
relying on setting a flag in walk and hoping that SSA sees it.
* issue20780.go
Previously, when PAUTOHEAPs were dereferenced during walk, it had a
consequence that when they're passed as a function call argument, they
would first get copied to the stack before being copied to their
actual destination. Moving the dereferencing to SSA had a side-effect
of eliminating this unnecessary temporary, and copying directly to the
destination parameter.
The test is updated to instead call "g(h(), h())" where h() returns a
large value, as the first result will always need to be spilled
somewhere will calling the second function. Maybe eventually we're
smart enough to realize it can be spilled to the heap, but we don't do
that today.
Because I'm concerned that the direct copy-to-parameter optimization
could interfere with race-detector instrumentation (e.g., maybe the
copies were previously necessary to ensure they're not clobbered by
inserted raceread calls?), I've also added issue20780b.go to exercise
this in a few different ways.
Change-Id: I720598cb32b17518bc10a03e555620c0f25fd28d
Reviewed-on: https://go-review.googlesource.com/c/go/+/281293
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
With the recent compiler rewrites and cleanups to gc/fmt.go, the
"safety net" provided by fmt_test has become less important and
the test itself has become a burden (often breaks because of small
format changes elsewhere).
Eventually, the syntax and types2 packages will provide most error
and diagnostic compiler output at which point fmt.go can be further
simplified as well.
Change-Id: Ie93eefd3e1166f3548fed0199b732dbd6c81948a
Reviewed-on: https://go-review.googlesource.com/c/go/+/282560
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Module-related help pages now contain a brief summary and point to the
reference documentation at golang.org/ref/mod for details.
Help pages for commands like 'go get' still describe the basic usage
and summarize flags but don't provide as much background detail.
Fixes#41427Fixes#43419
Change-Id: Icacd38e0f33c352c447cc5a496c99674493abde2
Reviewed-on: https://go-review.googlesource.com/c/go/+/282615
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
* All commands the user can run to fix the problem now appear alone on
a separate line after a tab.
* Removed -d from 'go get' commands.
* Replaced 'go mod tidy' with 'go mod download $modpath' when a
package might be provided by a module missing a sum.
* Errors about 'path@version' syntax are more explicit.
Fixes#29415Fixes#42087Fixes#43430Fixes#43523
Change-Id: I4427c2c4506a727a2c727d652fd2d506bb134d3b
Reviewed-on: https://go-review.googlesource.com/c/go/+/282121
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Previously, commands that wrote go.sum (except 'go mod tidy') would
retain sums for zip files of directly required modules. Sums of
indirect dependencies wouldn't be retained unless they were used to
load packages.
With this change, sums for indirect dependencies will be retained if
they're available. This allows users to add missing sums with
'go mod download example.com/mod', which previously only worked for
directly required modules.
Note that 'go mod download' without arguments now adds sums for every
module in the build list. That matches 1.15 behavior.
For #41103
Change-Id: I4cce2bf1c73578dae836bdb5adb32da071554f1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/282692
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This change removes the as-of-yet unused StopTheWorld field in the
Description struct. Adding a new field to a struct is much easier than
removing it, so let's save it for when we actually need it.
Change-Id: I8074b8569187c1a148500575fa8a661534e875d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/282632
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
This moves the Walk visitor from the types2 to the syntax
package. There are no changes but for package name adjustments.
Preparation for a more full-fledged node visitor.
Change-Id: I95217e27ff943ac58a7638fb8d1cd347d0d554b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/282556
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This CL moves the exprstring_test.go from the types2
package into the syntax package (which contains the
actual ShortString function). The code is mostly un-
changed but for the updated TestShortString function.
Change-Id: Ib39e3181e643fc0ac96ddf144a3114893a50c2fc
Reviewed-on: https://go-review.googlesource.com/c/go/+/282554
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The syntax package has a full-fledged node printer. Use that printer
to create the expression strings needed in error messages, and remove
the local (essentially) duplicate code for creating expression strings.
Change-Id: I03673e5e79b3c1470f8073ebbe840a90fd9053ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/282553
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Preparation for using the syntax printer as expression printer in types2.
- Introduced Form to control printing format
- Cleaned up/added String and ShortString convenience functions
- Implemented ShortForm format which prints … for non-empty
function and composite literal bodies
- Added test to check write error handling
Change-Id: Ie86e46d766fb60fcf07ef643c7788b2ef440ffa8
Reviewed-on: https://go-review.googlesource.com/c/go/+/282552
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
I have a real 7,000-line Go program (not so big)
that took over two minutes to report a trivial init cycle.
I thought the compiler was in an infinite loop but
it was actually just very slow.
CL 170062 rewrote init cycle reporting but replaced
a linear-time algorithm with an exponential one:
it explores all paths through the call graph of functions
involved in the cycle.
The net effect was that Go 1.12 took 0.25 seconds to load,
typecheck, and then diagnose the cycle in my program,
while Go 1.13 takes 600X longer.
This CL makes the new reporting code run in linear time,
restoring the speed of Go 1.12 but preserving the semantic
fixes from CL 170062.
Change-Id: I7d6dc95676d577d9b96f5953b516a64db93249bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/282314
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
When running go tool compile,
go tool is running compile as a subprocess.
Killing go tool with Process.Kill leaves the subprocess behind.
Send an interrupt signal first, which it can forward on
to the compile subprocess.
Also report the timeout in errorcheck -t.
Change-Id: I7ae0029bbe543ed7e60e0fea790dd0739d10bcaa
Reviewed-on: https://go-review.googlesource.com/c/go/+/282313
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This way, if a SIGINT is sent to the go command,
it is forwarded on to the underlying tool.
Otherwise trying to use os.Process.Signal to kill
"go tool compile" only kills the "go tool" not the "compile".
Change-Id: Iac7cd4f06096469f5e76164df813a379c0da3822
Reviewed-on: https://go-review.googlesource.com/c/go/+/282312
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This package implements a parser for the new //go:build constraint lines.
The parser also handles // +build lines, to be able to process legacy files.
This will not be used in the standard library until Go 1.17,
but it seems worth publishing in Go 1.16 so that code that
needs to process both kinds of lines once Go 1.17 comes out
will be able to build using Go 1.16 as well.
For #41184. Design in https://golang.org/design/draft-gobuild.
Change-Id: I756c0de4081c5039e8b7397200e5274f223ab111
Reviewed-on: https://go-review.googlesource.com/c/go/+/240604
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Russ Cox <rsc@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The testing.TestFS function assumes that the file system it's testing
doesn't change under it. Clarify this in the documentation and fix the
use of os.TestDirFS that's currently susceptible to this race.
Fixes#42637.
Change-Id: Ia7792380726177f8953d150ee87381b66cb01cb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/282452
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This change modifies the *-by-size metrics' units to be based off the
bucket's unit (bytes) as opposed to the unit of the counts (objects).
This convention is more in-line with distributions in other metrics
systems.
Change-Id: Id3b68a09f52f0e1ff9f4346f613ae1cbd9f52f73
Reviewed-on: https://go-review.googlesource.com/c/go/+/282352
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
The documentation for Glob was copied from filepath.Glob, and needs a bit
of tweaking: paths are not rooted at slash; the separator is always '/'.
Fixes#43537
Change-Id: Id64daa137e2762b66a82a5b9e60bbe603f4e2f5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/282173
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Current optimization: When we copy a->b and then b->c, we might as well
copy a->c instead of b->c (then b might be dead and go away).
*Except* if a is a volatile location (might be clobbered by a call).
In that case, we really do want to copy a immediately, because there
might be a call before we can do the a->c copy.
User calls can't happen in between, because the rule matches up the
memory states. But calls inserted for memory barriers, particularly
runtime.typedmemmove, can.
(I guess we could introduce a register-calling-convention version
of runtime.typedmemmove, but that seems a bigger change than this one.)
Fixes#43570
Change-Id: Ifa518bb1a6f3a8dd46c352d4fd54ea9713b3eb1a
Reviewed-on: https://go-review.googlesource.com/c/go/+/282492
Trust: Keith Randall <khr@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
This change modifies the semantics of
runtime/metrics.Float64Histogram.Buckets to remove implicit buckets to
that extend to positive and negative infinity and instead defines all
bucket boundaries as explicitly listed.
Bucket boundaries remain the same as before except
/gc/heap/allocs-by-size:objects and /gc/heap/frees-by-size:objects no
longer have a bucket that extends to negative infinity.
This change simplifies the Float64Histogram API, making it both easier
to understand and easier to use.
Also, add a test for allocs-by-size and frees-by-size that checks them
against MemStats.
Fixes#43443.
Change-Id: I5620f15bd084562dadf288f733c4a8cace21910c
Reviewed-on: https://go-review.googlesource.com/c/go/+/281238
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
golang.org/cl/251878 disallowed non-ASCII characters in import paths,
in module mode. They were already disallowed in module paths, so this
change just extended the restriction to the package subdirectory of
the module. Update the release notes to alert users of this change.
Fixes#43052
Change-Id: I1caf9ef978dd3ac599a3f82c5c376ad62e6fc436
Reviewed-on: https://go-review.googlesource.com/c/go/+/282194
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
For the example in #43551, before late call expansion, the OpArg type is
decomposed to int64. But the late call expansion is currently decompose
it to "x.Key" instead.
This CL make expand_calls decompose further for struct { 1-field type }
and array [1]elem.
This matches the previous rules for early decompose args:
(StructSelect (StructMake1 x)) => x
(ArraySelect (ArrayMake1 x)) => x
Fixes#43551
Change-Id: I2f1ebe18cb81cb967f494331c3d237535d2859e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/282332
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
In general, we don't want to encourage reading them from CSRs, and
applications that really want to can parse the Extensions field.
Note that this also fixes a bug where the error of
parseKeyUsageExtension was not handled in parseCertificateRequest.
Fixes#43477
Updates #37172
Change-Id: Ia5707b0e23cecc0aed57e419a1ca25e26eea6bbe
Reviewed-on: https://go-review.googlesource.com/c/go/+/281235
Trust: Filippo Valsorda <filippo@golang.org>
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
Changes from dev.go2go (compare with patchset 1):
+ Update stale comments.
+ Fix a bug in structType where check.atEnd closed over the loop
variable, resulting in incorrect error positions.
+ Fix a bug in the CallExpr clause of typInternal where it didn't check
e.Brackets before checking instantiatedType.
+ Remove support for parenthesized embedded type names.
+ Add an IndexExpr clause to embeddedFieldIdent.
+ Lift the substMap construction out of the loop in funcType when
substituting receiver type parameters.
+ Minor simplification in collectTypeConstraints.
Compare with patchset 1 to see these changes.
Change-Id: I24f10e8615a0bbcd56c86ecf3490ce6a99cfebd6
Reviewed-on: https://go-review.googlesource.com/c/go/+/278916
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
Earlier (contract-based) versions of the generics design restricted the
kind of types that could be used in a type list - the current design does
not have these restrictions anymore. Remove the respective checking code.
Change-Id: Ia333f7aa8a9c31a92c08acbd5cadba3532a455b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/281546
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This code matches go/types/typexpr but for the necessary adjustments
because of the use of package syntax rather than go/ast, and for the
code being part of cmd/compile/internal/types2 rather than go/types.
Primary differences to go.types/typexpr.go:
- syntax.FuncType doesn't carry type parameters
- type instantiations are represented using syntax.IndexExpr
nodes
- there's an explicit syntax.SliceType
- *x is expressed as a unary operation, not a StarExpr
- grouped fields are identified by identical pointer types
To see the changes copied from recent go/types changes, compare Patchsets 1 and 2.
Change-Id: I8aa9452882d1f5e9529c52a30c7c8e65f3fcbb43
Reviewed-on: https://go-review.googlesource.com/c/go/+/281545
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Fix a deadlock in DumpRequestOut which can occur if the request is
cancelled between response being sent and it being processed.
Also:
* Ensure we don't get a reader leak when an error is reported by the
transport before the body is consumed.
* Add leaked goroutine retries to avoid false test failures.
Fixes#38352
Change-Id: I83710791b2985b997f61fe5b49eadee0bb51bdee
Reviewed-on: https://go-review.googlesource.com/c/go/+/232798
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Damien Neil <dneil@google.com>
modload.Init now sets the default value for -mod if it wasn't set
explicitly. This happens before go.mod is loaded, so
modload.LoadModFile sets the default value again in order to enable
automatic vendoring.
Previously, cfg.BuildMod wasn't set at all if LoadModFile wasn't
called, as is the case for commands that run outside of a module
root. This problem only affected 'go install pkg@version' since other
commands are either forbidden in module mode or run with -mod=mod
(like 'go get' and 'go mod' subcommands).
This change also suppresses "missing sum" errors when -mod=readonly is
enabled and there is no module root.
Fixes#43278
Related #40278
Change-Id: I6071cc42bc5e24d0d7e84556e5bfd8e368e0019d
Reviewed-on: https://go-review.googlesource.com/c/go/+/279490
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Currently we rely on the type-checker to do some basic data-flow
analysis to help decide whether function literals should capture
variables by value or reference. However, this analysis isn't done by
go/types, and escape analysis already has a better framework for doing
this more precisely.
This CL extends escape analysis to recalculate the same "byval" as
CaptureVars and check that it matches. A future CL will remove
CaptureVars in favor of escape analysis's calculation.
Notably, escape analysis happens after deadcode removes obviously
unreachable code, so it sees the AST without any unreachable
assignments. (Also without unreachable addrtakens, but
ComputeAddrtaken already happens after deadcode too.) There are two
test cases where a variable is only reassigned on certain CPUs. This
CL changes them to reassign the variables unconditionally (as no-op
reassignments that avoid triggering cmd/vet's self-assignment check),
at least until we remove CaptureVars.
Passes toolstash -cmp.
Change-Id: I7162619739fedaf861b478fb8d506f96a6ac21f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/281535
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The backend doesn't synchronize compilation of functions with their
enclosed function literals, so it's not safe to double-check that
IsClosureVar isn't set on the underlying Name. Plenty of frontend
stuff would blow-up if this was wrong anyway, so it should be fine to
omit.
Change-Id: I3e97b64051fe56d97bf316c9b5dcce61f2082428
Reviewed-on: https://go-review.googlesource.com/c/go/+/281812
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
tracebackothers is called from fatal throw/panic.
A fatal throw may be taken with allglock held (notably in the allocator
when allglock is held), which would cause a deadlock in tracebackothers
when we try to take allglock again. Locking allglock here is also often
a lock order violation w.r.t. the locks held when throw was called.
Avoid the deadlock and ordering issues by skipping locking altogether.
It is OK to miss concurrently created Gs (which are generally avoided by
freezetheworld(), and which were possible previously anyways if created
after the loop).
Fatal throw/panic freezetheworld(), which should freeze other threads
that may be racing to modify allgs. However, freezetheworld() does _not_
guarantee that it stops all other threads, so we can't simply drop the
lock.
Fixes#42669
Updates #43175
Change-Id: I657aec46ed35fd5d1b3f1ba25b500128ab26b088
Reviewed-on: https://go-review.googlesource.com/c/go/+/270861
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Michael Pratt <mpratt@google.com>
There's a bunch of code that wants to map closure variables back to
their original name, so add a single Name.Canonical method that they
can all use.
Also, move the Byval flag from being stored on individual closure
variables to being stored on the canonical variable.
Passes toolstash -cmp.
Change-Id: Ia3ef81af5a15783d09f04b4e274ce33df94518e6
Reviewed-on: https://go-review.googlesource.com/c/go/+/281541
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
ir.StaticValue currently relies on CaptureVars setting Addrtaken for
variables that are assigned within nested function literals. We want
to move that logic to escape analysis, but ir.StaticValue is used in
inlining and devirtualization, which happen before escape
analysis.
The long-term solution here is to generalize escape analysis's precise
reassignment tracking for use by other optimization passes, but for
now we just generalize ir.StaticValue to not depend on Addrtaken
anymore. Instead, it now also pays attention to OADDR nodes as well as
recurses into OCLOSURE bodies.
Passes toolstash -cmp.
Change-Id: I6114e3277fb70b235f4423d2983d0433c881f79f
Reviewed-on: https://go-review.googlesource.com/c/go/+/281540
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
For OINDEX expressions, ir.OuterValue depends on knowing the indexee's
type. Rather than silently acting as though it's not an array, make it
loudly fail.
The only code that needs to be fixed to support this is checkassign
during typechecking, which needs to avoid calling ir.OuterValue now if
typechecking the assigned operand already failed.
Passes toolstash -cmp.
Change-Id: I935cae0dacc837202bc6b63164dc2f0a6fde005c
Reviewed-on: https://go-review.googlesource.com/c/go/+/281539
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
CaptureVars is responsible for deciding whether free variables should
be captured by value or by reference, but currently it also makes up
for some of the short-comings of the frontend symbol resolution /
type-checking algorithms. These are really separate responsibilities,
so move the latter into type-checking where it fits better.
Passes toolstash -cmp.
Change-Id: Iffbd53e83846a9ca9dfb54b597450b8543252850
Reviewed-on: https://go-review.googlesource.com/c/go/+/281534
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Dump uses reflection to print IR nodes, and it only knew how to print
out the Nodes slice type itself. This CL adds support for printing any
slice whose element type implements Node, such as SwitchStmt and
SelectStmt's clause lists.
Change-Id: I2fd8defe11868b564d1d389ea3cd9b8abcefac62
Reviewed-on: https://go-review.googlesource.com/c/go/+/281537
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
These aren't part of the Node interface anymore, so no need to keep
them around.
Passes toolstash -cmp.
[git-generate]
cd src/cmd/compile/internal/ir
: Fix one off case that causes trouble for rf.
sed -i -e 's/n.SetClass(ir.PAUTO)/n.Class_ = ir.PAUTO/' ../ssa/export_test.go
pkgs=$(go list . ../...)
rf '
ex '"$(echo $pkgs)"' {
var n *Name
var c Class
n.Class() -> n.Class_
n.SetClass(c) -> n.Class_ = c
}
rm Name.Class
rm Name.SetClass
mv Name.Class_ Name.Class
'
Change-Id: Ifb304bf4691a8c455456aabd8aa77178d4a49500
Reviewed-on: https://go-review.googlesource.com/c/go/+/281294
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
When exporting signature types, we include the originating package,
because it's exposed via go/types's API. And as a consistency check,
we ensure that the parameter names came from that same package.
However, we were getting this wrong in the case of exported variables
that were initialized with a method value using an imported method. In
this case, when we created the method value wrapper function's
type (which is reused as the variable's type if none is explicitly
provided in the variable declaration), we were reusing the
original (i.e., imported) parameter names, but the newly created
signature type was associated with the current package instead.
The correct fix here is really to preserve the original signature
type's package (along with position and name for its parameters), but
that's awkward to do at the moment because the DeclFunc API requires
an ir representation of the function signature, whereas we only
provide a way to explicitly set packages via the type constructor
APIs.
As an interim fix, we associate the parameters with the current
package, to be consistent with the signature type's package.
Fixes#43479.
Change-Id: Id45a10f8cf64165c9bc7d9598f0a0ee199a5e752
Reviewed-on: https://go-review.googlesource.com/c/go/+/281292
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
It's an error to call Int64Val on constants that don't fit into
int64. CL 272654 made the compiler stricter about detecting misuse,
and revealed that we were using it improperly in detecting consecutive
integer-switch cases. That particular usage actually did work in
practice, but it's easy and best to just fix it.
Fixes#43480.
Change-Id: I56f722d75e83091638ac43b80e45df0b0ad7d48d
Reviewed-on: https://go-review.googlesource.com/c/go/+/281272
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
In inl.go, that code path is unused, since we added ir.BasicLit to
represent unnamed OLITERALs.
In race.go, rather than cloning ir.RegFP, we can just create it from
scratch again.
Passes toolstash -cmp (incl. w/ -race).
Change-Id: I8e063e4898d2acf056ceca5bc03df6b40a14eca9
Reviewed-on: https://go-review.googlesource.com/c/go/+/281192
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
After the previous cleanup/optimization CLs, ascompatee now correctly
handles map assignments too. So remove the code from order.mapAssign,
which causes us to assign to the map at the wrong point during
execution. It's not every day you get to fix an issue by only removing
code.
Thanks to Cuong Manh Le for test cases and continually following up on
this issue.
Passes toolstash -cmp. (Apparently the standard library never uses
tricky map assignments. Go figure.)
Fixes#23017.
Change-Id: Ie0728103d59d884d00c1c050251290a2a46150f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/281172
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Instead of evaluating all result expressions up front and then
assigning them to their result destinations, we can interleave
evaluation with assignment. This reduces how much temporary
stack/register space is needed to hold the values in flight.
Doesn't pass toolstash -cmp, because it allows better return statement
code to be generated. E.g., cmd/go's text segment on linux/ppc64le
shrinks another 1kB.
Change-Id: I3fe889342c80e947e0118704ec01f1682c577e6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/281153
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
order.go has already ordered function calls, so ascompatee only needs
to worry about expressions that might access a variable after it's
already been re-assigned. It already handles this, so the safeExpr
calls simply result in unnecessarily pessimistic code.
Does not pass toolstash -cmp, because it allows more efficient code
generation. E.g., cmd/go on linux/ppc64le is about 2kB smaller.
Change-Id: Idde0588eabe7850fa13c4e281fc46bbeffb4f68c
Reviewed-on: https://go-review.googlesource.com/c/go/+/281152
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
After the previous commit, we no longer access Walkdef on anything but
ir.Names, so we can remove them from the Node interface and miniNode.
The flag bits storage should also move from miniNode.bits to
Name.flags, but the latter is already full at the moment. Leaving as a
TODO for now.
Passes toolstash -cmp.
Change-Id: I2427e4cf7bc68dc1d1529f40fb93dd9f7a9149f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/281005
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
We only actually care about ir.Names in typecheckdef, so don't bother
calling it on anything else. Allows us to get rid of some more
superfluous .Name() calls and .(*ir.Name) assertions.
Passes toolstash -cmp.
Change-Id: I78c7cb680178991ea185958b47a36f101d4d5ef7
Reviewed-on: https://go-review.googlesource.com/c/go/+/281004
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
To do closure conversion during escape analysis, we need to walk the
AST in order. So this CL makes a few changes:
1. Function literals are walked where they appear in their enclosing
function, rather than as independent functions.
2. Walking "range" and "switch" statements is reordered to visit the
X/Tag expression up front, before the body.
3. Most assignments are refactored to use a new assignList helper,
which handles 1:1, 2:1, and N:N assignments. N:1 function call
assignments are still handled directly by the OAS2FUNC case.
4. A latent missed-optimization in escape.addr is fixed: the
ONAMEOFFSET case was failing to update k with the result of calling
e.addr(n.Name_). In partice, this probably wasn't an issue because
ONAMEOFFSET is likely only used for PEXTERN variables (which are
treated as heap memory anyway) or code generated by walk (which has
already gone through escape analysis).
5. Finally, don't replace k with discardHole at the end of
escape.addr. This is already handled at the start of escape.expr, and
we'll want to be able to access the hole's location after escape.expr
returns.
Passes toolstash -cmp.
Change-Id: I2325234346b12b10056a360c489692bab8fdbd93
Reviewed-on: https://go-review.googlesource.com/c/go/+/281003
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Just "=". It's cleaner.
Passes toolstash -cmp.
[git-generate]
cd src/cmd/compile/internal/ir
pkgs=$(go list . ../...)
rf '
ex '"$(echo $pkgs)"' {
var l Nodes
var p *Nodes
p.Set(l) -> *p = l
}
ex '"$(echo $pkgs)"' {
var n InitNode
var l Nodes
*n.PtrInit() = l -> n.SetInit(l)
}
rm Nodes.Set
'
Change-Id: Ic97219792243667146a02776553942ae1189ff7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/281002
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
This CL separates out PtrInit and SetInit into a new InitNode
extension interface, and adds a new TakeInit helper function for
taking and clearing the Init list (if any) from a Node.
This allows removing miniNode.SetInit and miniNode.PtrInit, which in
turn allow getting rid of immutableEmptyNodes, and will allow
simplification of the Nodes API.
It would be nice to get rid of the default Init method too, but
there's way more code that expects to be able to call that at the
moment, so that'll have to wait.
Passes toolstash -cmp.
Change-Id: Ia8c18fab9555b774376f7f43eeecfde4f07b5946
Reviewed-on: https://go-review.googlesource.com/c/go/+/281001
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
When deciding whether a captured variable can be passed by value, the
compiler is sensitive to the order that the OCLOSURE node is
typechecked relative to the order that the variable is passed to
"checkassign". Today, for an assignment like:
q, g = 2, func() int { return q }
we get this right because we always typecheck the full RHS expression
list before calling checkassign on any LHS expression.
But I nearly made a change that would interleave this ordering,
causing us to call checkassign on q before typechecking the function
literal. And alarmingly, there weren't any tests that caught this.
So this commit adds one.
Change-Id: I66cacd61066c7a229070861a7d973bcc434904cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/280998
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
In a future CL, I plan to change escape analysis to walk function
literal bodies at the point they appear within the AST, rather than
separately as their own standalone function declaration. This means
escape analysis's AST-walking code will become reentrant.
To make this easier to get right, this CL splits escape analysis's
state into two separate types: one that holds all of the state shared
across the entire batch, and another that holds only the state that's
used within initFunc and walkFunc.
Incidentally, this CL reveals that a bunch of logopt code was using
e.curfn outside of the AST-walking code paths where it's actually set,
so it was always nil. That code is in need of refactoring anyway, so
I'll come back and figure out the correct values to pass later when I
address that.
Passes toolstash -cmp.
Change-Id: I1d13f47d06f7583401afa1b53fcc5ee2adaea6c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/280997
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Closures have their own ONAMEs for captured variables, which their
function bodies refer to. So during inlining, we need to account for
this and ensure the references still work.
The previous inlining handled this by actually declaring the variables
and then either copying the original value or creating a pointer to
them, as appropriate for variables captured by value or by reference.
But this is needlessly complicated. When inlining the function body,
we need to rewrite all variable references anyway. We can just detect
closure variables and change them to directly point to the enclosing
function's version of this variable. No need for copying or further
indirection.
Does not pass toolstash -cmp. Presumably because we're able to
generate better code in some circumstances.
Change-Id: I8f0ccf7b098f39b8cd33f3bcefb875c8132d2c62
Reviewed-on: https://go-review.googlesource.com/c/go/+/280996
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
The previous code was way overcomplicating things. To find out if a
variable is a closure pseudo-variable, one only needs to check
IsClosureVar. Checking Captured and Byval are only meant to be used by
closure conversion.
Passes toolstash -cmp.
Change-Id: I22622cba36ba7f60b3275d17999a8b6bb7c6719a
Reviewed-on: https://go-review.googlesource.com/c/go/+/280995
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
This CL moves the general deadcode-removal pass to before computing
Addrtaken, which allows variables to still be converted to SSA if
their address is only taken in unreachable code paths (e.g., the "&mp"
expression in the "if false" block in runtime/os_linux.go:newosproc).
This doesn't pass toolstash -cmp, because it allows SSA to better
optimize some code.
Change-Id: I43e54acc02fdcbad8eb6493283f355aa1ee0de84
Reviewed-on: https://go-review.googlesource.com/c/go/+/280992
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
This CL fixes package initialization order by creating the init task
before the general deadcode-removal pass.
It also changes noder to emit zero-initialization assignments (i.e.,
OAS with nil RHS) for package-block variables, so that initOrder can
tell the variables still need initialization. To allow this, we need
to also extend the static-init code to recognize zero-initialization
assignments.
This doesn't pass toolstash -cmp, because it reorders some package
initialization routines.
Fixes#43444.
Change-Id: I0da7996a62c85e15e97ce965298127e075390a7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/280976
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
This commit splits up typecheck.Package and moves the code
elsewhere. The type-checking code is moved into noder, so that it can
eventually be interleaved with the noding process. The
non-type-checking code is moved back into package gc, so that it can
be incorporated into appropriate compiler backend phases.
While here, deadcode removal is moved into its own package.
Passes toolstash -cmp.
[git-generate]
cd src/cmd/compile/internal/typecheck
: Split into two functions.
sed -i -e '/Phase 6/i}\n\nfunc postTypecheck() {' typecheck.go
rf '
# Export needed identifiers.
mv deadcode Deadcode
mv loadsys InitRuntime
mv declareUniverse DeclareUniverse
mv dirtyAddrtaken DirtyAddrtaken
mv computeAddrtaken ComputeAddrtaken
mv incrementalAddrtaken IncrementalAddrtaken
# Move into new package.
mv Deadcode deadcodeslice deadcodeexpr deadcode.go
mv deadcode.go cmd/compile/internal/deadcode
# Move top-level type-checking code into noder.
# Move DeclVars there too, now that nothing else uses it.
mv DeclVars Package noder.go
mv noder.go cmd/compile/internal/noder
# Move non-type-checking code back into gc.
mv postTypecheck main.go
mv main.go cmd/compile/internal/gc
'
cd ../deadcode
rf '
# Destutter names.
mv Deadcode Func
mv deadcodeslice stmts
mv deadcodeexpr expr
'
cd ../noder
rf '
# Move functions up, next to their related code.
mv noder.go:/func Package/-1,$ \
noder.go:/makeSrcPosBase translates/-1
mv noder.go:/func DeclVars/-3,$ \
noder.go:/constState tracks/-1
'
cd ../gc
rf '
# Inline postTypecheck code back into gc.Main.
mv main.go:/func postTypecheck/+0,/AllImportedBodies/+1 \
main.go:/Build init task/-1
rm postTypecheck
'
Change-Id: Ie5e992ece4a42204cce6aa98dd6eb52112d098c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/280974
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Unused variables are a type-checking error, so they should be reported
during typecheck rather than walk.
One catch is that we only want to report unused-variable errors for
functions that type check successfully, but some errors are reported
during noding, so we don't have an easy way to detect that
currently. As an approximate solution, we simply check if we've
reported any errors yet.
Passes toolstash -cmp.
Change-Id: I9400bfc94312c71d0c908a491e85c16d62224c9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/280973
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Back to pre Russquake, Node.Nbody of OCALL* node is used to attach
variables which must be kept alive during that call.
Now after Russquake, we have CallExpr to represent a function call,
so use a dedicated field for those variables instead.
Passes toolstash -cmp.
Change-Id: I4f40ebefcc7c41cdcc4e29c7a6d8496a083b68f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/280733
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
OTYPE and OMETHEXPR were missing from OpPrec. So add them with the
same precedences as OT{ARRAY,MAP,STRUCT,etc} and
ODOT{,METH,INTER,etc}, respectively. However, ODEREF (which is also
used for pointer types *T) has a lower precedence than other types, so
pointer types need to be specially handled to assign them their
correct, lower precedence.
Incidentally, this also improves the error messages in issue15055.go,
where we were adding unnecessary parentheses around the types in
conversion expressions.
Thanks to Cuong Manh Le for writing the test cases for #43428.
Fixes#43428.
Change-Id: I57e7979babe3ed9ef8a8b5a2a3745e3737dd785f
Reviewed-on: https://go-review.googlesource.com/c/go/+/280873
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
It isn't necessary on darwin/arm64 (macOS).
It was probably leftover from the old code when darwin/arm64
meant iOS. The test passes on iOS builder. Apparently this is
not needed either. Remove.
Change-Id: I6fa0c55d6086325d4b722862c4fe6c30bcd6e6e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/280158
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The compiler has logic to check whether we implicitly dereferenced a
defined pointer while trying to select a method. However, rather than
checking whether there were any implicit dereferences of a defined
pointer, it was finding the innermost dereference/selector expression
and checking whether that was dereferencing a named pointer. Moreover,
it was only checking defined pointer declared in the package block.
This CL restructures the code to match go/types and gccgo's behavior.
Fixes#43384.
Change-Id: I7bddfe2515776d9480eb2c7286023d4c15423888
Reviewed-on: https://go-review.googlesource.com/c/go/+/280392
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
After using the IR visitor code for a bit, it seems clear that a
simple boolean result type is adequate for tree traversals. This CL
updates ir.DoChildren to use the same calling convention as ir.Any,
and updates mknode.go to generate code accordingly.
There were only two places where the error-based DoChildren API was
used within the compiler:
1. Within typechecking, marking statements that contain "break". This
code never returns errors anyway, so it's trivially updated to return
false instead.
2. Within inlining, the "hairy visitor" actually does make use of
returning errors. However, it threads through a reference to the
hairyVisitor anyway, where it would be trivial to store any needed
information instead. For the purpose of this CL, we provide
"errChildren" and "errList" helper functions that provide the previous
error-based semantics on top of the new bool-based API.
Passes toolstash -cmp.
Change-Id: I4bac9a697b4dbfb5f66eeac37d4a2ced2073d7d0
Reviewed-on: https://go-review.googlesource.com/c/go/+/280675
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
This CL generalizes ir/mknode.go to get rid of most of almost all of
its special cases for node field types. The only remaining speciale
case now is Field, which doesn't implement Node any more, but perhaps
should.
To help with removing special cases, node fields can now be tagged
with `mknode:"-"` so that mknode ignores them when generating its
helper methods. Further, to simplify skipping all of the orig fields,
a new origNode helper type is added which declares an orig field
marked as `mknode:"-"` and also provides the Orig and SetOrig methods
needed to implement the OrigNode interface.
Passes toolstash -cmp.
Change-Id: Ic68d4f0a9d2ef6e57e9fe87cdc641e5c4859830b
Reviewed-on: https://go-review.googlesource.com/c/go/+/280674
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Two simplifications:
1. Statements (including ODCLFUNC) don't have types, and the
Func.Nname already has a type. There's no need for a second one.
However, there is a lot of code that expects to be able to call
Func.Type, so leave a forwarding method, like with Sym and Linksym.
2. Inline and remove ir.NewFuncNameAt. It doesn't really save any
code, and it's only used a handful of places.
Passes toolstash -cmp.
Change-Id: I51acaa341897dae0fcdf2fa576a10174a2ae4d1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/280648
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Currently, the tcArith logic is complicated and involes many
un-necessary checks for some ir.Op. This CL refactors how it works:
- Add a new tcShiftOp function, which only does necessary works for
typechecking OLSH/ORSH. That ends up moving OLSH/ORSH to a separated
case in typecheck1.
- Move OASOP to separated case, so its logic is detached from tcArith.
- Move OANDAND/OOROR to separated case, which does some validation
dedicated to logical operators only.
Passes toolstash -cmp.
Change-Id: I0db7b7c7a3e52d6f9e9d87eee6967871f1c32200
Reviewed-on: https://go-review.googlesource.com/c/go/+/279442
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Syms are meant to be just interned (pkg, name) tuples, and are a
purely abstract, Go-language concept. As such, associating them with
linker symbols (a low-level, implementation-oriented detail) is
inappropriate.
There's still work to be done before linker symbols can be directly
attached to their appropriate, higher-level objects instead. But in
the mean-time, we can at least add helper functions and discourage
folks from using Sym.Linksym directly. The next CL will mechanically
rewrite code to use these helpers where possible.
Passes toolstash -cmp.
Change-Id: I413bd1c80bce056304f9a7343526bd153f2b9c7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/280639
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Escape analysis uses Node.Opt to map nodes to their "location", so
that other references to the same node use the same location
again. But in the current implementation of escape analysis, we never
need to refer back to a node's location except for named nodes (since
other nodes are anonymous, and have no way to be referenced).
This CL moves Opt from Node down to Name, turns it into a directly
accessed field, and cleans up escape analysis to avoid setting Opt on
non-named expressions.
One nit: in walkCheckPtrArithmetic, we were abusing Opt as a way to
detect/prevent loops. This CL adds a CheckPtr bit flag instead.
Passes toolstash -cmp.
Change-Id: If57d5ad8d972fa63bedbe69b9ebb6753e31aba85
Reviewed-on: https://go-review.googlesource.com/c/go/+/280638
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Previously, ODOTTYPE/ODOTTYPE2 were forced to reuse some available
Node fields for storing pointers to runtime type descriptors. This
resulted in awkward field types for TypeAssertExpr and AddrExpr.
This CL gives TypeAssertExpr proper fields for the runtime type
descriptors, and also tightens the field types as
possible/appropriate.
Passes toolstash -cmp.
Change-Id: I521ee7a1462affc5459de33a0de6c68a7d6416ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/280637
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
These three expression nodes all represent the same syntax, and so
they're represented the same within types2. And also they're not
handled that meaningfully differently throughout the rest of the
compiler to merit unique representations.
Method expressions are somewhat unique today that they're very
frequently turned into plain function names. But eventually that can
be handled by a post-typecheck desugaring phase that reduces the
number of redundant AST forms.
Passes toolstash -cmp.
Change-Id: I20df91bbd0d885c1f18ec67feb61ae1558670719
Reviewed-on: https://go-review.googlesource.com/c/go/+/280636
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
During recent refactoring, we moved mkbuiltin.go to package typecheck,
but accidentally duplicated its //go:generate directive into a bunch
of other files/directories. This CL cleans up the unnecessary
duplicates.
Also, update all of the stringer invocations to use an explicit file
name, and regenerate their files.
Updates #43369.
Change-Id: I4e493c1fff103d742de0a839d7a3375659270b50
Reviewed-on: https://go-review.googlesource.com/c/go/+/280635
Trust: Matthew Dempsky <mdempsky@google.com>
Trust: Meng Zhuo <mzh@golangcn.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Meng Zhuo <mzh@golangcn.org>
Merge List:
+ 2020-12-26 1d78139128 runtime/cgo: fix Android build with NDK 22
+ 2020-12-25 2018b68a65 net/mail: don't use MDT in test
+ 2020-12-23 b116404444 runtime: shift timeHistogram buckets and allow negative durations
+ 2020-12-23 8db7e2fecd runtime: fix allocs-by-size and frees-by-size buckets
+ 2020-12-23 fb96f07e1a runtime: fix nStackRoots comment about stack roots
+ 2020-12-23 d1502b3c72 lib/time, time/tzdata: update tzdata to 2020e
+ 2020-12-23 30c99cbb7a cmd/go: add the Retract field to 'go help mod edit' definition of the GoMod struct
+ 2020-12-23 49d0b239cb doc: fix a typo in contribute.html
+ 2020-12-23 98a73030b0 cmd/go: in 'go get', promote named implicit dependencies to explicit
+ 2020-12-23 fd6ba1c8a2 os/signal: fix a deadlock with syscall.AllThreadsSyscall() use
+ 2020-12-23 b0b0d98283 runtime: linux iscgo support for not blocking nptl signals
+ 2020-12-22 223331fc0c cmd/go/internal/modload: add hint for missing implicit dependency
Change-Id: I76d79f17c546cab03fab1facc36cc3f834d9d126
After earlier importer refactorings, most of the importer is now
reentrant, so we don't need to guard against it at Resolve. The only
remaining part that is still not reentrant is inline body importing,
so move the recursive-import check there.
Passes toolstash -cmp.
Change-Id: Ia828f880a03e6125b102668c12a155d4c253d26b
Reviewed-on: https://go-review.googlesource.com/c/go/+/280515
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
This CL shuffles a couple functions around to help flatten the package
dependency graph somewhat:
1. ssa.LosesStmtMark is only ever used in associated with an
objw.Prog, so we might as well move it to that package. This removes a
dependency from objw (a relatively low-level utility package that
wraps cmd/internal/obj) on ssa (a large and relatively high-level
package).
2. Moves liveness.SetTypeBits into a new package typebits. A
single-function package is a bit on the silly side, but reflectdata
shouldn't need to depend on liveness (nor vice versa).
[git-generate]
cd src/cmd/compile/internal/ssa
rf '
mv LosesStmtMark prog.go
mv prog.go cmd/compile/internal/objw
'
cd ../liveness
rf '
mv SetTypeBits Set
mv Set typebits.go
rm typebits.go:/Copyright/+4,/^package/-0
mv typebits.go cmd/compile/internal/typebits
'
Change-Id: Ic9a983f0ad6c0cf1a537f99889699a8444699e6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/280447
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Rename these two AST nodes to match their cmd/compile/internal/syntax
and go/ast counterparts.
Passes toolstash -cmp.
[git-generate]
cd src/cmd/compile/internal/ir
rf '
mv CaseStmt CaseClause
mv CommStmt CommClause
'
sed -E -i -e 's/(Case|Comm)Stmt/\1Clause/g' mknode.go
Change-Id: I19fba0323a5de1e71346622857011b2f7879bcef
Reviewed-on: https://go-review.googlesource.com/c/go/+/280446
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Package syntax's parser already ensures that select communication
clauses only have one statement, so there's no need for ir's CommStmt
to need to represent more than one. Instead, noder can just directly
populate Comm in the first place.
Incidentally, this also revealed a latent issue in the inline-body
exporter: we were exporting List (where the case statement is before
type-checking), rather than Comm (where the case statement would be
after type-checking, when export happens).
Passes toolstash -cmp.
Change-Id: Ib4eb711527bed297c7332c79ed6e6562a1db2cfa
Reviewed-on: https://go-review.googlesource.com/c/go/+/280444
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Select and switch statements only ever contain case statements, so
change their Cases fields from Nodes to []*CaseStmt. This allows
removing a bunch of type assertions throughout the compiler.
CaseStmt should be renamed to CaseClause, and SelectStmt should
probably have its own CommClause type instead (like in go/ast and
cmd/compile/internal/syntax), but this is a good start.
Passes toolstash -cmp.
Change-Id: I2d41d616d44512c2be421e1e2ff13d0ee8b238ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/280442
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
When looking for referenced functions within bottomUpVisitor and
initDeps, the logic for ODOTMETH, OCALLPART, and OMETHEXPR are
basically identical, especially after previous refactorings to make
them use MethodExprName. This CL makes them exactly identical.
Passes toolstash -cmp.
Change-Id: I1f59c9be99aa9484d0397a0a6fb8ddd894a31c68
Reviewed-on: https://go-review.googlesource.com/c/go/+/280441
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Now that we have proper types, these functions can be restricted to
only allowing *ir.Func, rather than any ir.Node. And even more
fortunately, all of their callers already happen to always
pass *ir.Func arguments, making this CL pretty simple.
Passes toolstash -cmp.
Change-Id: I21ecd4c8cee3ccb8ba86b17cedb2e71c56ffe87a
Reviewed-on: https://go-review.googlesource.com/c/go/+/280440
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
After reorder3's simplification, the only remaining use of
refersToCommonName is in oaslit, where the LHS expression is always a
single name. We can replace the now overly-generalized
refersToCommonName with a simple ir.Any traversal with ir.Uses.
Passes toolstash -cmp.
Change-Id: Ice3020cdbbf6083d52e07866a687580f4eb134b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/280439
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
reorder3 is the code responsible for ensuring that evaluation of an
N:N parallel assignment statement respects the order of evaluation
rules specified for Go.
This CL simplifies the code and improves it from an O(N^2) algorithm
to O(N).
Passes toolstash -cmp.
Change-Id: I04cd31613af6924f637b042be8ad039ec6a924c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/280437
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
ODOTMETH is unique among SelectorExpr expressions, in that Sel gets
mangled so that it no longer has the original identifier that was
selected (e.g., just "Foo"), but instead the qualified symbol name for
the selected method (e.g., "pkg.Type.Foo"). This is rarely useful, and
instead results in a lot of compiler code needing to worry about
undoing this change.
This CL changes ODOTMETH to leave the original symbol in place. The
handful of code locations where the mangled symbol name is actually
wanted are updated to use ir.MethodExprName(n).Sym() or (equivalently)
ir.MethodExprName(n).Func.Sym() instead.
Historically, the compiler backend has mistakenly used types.Syms
where it should have used ir.Name/ir.Funcs. And this change in
particular may risk breaking something, as the SelectorExpr.Sel will
no longer point at a symbol that uniquely identifies the called
method. However, I expect CL 280294 (desugar OCALLMETH into OCALLFUNC)
to have substantially reduced this risk, as ODOTMETH expressions are
now replaced entirely earlier in the compiler.
Passes toolstash -cmp.
Change-Id: If3c9c3b7df78ea969f135840574cf89e1d263876
Reviewed-on: https://go-review.googlesource.com/c/go/+/280436
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
This CL cleans up a few minor points in walkExpr:
1. We don't actually care about computing the type-size of all
expressions that are walked. We care about computing the type-size of
all expressions that are *returned* by walk, as these are the
expressions that will actually be seen by the back end.
2. There's no need to call typecheck.EvalConst anymore. EvalConst used
to be responsible for doing additional constant folding during walk;
but for a while a now, it has done only as much constant folding as is
required during type checking (because doing further constant folding
led to too many issues with Go spec compliance). Instead, more
aggressive constant folding is handled entirely by SSA.
3. The code for detecting string constants and generating their
symbols can be simplified somewhat.
Passes toolstash -cmp.
Change-Id: I464ef5bceb8a97689c8f55435369a3402a5ebc55
Reviewed-on: https://go-review.googlesource.com/c/go/+/280434
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Now that the previous CL ensures we always set SelectorExpr.Selection,
we can replace the SelectorExpr.Offset field with a helper method that
simply returns SelectorExpr.Selection.Offset.
Passes toolstash -cmp.
Change-Id: Id0f22b8b1980397b668f6860d27cb197b90ff52a
Reviewed-on: https://go-review.googlesource.com/c/go/+/280433
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
During walk, we create ODOTPTR expressions to access runtime struct
fields. But rather than using an actual Field for the selection, we
were just directly setting the ODOTPTR's Offset field.
This CL changes walk to create proper struct fields (albeit without
the rest of their enclosing struct type) and use them for creating the
ODOTPTR expressions.
Passes toolstash -cmp.
Change-Id: I08dbac3ed29141587feb0905d15adbcbcc4ca49e
Reviewed-on: https://go-review.googlesource.com/c/go/+/280432
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
When time.Parse sees a timezone name that matches the local timezone,
it uses the local timezone. The tests weren't expecting that,
so using MDT broke with TZ=America/Boise (where MDT means Mountain
Daylight Time). Just use GMT instead.
Fixes#43354
Change-Id: Ida70c8c867e2568b1535d1dfbf1fb0ed9e0e5c1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/280072
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
During walkCall, there's a half-hearted attempt at rewriting OCALLMETH
expressions into regular function calls by moving the receiver
argument into n.Args with the rest of the arguments. But the way it
does this leaves the AST in an inconsistent state (an ODOTMETH node
with no X expression), and leaves a lot of duplicate work for the rest
of the backend to deal with.
By simply rewriting OCALLMETH expressions into proper OCALLFUNC
expressions, we eliminate a ton of unnecessary code duplication during
SSA construction and avoid creation of invalid method-typed variables.
Passes toolstash -cmp.
Change-Id: I4d5c5f90a79f8994059b2d0ae472182e08096c0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/280294
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Within the compiler, we represent the type of methods as a special
"method" type, where the receiver parameter type is kept separate from
the other parameters. This is convenient for operations like testing
whether a type implements an interface, where we want to ignore the
receiver type.
These method types don't properly exist within the Go language though:
there are only "function" types. E.g., method expressions (expressions
of the form Type.Method) are simply functions with the receiver
parameter prepended to the regular parameter list.
However, the compiler backend is currently a little sloppy in its
handling of these types, which results in temporary variables being
declared as having "method" type, which then end up in DWARF
data. This is probably harmless in practice, but it's still wrong.
The proper solution is to fix the backend code so that we use correct
types everywhere, and the next CL does exactly this. But as it fixes
the DWARF output, so it fails toolstash -cmp. So this prelim CL
bandages over the issue in a way that generates the same output as
that proper fix.
Change-Id: I37a127bc8365c3a79ce513bdb3cfccb945912762
Reviewed-on: https://go-review.googlesource.com/c/go/+/280293
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The assignment type-checking code previously bounced around a lot
between the LHS and RHS sides of the assignment. But there's actually
a very simple, consistent pattern to how to type check assignments:
1. Check the RHS expression.
2. If the LHS expression is an identifier that was declared in this
statement and it doesn't have an explicit type, give it the RHS
expression's default type.
3. Check the LHS expression.
4. Try assigning the RHS expression to the LHS expression, adding
implicit conversions as needed.
This CL implements this algorithm, and refactors tcAssign and
tcAssignList to use a common implementation. It also fixes the error
messages to consistently say just "1 variable" or "1 value", rather
than occasionally "1 variables" or "1 values".
Fixes#43348.
Passes toolstash -cmp.
Change-Id: I749cb8d6ccbc7d22cd7cb0a381f58a39fc2696b5
Reviewed-on: https://go-review.googlesource.com/c/go/+/280112
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The devirtualization code was only in inl.go because it reused some of
the same helper functions as inlining (notably staticValue), but that
code all ended up in package ir instead anyway. Beyond that minor
commonality, it's entirely separate from inlining.
It's definitely on the small side, but consistent with the new
micropass-as-a-package approach we're trying.
[git-generate]
cd src/cmd/compile/internal/inline
rf '
mv Devirtualize Func
mv devirtualizeCall Call
mv Func Call devirtualize.go
mv devirtualize.go cmd/compile/internal/devirtualize
'
Change-Id: Iff7b9fe486856660a8107d5391c54b7e8d238706
Reviewed-on: https://go-review.googlesource.com/c/go/+/280212
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Today, timeHistogram, when copied, has the wrong set of counts for the
bucket that should represent (-inf, 0), when in fact it contains [0, 1).
In essence, the buckets are all shifted over by one from where they're
supposed to be.
But this also means that the existence of the overflow bucket is wrong:
the top bucket is supposed to extend to infinity, and what we're really
missing is an underflow bucket to represent the range (-inf, 0).
We could just always zero this bucket and continue ignoring negative
durations, but that likely isn't prudent.
timeHistogram is intended to be used with differences in nanotime, but
depending on how a platform is implemented (or due to a bug in that
platform) it's possible to get a negative duration without having done
anything wrong. We should just be resilient to that and be able to
detect it.
So this change removes the overflow bucket and replaces it with an
underflow bucket, and timeHistogram no longer panics when faced with a
negative duration.
Fixes#43328.
Fixes#43329.
Change-Id: If336425d7d080fd37bf071e18746800e22d38108
Reviewed-on: https://go-review.googlesource.com/c/go/+/279468
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Currently these two metrics are reported incorrectly, going by the
documentation in the runtime/metrics package. We just copy in the
size-class-based values from the runtime wholesale, but those implicitly
have an inclusive upper-bound and exclusive lower-bound (e.g. 48-byte
size class contains objects in the size range (32, 48]) but the API
declares inclusive lower-bounds and exclusive upper-bounds.
Also, the bottom bucket representing (-inf, 1) should always be empty.
Extend the consistency check to verify this.
Updates #43329.
Change-Id: I11b5b062a34e13405ab662d15334bda91f779775
Reviewed-on: https://go-review.googlesource.com/c/go/+/279467
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
All function parameters and return values in liveness have explicit
*ir.Name type, so use it directly instead of casting from ir.Node. While
at it, rename "affectedNode" to "affectedVar" to reflect this change.
Passes buildall w/ toolstash -cmp.
Change-Id: Id927e817a92ddb551a029064a2a54e020ca27074
Reviewed-on: https://go-review.googlesource.com/c/go/+/279434
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
'go get pkg@vers' will now add an explicit requirement for the module
providing pkg if that version was already indirectly required.
'go get mod@vers' will do the same if mod is a module path but not a
package.
Requirements promoted this way will be marked "// indirect" because
'go get' doesn't know whether they're needed to build packages in the
main module. So users should prefer to run 'go get ./pkg' (where ./pkg
is a package in the main module) to promote requirements.
Fixes#43131
Change-Id: Ifbb65b71274b3cc752a7a593d6ddd875f7de23b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/278812
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
This CL rips off a number of toolstash bandages:
- Fixes position information for string concatenation.
- Adds position information for struct literal fields.
- Removes unnecessary exprsOrNil calls or replaces them with plain
expr calls when possible.
- Reorders conversion expressions to put type first, which matches
source order and also the order the importer needs for calling the
ConvExpr constructor.
Change-Id: I44cdc6035540d9ecefd9c1bcd92b8711d6ed813c
Reviewed-on: https://go-review.googlesource.com/c/go/+/279957
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
After the previous CL, the only callers to NewFuncType, tointerface,
or NewStructType are the functions for type-checking the type literal
ASTs. So just inline the code there.
While here, refactor the Field type-checking logic a little bit, to
reduce some duplication.
Passes toolstash -cmp.
Change-Id: Ie12d14b87ef8b6e528ac9dccd609604bd09b98ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/279956
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Similar to the earlier mkbuiltin cleanup, there's a bunch of code that
calls typecheck.NewFuncType or typecheck.NewStructType, which can now
just call types.NewSignature and types.NewStruct, respectively.
Passes toolstash -cmp.
Change-Id: Ie6e09f1a7efef84b9a2bb5daa7087a6879979668
Reviewed-on: https://go-review.googlesource.com/c/go/+/279955
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
To break up package gc, we need to put these calculations somewhere
lower in the import graph, either an existing or new package. Package types
already needs this code and is using hacks to get it without an import cycle.
We can remove the hacks and set up for the new package gc by moving the
code into package types itself.
[git-generate]
cd src/cmd/compile/internal/gc
rf '
# Remove old import cycle hacks in gc.
rm TypecheckInit:/types.Widthptr =/-0,/types.Dowidth =/+0 \
../ssa/export_test.go:/types.Dowidth =/-+
ex {
import "cmd/compile/internal/types"
types.Widthptr -> Widthptr
types.Dowidth -> dowidth
}
# Disable CalcSize in tests instead of base.Fatalf
sub dowidth:/base.Fatalf\("dowidth without betypeinit"\)/ \
// Assume this is a test. \
return
# Move size calculation into cmd/compile/internal/types
mv Widthptr PtrSize
mv Widthreg RegSize
mv slicePtrOffset SlicePtrOffset
mv sliceLenOffset SliceLenOffset
mv sliceCapOffset SliceCapOffset
mv sizeofSlice SliceSize
mv sizeofString StringSize
mv skipDowidthForTracing SkipSizeForTracing
mv dowidth CalcSize
mv checkwidth CheckSize
mv widstruct calcStructOffset
mv sizeCalculationDisabled CalcSizeDisabled
mv defercheckwidth DeferCheckSize
mv resumecheckwidth ResumeCheckSize
mv typeptrdata PtrDataSize
mv \
PtrSize RegSize SlicePtrOffset SkipSizeForTracing typePos align.go PtrDataSize \
size.go
mv size.go cmd/compile/internal/types
'
: # Remove old import cycle hacks in types.
cd ../types
rf '
ex {
Widthptr -> PtrSize
Dowidth -> CalcSize
}
rm Widthptr Dowidth
'
Change-Id: Ib96cdc6bda2617235480c29392ea5cfb20f60cd8
Reviewed-on: https://go-review.googlesource.com/c/go/+/279234
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
There are a handful of pre-computed magic symbols known by
package gc, and we need a place to store them.
If we keep them together, the need for type *ir.Name means that
package ir is the lowest package in the import hierarchy that they
can go in. And package ir needs gopkg for methodSymSuffix
(in a later CL), so they can't go any higher either, at least not all together.
So package ir it is.
Rather than dump them all into the top-level package ir
namespace, however, we introduce global structs, Syms, Pkgs, and Names,
and make the known symbols, packages, and names fields of those.
[git-generate]
cd src/cmd/compile/internal/gc
rf '
add go.go:$ \
// Names holds known names. \
var Names struct{} \
\
// Syms holds known symbols. \
var Syms struct {} \
\
// Pkgs holds known packages. \
var Pkgs struct {} \
mv staticuint64s Names.Staticuint64s
mv zerobase Names.Zerobase
mv assertE2I Syms.AssertE2I
mv assertE2I2 Syms.AssertE2I2
mv assertI2I Syms.AssertI2I
mv assertI2I2 Syms.AssertI2I2
mv deferproc Syms.Deferproc
mv deferprocStack Syms.DeferprocStack
mv Deferreturn Syms.Deferreturn
mv Duffcopy Syms.Duffcopy
mv Duffzero Syms.Duffzero
mv gcWriteBarrier Syms.GCWriteBarrier
mv goschedguarded Syms.Goschedguarded
mv growslice Syms.Growslice
mv msanread Syms.Msanread
mv msanwrite Syms.Msanwrite
mv msanmove Syms.Msanmove
mv newobject Syms.Newobject
mv newproc Syms.Newproc
mv panicdivide Syms.Panicdivide
mv panicshift Syms.Panicshift
mv panicdottypeE Syms.PanicdottypeE
mv panicdottypeI Syms.PanicdottypeI
mv panicnildottype Syms.Panicnildottype
mv panicoverflow Syms.Panicoverflow
mv raceread Syms.Raceread
mv racereadrange Syms.Racereadrange
mv racewrite Syms.Racewrite
mv racewriterange Syms.Racewriterange
mv SigPanic Syms.SigPanic
mv typedmemclr Syms.Typedmemclr
mv typedmemmove Syms.Typedmemmove
mv Udiv Syms.Udiv
mv writeBarrier Syms.WriteBarrier
mv zerobaseSym Syms.Zerobase
mv arm64HasATOMICS Syms.ARM64HasATOMICS
mv armHasVFPv4 Syms.ARMHasVFPv4
mv x86HasFMA Syms.X86HasFMA
mv x86HasPOPCNT Syms.X86HasPOPCNT
mv x86HasSSE41 Syms.X86HasSSE41
mv WasmDiv Syms.WasmDiv
mv WasmMove Syms.WasmMove
mv WasmZero Syms.WasmZero
mv WasmTruncS Syms.WasmTruncS
mv WasmTruncU Syms.WasmTruncU
mv gopkg Pkgs.Go
mv itabpkg Pkgs.Itab
mv itablinkpkg Pkgs.Itablink
mv mappkg Pkgs.Map
mv msanpkg Pkgs.Msan
mv racepkg Pkgs.Race
mv Runtimepkg Pkgs.Runtime
mv trackpkg Pkgs.Track
mv unsafepkg Pkgs.Unsafe
mv Names Syms Pkgs symtab.go
mv symtab.go cmd/compile/internal/ir
'
Change-Id: Ic143862148569a3bcde8e70b26d75421aa2d00f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/279235
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The syscall.AllThreadsSyscall() fixup mechanism needs to cooperate
with signal handling to ensure a notetsleepg() thread can wake up
to run the mDoFixup() function.
Fixes#43149
Change-Id: I6651b25bc44a4de47d3fb71d0293d51aef8b79c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/277434
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
We want almost all cmd subdirectories anyway, and relative to the cost
of the rest of toolchain bootstrapping, copying/rewriting a few extra
source files is way cheaper than the engineering cost of forgetting to
maintain these lists as we split out new packages.
While here, also add cmd/internal/archive (and make it compile with Go
1.4) because it'll be needed in subsequent refactorings anyway; and
skip files starting with # (emacs temporary files) and test files
ending with _test.go.
Change-Id: Ic86e680a5fdfaecd617c36d5d04413293b2d6f52
Reviewed-on: https://go-review.googlesource.com/c/go/+/279832
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Under linux+cgo, OS threads are launched via pthread_create().
This abstraction, under linux, requires we avoid blocking
signals 32,33 and 34 indefinitely because they are needed to
reliably execute POSIX-semantics threading in glibc and/or musl.
When blocking signals the go runtime generally re-enables them
quickly. However, when a thread exits (under cgo, this is
via a return from mstart()), we avoid a deadlock in C-code by
not blocking these three signals.
Fixes#42494
Change-Id: I02dfb2480a1f97d11679e0c4b132b51bddbe4c14
Reviewed-on: https://go-review.googlesource.com/c/go/+/269799
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
By default (and with -mod=readonly), the go command imports an error
if a package provided by an implicitly required module is
imported by a package in the main module. This import requires an
update to go.mod: the module must be required explicitly.
The package loader now provides a hint that 'go get' should be run on
the importing package. This is preferred to 'go get' on the imported
package, since that would add an "// indirect" requirement.
For #43131
Change-Id: I0b353ce8ac8c4ddf1a9863544dfaf6c1964daf42
Reviewed-on: https://go-review.googlesource.com/c/go/+/279528
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The codereview command will start using this to figure out
the origin branch for commands like "git pending",
and it will use the parent setting for the new "git branch-sync" (merge).
Change-Id: Ia74af18ae5a437fb45ea81d7d69e2ffe41987b64
Reviewed-on: https://go-review.googlesource.com/c/go/+/279523
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The Go PE linker does not support enough generalized PE logic to
properly handle .rsrc sections gracefully. Instead a few things are
special cased for these. The linker also does not support PE's "grouped
sections" features, in which input objects have several named sections
that are sorted, merged, and renamed in the output file. In the past,
more sophisticated support for resources or for PE features like grouped
sections have not been necessary, as Go's own object formats are pretty
vanilla, and GNU binutils also produces pretty vanilla objects where all
sections are already merged.
However, GNU binutils is lagging with arm support, and here LLVM has
picked up the slack. In particular, LLVM has its own rc/cvtres combo,
which are glued together in mingw LLVM distributions as windres, a
command line compatible tool with binutils' windres, which supports arm
and arm64. But there's a key difference between binutils' windres and
LLVM's windres: the LLVM one uses proper grouped sections.
So, this commit adds grouped sections support for resource sections to
the linker. We don't attempt to plumb generic support for grouped
sections, just as there isn't generic support already for what resources
require. Instead we augment the resource handling logic to deal with
standard two-section resource objects.
We also add a test for this, akin to the current test for more vanilla
binutils resource objects, and make sure that the rsrc tests are always
performed.
Fixes#42866.
Fixes#43182.
Change-Id: I059450021405cdf2ef1c195ddbab3960764ad711
Reviewed-on: https://go-review.googlesource.com/c/go/+/268337
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
The mid-case n := n.(*ir.AssignExpr) does not lend itself
well to pulling the code into a new function, because n will
be a function argument and will not be redeclarable.
Change-Id: I673f2aa37eea64b083725326ed3fa36447bcc7af
Reviewed-on: https://go-review.googlesource.com/c/go/+/279426
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Sets up for removing Func from Node interface.
That means that once the Name reorg is done,
which will let us remove Name, Sym, and Val,
Node will be basically a minimal interface.
Passes buildall w/ toolstash -cmp.
Change-Id: I6e87897572debd7f8e29b4f5167763dc2792b408
Reviewed-on: https://go-review.googlesource.com/c/go/+/279484
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Misc cleanup for splitting package gc: API tweaks
and boundary adjustments.
The change in ir.NewBlockStmt makes it a drop-in
replacement for liststmt.
Change-Id: I9455fe8ccae7d71fe8ccf390ac96672389bf4f3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/279305
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Move various code out of Main itself and into helper functions
that can be moved into other packages as package gc splits up.
Similarly, move order and instrument inside walk to reduce the amount
of API surface needed from the eventual package walk.
Change-Id: I7849258038c6e39625a0385af9c0edd6a3b654a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/279304
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Having a global MaxWidth lets us avoid needing to
refer to thearch from split-out packages when all
they need is thearch.MAXWIDTH.
And make a couple interface changes to let dowidth
avoid importing package ir directly.
Then it can move into package types.
Change-Id: I2c12e8e22252597530e648848320e19bdd490a01
Reviewed-on: https://go-review.googlesource.com/c/go/+/279302
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
In issue11656.go, it tests that if the runtime can get a
reasonable traceback when it faults at a non-function PC. It does
it by jumping to an address that contains an illegal or trap
instruction. When it traps, the SIGTRAP crashes the runtime.
This CL changes it to use an instruction that triggers SIGSEGV.
This is due to two reasons:
- currently, the handling of bad PC is done by preparePanic,
which is only used for a panicking signal (SIGSEGV, SIGBUS,
SIGFPE), not a fatal signal (e.g. SIGTRAP).
- the test uses defer+recover to get a traceback, which only
works for panicking signals, not fatal signals.
Ideally, we should handle all kinds of faults (SIGSEGV, SIGBUS,
SIGILL, SIGTRAP, etc.) with a nice traceback. I'll leave this
for the future.
This CL also adds RISCV64 support.
Fixes#43283.
Change-Id: I5e0fbf8530cc89d16e05c3257d282bc1d4d03405
Reviewed-on: https://go-review.googlesource.com/c/go/+/279423
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Add compiler support for emitting ABI wrappers by creating real IR as
opposed to introducing ABI aliases. At the moment these are "no-op"
wrappers in the sense that they make a simple call (using the existing
ABI) to their target. The assumption here is that once late call
expansion can handle both ABI0 and the "new" ABIInternal (register
version), it can expand the call to do the right thing.
Note that the runtime contains functions that do not strictly follow
the rules of the current Go ABI0; this has been handled in most cases
by treating these as ABIInternal instead (these changes have been made
in previous patches).
Generation of ABI wrappers (as opposed to ABI aliases) is currently
gated by GOEXPERIMENT=regabi -- wrapper generation is on by default if
GOEXPERIMENT=regabi is set and off otherwise (but can be turned on
using "-gcflags=all=-abiwrap -ldflags=-abiwrap"). Wrapper generation
currently only workd on AMD64; explicitly enabling wrapper for other
architectures (via the command line) is not supported.
Also in this patch are a few other command line options for debugging
(tracing and/or limiting wrapper creation). These will presumably go
away at some point.
Updates #27539, #40724.
Change-Id: I1ee3226fc15a3c32ca2087b8ef8e41dbe6df4a75
Reviewed-on: https://go-review.googlesource.com/c/go/+/270863
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
The files below had conflicts that required manual resolution.
The unresolved conflict in noder.go was just in the import
declaration (trivial). All the other conflicts are in tests
where the ERROR regex patterns changed to accomodate gccgo
error messages (incoming from dev.regabi), and to accomodate
types2 in dev.typeparams. They were resolved by accepting the
dev.regabi changes (so as not to lose them) and then by re-
applying whatever changes needed to make them pass with types2.
Finally, the new test mainsig.go was excluded from run.go when
using types2 due to issue #43308.
src/cmd/compile/internal/gc/noder.go
test/fixedbugs/bug13343.go
test/fixedbugs/bug462.go
test/fixedbugs/issue10975.go
test/fixedbugs/issue11326.go
test/fixedbugs/issue11361.go
test/fixedbugs/issue11371.go
test/fixedbugs/issue11674.go
test/fixedbugs/issue13365.go
test/fixedbugs/issue13471.go
test/fixedbugs/issue14136.go
test/fixedbugs/issue14321.go
test/fixedbugs/issue14729.go
test/fixedbugs/issue15898.go
test/fixedbugs/issue16439.go
test/fixedbugs/issue17588.go
test/fixedbugs/issue19323.go
test/fixedbugs/issue19482.go
test/fixedbugs/issue19880.go
test/fixedbugs/issue20185.go
test/fixedbugs/issue20227.go
test/fixedbugs/issue20415.go
test/fixedbugs/issue20749.go
test/fixedbugs/issue22794.go
test/fixedbugs/issue22822.go
test/fixedbugs/issue22921.go
test/fixedbugs/issue23823.go
test/fixedbugs/issue25727.go
test/fixedbugs/issue26616.go
test/fixedbugs/issue28079c.go
test/fixedbugs/issue28450.go
test/fixedbugs/issue30085.go
test/fixedbugs/issue30087.go
test/fixedbugs/issue35291.go
test/fixedbugs/issue38745.go
test/fixedbugs/issue41247.go
test/fixedbugs/issue41440.go
test/fixedbugs/issue41500.go
test/fixedbugs/issue4215.go
test/fixedbugs/issue6402.go
test/fixedbugs/issue6772.go
test/fixedbugs/issue7129.go
test/fixedbugs/issue7150.go
test/fixedbugs/issue7153.go
test/fixedbugs/issue7310.go
test/fixedbugs/issue8183.go
test/fixedbugs/issue8385.go
test/fixedbugs/issue8438.go
test/fixedbugs/issue8440.go
test/fixedbugs/issue8507.go
test/fixedbugs/issue9370.go
test/fixedbugs/issue9521.go
Change-Id: I26e6e326fde6e3fca5400711a253834d710ab7f4
This CL changes so that all literals are represented with a new,
smaller ir.BasicLit type, so that ir.Name is only used to represent
declared constants.
Passes buildall w/ toolstash -cmp.
Change-Id: I4702b8e3fa945617bd05881d7a2be1205f229633
Reviewed-on: https://go-review.googlesource.com/c/go/+/279153
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
For OSLICELITs, we were reusing the Ntype field after type checking to
hold the length of the OSLICELIT's backing array. However, Ntype is
only meant for nodes that can represent types. Today, this works only
because we currently use Name for all OLITERAL constants (whether
declared or not), whereas we should be able to represent them more
compactly with a dedicated type that doesn't implement Ntype.
Passes buildall w/ toolstash -cmp.
Change-Id: I385f1d787c41b016f507a5bad9489d59ccfde7f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/279152
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
declNames always returns a slice of *ir.Names, so return that directly
rather than as []ir.Node.
While here, also change iimport to directly create ir.ODCL/ir.OAS
statements, rather than calling variter. Allows eliminating a use of
ir.TypeNode.
Passes buildall w/ toolstash -cmp.
Change-Id: Icb75e993c4957b6050c797ba64ee71cfb7a19644
Reviewed-on: https://go-review.googlesource.com/c/go/+/279315
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Adjust the pattern matching in one of the race output test to allow
for the possible introduction of an ABI wrapper. Normally for tests
that match traceback output wrappers are not an issue since they
are screened out by Go's traceback mechanism, but in this case the
race runtime is doing the unwinding, so the wrapper may be visible.
Change-Id: I45413b5c4701d4c28cc760fccc8203493dbe2874
Reviewed-on: https://go-review.googlesource.com/c/go/+/278756
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
The FreeBSD syscall convention uses the carry flag to indicate whether
an error has occured. The sys_umtx_op, thr_new, and pipe2 syscall
wrappers were failing to account for this convention and silently
suppressing errors as a result. This commit corrects these wrappers
by copying the pattern used by the other fallible syscall wrappers.
Note that futexsleep1 must now explicitly ignore the ETIMEDOUT error
from sys_umtx_op. Previously ETIMEDOUT was implicitly ignored because
sys_umtx_op never returned an error.
Fixes#43106.
Change-Id: I9c422b87cf4c6d308003bf42c3b419f785578b5d
Reviewed-on: https://go-review.googlesource.com/c/go/+/276892
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Than McIntosh <thanm@google.com>
Treat the compiler's -linkobj output as "compiler object, which
means "pack c" will "see through" the file and add individual
entry to the new archive, instead of the object as a whole.
This is somewhat peculiar. But Go 1.15's cmd/pack does this,
although seemingly accidental. We just do the same. FWIW, it
does make things more consistent with/without -linkobj flag.
Fixes#43271.
Change-Id: I6b2d99256db7ebf0fa430f85afa7464e334f6bcb
Reviewed-on: https://go-review.googlesource.com/c/go/+/279483
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Fix up the assembly shim routines runtime.panic{Index,Slice} and
friends so that their tail calls target ABIInternal and not ABI0
functions. This is so as to ensure that these calls don't go through
an ABI0->ABIInternal wrapper (which would throw off the machinery in
the called routines designed to detect whether the violation happened
in the runtime).
Note that when the compiler starts emitting real register calls to
these routines, we'll need to rewrite them to update the arg size and
ensure that args are in the correct registers. For example, the
current shim
TEXT runtime·panicIndex<ABIInternal>(SB),NOSPLIT,$0-16
MOVQ AX, x+0(FP)
MOVQ CX, y+8(FP)
JMP runtime·goPanicIndex<ABIInternal>(SB)
will need to change to
TEXT runtime·panicIndex<ABIInternal>(SB),NOSPLIT,$0
// AX already set up properly
MOVQ CX, BX // second argument expected in BX
JMP runtime·goPanicIndex<ABIInternal>(SB)
Change-Id: I48d1b5138fb4d229380ad12735cfaca5c50e6cc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/278755
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
This CL changes NewDeclNameAt to take an Op argument to set the Op up
front, and updates all callers to provide the appropriate Op. This
allows dropping the Name.SetOp method.
Passes buildall w/ toolstash -cmp.
Change-Id: I20e580f62d3c8a81223d1c162327c11b37bbf3f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/279314
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Rather than creating Names w/ ONONAME earlier and later adding in the
details, this CL changes the import logic to create and add details at
the same time.
Passes buildall w/ toolstash -cmp.
Change-Id: Ifaabade3cef8cd80ddd6644bff79393b934255d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/279313
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
We only need to call itabname when actually creating the OCONVIFACE
ops, not any time we test whether a type implements an
interface. Additionally, by moving this call out of implements, we
make it purely based on types, which makes it safe to move to package
types.
Does not pass toolstash -cmp, because it shuffles symbol creation
order.
Change-Id: Iea8e0c9374218f4d97b4339020ebd758d051bd03
Reviewed-on: https://go-review.googlesource.com/c/go/+/279333
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
isIntrinsicCall and ssaDumpInline are the only two "forward references"
to ssa by earlier phases. Make them a bit more explicit so that the
uses and the definitions can end up in different packages.
Change-Id: I02c7a27464fbedef9fee43c0e4094fa08b4d7a5c
Reviewed-on: https://go-review.googlesource.com/c/go/+/279300
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Separate embed, cgo pragmas, and Main trackScopes variable
from noder more cleanly.
This lets us split embed and noder into new packages.
It also assumes that the local embedded variables will be
removed and deletes them now for simplicity.
Change-Id: I9638bcc2c5f0e76440de056c6285b6aa2f73a00d
Reviewed-on: https://go-review.googlesource.com/c/go/+/279299
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
There are various global variables tracking the state of the
compilation. Collect them in a single global struct instead.
The struct definition is in package ir, but the struct itself is
still in package gc. It may eventually be threaded through the
code, but in the short term will end up in package typecheck.
Change-Id: I019db07aaedaed2c9b67dd45a4e138dc6028e54c
Reviewed-on: https://go-review.googlesource.com/c/go/+/279297
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Deleting the Pc assignment from Patch is safe because the actual PCs
are not assigned until well after the compiler is done patching jumps.
And it proves that replacing uses of Patch with SetTarget will be safe later.
Change-Id: Iffcbe03f0b5949ccd4c91e79c1272cd06be0f434
Reviewed-on: https://go-review.googlesource.com/c/go/+/279296
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The list of conflicted files for this merge is:
src/cmd/compile/internal/gc/inl.go
src/cmd/compile/internal/gc/order.go
src/cmd/compile/internal/gc/ssa.go
test/fixedbugs/issue20415.go
test/fixedbugs/issue22822.go
test/fixedbugs/issue28079b.go
inl.go was updated for changes on dev.regabi: namely that OSELRECV has
been removed, and that OSELRECV2 now only uses List, rather than both
Left and List.
order.go was updated IsAutoTmp is now a standalone function, rather
than a method on Node.
ssa.go was similarly updated for new APIs involving package ir.
The tests are all merging upstream additions for gccgo error messages
with changes to cmd/compile's error messages on the dev.regabi branch.
Change-Id: Icaaf186d69da791b5994dbb6688ec989caabec42
On darwin, where we use libc for syscalls, when the runtime exits,
it calls libc exit function, which may call back into user code,
e.g. invoking functions registered with atexit. In particular, it
may call back into Go. But at this point, the Go runtime is
already exiting, so this wouldn't work.
On non-libc platforms we use exit syscall directly, which doesn't
invoke any callbacks. Use _exit on darwin to achieve the same
behavior.
No test for now, as it doesn't pass on all platforms (see trybot
run of PS2).
May fix#42465.
May fix#43294.
Change-Id: Ia1ada22b5da8cb64fdd598d0541eb90e195367eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/269378
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The netbsd kernel has a bug [1] that occassionally prevents netpoll from
waking with netpollBreak, which could result in missing timers for an
unbounded amount of time, as netpoll can't restart with a shorter delay
when an earlier timer is added.
Prior to CL 232298, sysmon could detect these overrun timers and
manually start an M to run them. With this fallback gone, the bug
actually prevents timer execution indefinitely.
As a workaround, we add back sysmon detection only for netbsd.
[1] https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=50094
Updates #42515
Change-Id: I8391f5b9dabef03dd1d94c50b3b4b3bd4f889e66
Reviewed-on: https://go-review.googlesource.com/c/go/+/277332
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Michael Pratt <mpratt@google.com>
This was part of a performance improvement made by CL 232298 to
reduce timer latency. On multiprocessor Plan 9 machines, it triggers
memory faults often enough that the builder test suite never completes
successfully. See issue #42303 for discussion. As shown by the benchmark
result below, worst case latency on plan9_arm is very bad even with the
wakep call in place - in the tickers-per-P=1 case, a 3ms timer is 270ms late.
Skipping the wakep call and running the benchmark again shows some cases
worse, some better. The performance cost doesn't seem excessive for this
temporary workaround which makes the plan9_arm builders usable again.
With wakep call:
cpu% go test -bench Latency time
goos: plan9
goarch: arm
pkg: time
BenchmarkParallelTimerLatency-4 100 10985859 avg-late-ns 18630963 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=1-4 195 270294688 avg-late-ns 542057670 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=2-4 234 182452000 avg-late-ns 423933688 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=3-4 280 193003004 avg-late-ns 408034405 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=4-4 282 132819086 avg-late-ns 313624570 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=5-4 339 71152187 avg-late-ns 189014519 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=6-4 315 26860484 avg-late-ns 101759844 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=7-4 357 19106739 avg-late-ns 59435620 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=8-4 376 7246933 avg-late-ns 38888461 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=9-4 267 40476892 avg-late-ns 205851926 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=10-4 294 87836303 avg-late-ns 252059695 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=2ms/tickers-per-P=1-4 379 4127144 avg-late-ns 10494927 max-late-ns
Without wakep call:
BenchmarkParallelTimerLatency-4 61 10775151 avg-late-ns 18668517 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=1-4 199 299587535 avg-late-ns 597182307 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=2-4 272 184561831 avg-late-ns 449739837 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=3-4 235 154983257 avg-late-ns 370940553 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=4-4 290 150034689 avg-late-ns 332399843 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=5-4 298 47540764 avg-late-ns 133709031 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=6-4 350 20379394 avg-late-ns 81742809 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=7-4 363 14403223 avg-late-ns 98901212 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=8-4 375 12293090 avg-late-ns 50266552 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=9-4 336 40628820 avg-late-ns 150946099 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=300µs/tickers-per-P=10-4 289 88265539 avg-late-ns 280770418 max-late-ns
BenchmarkStaggeredTickerLatency/work-dur=2ms/tickers-per-P=1-4 375 8364937 avg-late-ns 22598421 max-late-ns
Fixes#42303
Change-Id: I70c63cb2a2bad46950a7cd9dfc7bb32943710d32
Reviewed-on: https://go-review.googlesource.com/c/go/+/275672
Reviewed-by: David du Colombier <0intro@gmail.com>
Trust: Michael Pratt <mpratt@google.com>
Previously, reassigned was failing to detect reassignments due to
channel receives in select statements (OSELRECV, OSELRECV2), or due to
standalone 2-value receive assignments (OAS2RECV). This was reported
as a devirtualization panic, but could have caused mis-inlining as
well.
Fixes#43292.
Change-Id: Ic8079c20c0587aeacff9596697fdeba80a697b12
Reviewed-on: https://go-review.googlesource.com/c/go/+/279352
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
The issue11656 code was using the trap instruction as a PC value,
but it is intended to call a PC value that contains the trap instruction.
It doesn't matter too much as in practice the address is not
executable anyhow. But may as well have the code act the way it
is documented to act.
Also, don't run the test with gccgo/GoLLVM, as it can't work.
The illegal instruction will have no unwind data, so the unwinder
won't be able to get past it. In other words, gccgo/GoLLVM suffer
from the exact problem that the issue describes, but it seems insoluble.
For golang/go#11656
Change-Id: Ib2e50ffc91d215fd50e78f742fafe476c92d704e
Reviewed-on: https://go-review.googlesource.com/c/go/+/278473
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The language spec only requires a signed binary exponent of 16 bits
for floating point constants. Permit a "exponent too large" error for
larger exponents.
Don't run test 11326b with gccgo, as it requires successful compilation
of floating point constants with exponents that don't fit in 16 bits.
Change-Id: I98688160c76864aba525a151a14aaaf86bc36a6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/279252
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
CL 243940 accidentally broke TestDependencies such that it always passed.
Make it work again, and add a test so that it won't break in the same way.
This revealed that the new embed package was missing from TestDepencies,
so add it.
Fixes#43249
Change-Id: I02b3e38dd35ad88880c4344d46de13b7639aa4c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/279073
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Historically the os package has not imported the strings package.
That was enforced by go/build.TestDependencies, but that test
was accidentally broken (#43249). A dependency of os on strings
was accidentally added by CL 266364; remove it.
For #42026
For #43249
Change-Id: If932308f30561fdcc5c608d7563e849c0d2870d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/279072
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
The prealloc map seems to exist to avoid adding a field to all nodes.
Now we can add a field to just the nodes that need the field,
so let's do that and avoid having a magic global with extra node state
that isn't preserved by operations like Copy nor printed by Dump.
This also makes clear which nodes can be prealloc'ed.
In particular, the code in walkstmt looked up an entry in
prealloc using an ONAME node, but there's no code that
ever stores such an entry, so the lookup never succeeded.
Having fields makes that kind of thing easier to see and fix.
Passes buildall w/ toolstash -cmp.
Change-Id: I418ad0e2847615c08868120c13ee719dc0b2eacb
Reviewed-on: https://go-review.googlesource.com/c/go/+/278915
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
For globals, Name.Offset is used as a way to address a field within
a global during static initialization. This CL replaces that use with
a separate NameOffsetExpr (ONAMEOFFSET) node.
For locals, Name.Offset is the stack frame offset. This CL calls it
that (FrameOffset, SetFrameOffset).
Now there is no longer any use of Name.Offset or Name.SetOffset.
And now that copies of Names are not being made to change their
offsets, we can lock down use of ir.Copy on Names. The only
remaining uses are during inlining and in handling generic system
functions. At both those times you do want to create a new name
and that can be made explicit by calling the new CloneName method
instead. ir.Copy on a name now panics.
Passes buildall w/ toolstash -cmp.
Change-Id: I0b0a25b9d93aeff7cf4e4025ac53faec7dc8603b
Reviewed-on: https://go-review.googlesource.com/c/go/+/278914
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on sinit.go.
Passes buildall w/ toolstash -cmp.
Change-Id: I3e9458e69a7a9b3f2fe139382bf961bc4473cc42
Reviewed-on: https://go-review.googlesource.com/c/go/+/277928
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on walk.go.
Passes buildall w/ toolstash -cmp.
Change-Id: I7aab57e4077cf10da1994625575c5e42ad114a9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/277921
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
ir.Find is called "any" in C#, Dart, Haskell, Python, R, Ruby, and Rust,
and "any_of" in C++, "anyMatch" in Java, "some" in JavaScript,
"exists in OCaml, and "existsb" in Coq.
(Thanks to Matthew Dempsky for the research.)
This CL changes Find to Any to use the mostly standard name.
It also updates wrapper helpers to use the any terminology:
hasCall -> anyCall
hasCallOrChan -> anyCallOrChan
hasSideEffects -> anySideEffects
Unchanged are "hasNamedResults", "hasUniquePos", and "hasDefaultCase",
which are all about a single node, not any node in the IR tree.
I also renamed hasFall to endsInFallthrough, since its semantics are
neither that of "any" nor that of the remaining "has" functions.
So the new terminology helps separate different kinds of predicates nicely.
Change-Id: I9bb3c9ebf060a30447224be09a5c34ad5244ea0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/278912
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Test failures started to happen sporadically on some builds after the introduction of NotifyContext.
To make these tests more robust and avoid the risk of crosstalk we run them in a separate process.
Fixes#41561.
Change-Id: Ia7af105c316afd11765358f1e5e253ccfe2adc2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/270198
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Cherry Zhang <cherryyz@google.com>
When doing external linking on Windows, auto-detect the linker flavor
(bfd vs gold vs lld) and when linking with "lld", avoid the use of
"-T" (linker script), since this option is not supported by lld.
[Note: the Go linker currently employs -T to ensure proper placement
of the .debug_gdb_scripts section, to work around issues in older
versions of binutils; LLD recognizes this section and does place it
properly].
Updates #39326.
Change-Id: I3ea79cdceef2316bf86eccdb60188ac3655264ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/278932
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Change the run.go driver to recognize the "gc" build tag.
Change existing tests to use the "gc" build tag if they use some
feature that seems specific to the gc compiler, such as passing specific
options to or expecting specific behavior from "go tool compile".
Change tests to use the "!gccgo" build tag if they use "go build" or
"go run", as while those might work with compilers other than gc, they
won't work with the way that gccgo runs its testsuite (which happens
independently of the go command).
For #43252
Change-Id: I666e04b6d7255a77dfc256ee304094e3a6bb15ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/279052
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Changes from dev.go2go:
+ Removed enableImplicitTParam
+ Fixed a bug in unpackRecv where pointer receivers were not being
detected in the syntax. This didn't seem to actually matter, as I
couldn't produce an incorrect test case as a result of this bug (I
guess by the time method sets are considered, functions have already
been type checked).
+ Updated to the new error API.
+ A line setting t.underlying to Typ[Invalid] was restored in
Checker.validType when a cycle is detected. Though this didn't seem
to matter, it preserves an invariant that invalid types are used to
suppress error reporting.
Change-Id: I3b53b35368c244d67571f23d70fb991af50db540
Reviewed-on: https://go-review.googlesource.com/c/go/+/278595
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL handles all the little files that are left.
Passes buildall w/ toolstash -cmp.
Change-Id: I6588c92dbbdd37342a77b365d70e02134a033d2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/277932
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on noder.go.
Passes buildall w/ toolstash -cmp.
Change-Id: Ie870126b51558e83c738add8e91a2804ed6d7f92
Reviewed-on: https://go-review.googlesource.com/c/go/+/277931
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on subr.go.
Passes buildall w/ toolstash -cmp.
Change-Id: I435082167c91e20a4d490aa5d5945c7454f71d61
Reviewed-on: https://go-review.googlesource.com/c/go/+/277930
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on range.go, select.go, and swt.go: the big
control structures.
Passes buildall w/ toolstash -cmp.
Change-Id: I033fe056a7b815edb6e8a06f45c12ffd990f4d45
Reviewed-on: https://go-review.googlesource.com/c/go/+/277929
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on const.go.
Passes buildall w/ toolstash -cmp.
Change-Id: I824f18fa0344ddde56df0522f9fa5e237114bbe2
Reviewed-on: https://go-review.googlesource.com/c/go/+/277927
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on inl.go.
Passes buildall w/ toolstash -cmp.
Change-Id: Iaaee7664cd43e264d9e49d252e3afa7cf719939b
Reviewed-on: https://go-review.googlesource.com/c/go/+/277926
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on iimport.go and iexport.go.
Passes buildall w/ toolstash -cmp.
Change-Id: I63edee54991ae5d982e99efa7a2894478d511910
Reviewed-on: https://go-review.googlesource.com/c/go/+/277925
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on escape.go.
Passes buildall w/ toolstash -cmp.
Change-Id: I3e76e1ef9b72f28e3adad9633929699635d852dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/277924
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on ssa.go.
Passes buildall w/ toolstash -cmp.
Change-Id: Iefacc7104dd9469e3c574149791ab0bff29f7fee
Reviewed-on: https://go-review.googlesource.com/c/go/+/277923
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on order.go.
Passes buildall w/ toolstash -cmp.
Change-Id: Ib5731905a620175a6fe978f512da593e0dae9d87
Reviewed-on: https://go-review.googlesource.com/c/go/+/277922
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on typecheck.go.
Passes buildall w/ toolstash -cmp.
Change-Id: I32d1d3b813b0a088b1750c9fd28cd858ed813f1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/277920
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
It seems clear after using these for a week that Find need not return
anything other than a bool saying whether the target was found.
The main reason for not using the boolean earlier was to avoid confusion
with Inspect: for Find, returning true means "it was found! stop walking"
while for Inspect, returning true means "keep walking the children".
But it turns out that none of the uses of Inspect need the boolean.
This makes sense because types can contain expressions, expressions
can contain statements (inside function literals), and so on, so there
are essentially no times when you can say based on the current AST node
that the children are irrelevant to a particular operation.
So this CL makes two changes:
1) Change Find to return a boolean and to take a callback function
returning a boolean. This simplifies all existing calls to Find.
2) Rename Inspect to Visit and change it to take a callback with no
result at all. This simplifies all existing calls to Inspect.
Removing the boolean result from Inspect's callback avoids having
two callbacks with contradictory boolean results in different APIs.
Renaming Inspect to Visit avoids confusion with ast.Inspect.
Passes buildall w/ toolstash -cmp.
Change-Id: I344ebb5e00b6842012be33e779db483c28e5f350
Reviewed-on: https://go-review.googlesource.com/c/go/+/277919
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The general concept of an "implicit" operation is provided by every
expr representation, but it really only makes sense for a few of them,
and worse the exact definition of what "implicit" means differs from
node to node.
This CL moves the method to each node implementation, although
they all share the same header bit instead of each defining a bool field
that would turn into 8 bytes on 64-bit systems.
Now we can say precisely which Nodes have a meaningful Implicit
method: AddrExpr, CompLitExpr, ConvExpr, ParenExpr, and StarExpr.
Passes buildall w/ toolstash -cmp.
Change-Id: I7d85cb0507a514cdcb6eed21347f362e5fb57a91
Reviewed-on: https://go-review.googlesource.com/c/go/+/277918
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The initorder pass is already making heavy use of maps,
and it is concerned with relatively few nodes (only the assignments
in package-level variable declarations). The tracking of init order
for these nodes can be done with another map instead of storing
the bits directly in the Node representations.
This will let us drop Offset_ from AssignStmt and AssignListStmt
and drop Initorder from all nodes.
Passes buildall w/ toolstash -cmp.
Change-Id: I151c64e84670292c2004da4e8e3d0660a88e3df3
Reviewed-on: https://go-review.googlesource.com/c/go/+/277917
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The Nodes type originally served two purposes:
(1) It provided a representation optimized for empty slices,
allocating only a single word in that case instead of three,
at the cost of a non-empty slice being four words instead of three.
This was particularly important with the old Node representation,
in which most Nodes were full of unused fields.
(2) It provided a few useful helper methods beyond what can be
done with slices.
The downside of Nodes is that the API is a bit overwhelming,
with many ways to spell ordinary slice operations. For example,
reassigning the first node in the list can be done with:
ns.Slice()[0] = n
ns.SetIndex(0, n)
ns.SetFirst(n)
*ns.Addr(0) = n
And APIs must decide whether to use Nodes or []ir.Node and
then conversions must be inserted when crossing the boundary.
Now that Node structs are specialized to opcode and most Nodes
lists are actually non-empty, it makes sense to simplify Nodes
to make it actually a slice type, so that ordinary slice operations can
be used, and assignments can automatically convert between
Nodes and []ir.Node.
This CL changes the representation to be a slice and adds a new
Take method, which returns the old slice and clears the receiver.
In a future CL, the Nodes method set will simplify down to:
Copy
Take
Append
Prepend
Format
with the current methods being rewritten:
ns.Len() -> len(ns)
ns.Slice() -> ns
ns.First() -> ns[0]
ns.Second() -> ns[1]
ns.Index(i) -> ns[i]
ns.Addr(i) -> &ns[i]
ns.SetIndex(i, n) -> ns[i] = n
ns.SetFirst(n) -> ns[0] = n
ns.SetSecond(n) -> ns[1] = n
ns.Set1(n) -> ns = []Node{n}
ns.Set2(n, n2) -> ns = []Node{n, n2}
ns.Set3(n, n2, n3) -> ns = []Node{n, n2, n3}
AsNodes(slice) -> Nodes(slice)
ns.AppendNodes(pns) -> ns.Append(pns.Take()...)
ns.MoveNodes(pns) -> ns = pns.Take()
and then all those other methods will be deleted.
Simplifying the API down to just those five methods will also make it
more reasonable to introduce more specialized slices like Exprs and Stmts
at some point in the future.
But again this CL just changes the representation to a slice,
introduces Take, and leaves the rest alone.
Passes buildall w/ toolstash -cmp.
Change-Id: I309ab8335c69bb582d811c92c17f938dd6e0c4fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/277916
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL handles package fmt. There are various type assertions
but also some rewriting to lean more heavily on reflection.
Passes buildall w/ toolstash -cmp.
Change-Id: I503467468b42ace11bff2ba014b03cfa345e6d03
Reviewed-on: https://go-review.googlesource.com/c/go/+/277915
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
I haven't measured this, but it's the only use of EditChildren
where we aren't careful to allocate a closure once and use it
for the whole recursion. This one is allocating a closure at
every level of the recursion, and it was an oversight that it
wasn't cleaned up in the original CL.
Passes buildall w/ toolstash -cmp.
Change-Id: I5e3f1795c6f64c5867a19c077f797643aa1066a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/277914
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite is going to remove the bulk of the calls
to ir.Nod and friends. This CL takes care of the ones that don't
have fixed opcodes and so aren't amenable to automatic rewriting.
Passes buildall w/ toolstash -cmp.
Replay of CL 275886, lost to the bad-merge history rewrite.
Change-Id: I5bf8d1d182f847f4ab44b7e278b752913e30e4c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/277956
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Avoid using the same variable for two different concrete
Node types in other files (beyond walk). This will smooth the
introduction of specific constructors, replacing ir.Nod and friends.
Passes buildall w/ toolstash -cmp.
Replay of CL 275885, lost to the bad-merge history rewrite.
Change-Id: I0da89502a0bd636b8766f01b6f843c7821b3e9ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/277955
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Avoid using the same variable for two different concrete
Node types in walk. This will smooth the introduction of
specific constructors, replacing ir.Nod and friends.
Passes buildall w/ toolstash -cmp.
Replay of CL 275884, lost to the bad-merge history rewrite.
Change-Id: I05628e20a19c9559ed7478526ef6cb2613f735e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/277954
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This is a port of CL 278132 from the dev.typeparams branch. A notable
addition is a new error code, since no existing codes made sense and we
have an analogous code for type switches.
Fixes#43110
Change-Id: I22b3f9d8777063223f82785504e8b7d299bc5216
Reviewed-on: https://go-review.googlesource.com/c/go/+/278813
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
The -verify flag is used to verify idempotent printing of syntax
trees. While syntax tree printing is not actively used at the
moment, the verification code still shouldn't panic.
Fixed the cause for the panic (after reading from a bytes.Buffer
that buffer is empty and so doesn't compare to the unread buffer),
and replaced the panic with a test error.
Added a test that makes sure the code invoked by -verify is run.
Change-Id: I38634ed7cfa8668deb0ea2ee9fb74a8f86cfc195
Reviewed-on: https://go-review.googlesource.com/c/go/+/278477
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Make predicates.go match the corresponding and reviewed go/types version.
The remaining diffs are due to the difference in the implementations
of the type conversion methods/functions:
$ diff $GOROOT/src/cmd/compile/internal/types2/predicates.go $GOROOT/src/go/types/predicates.go
7c7
< package types2
---
> package types
9a10
> "go/token"
32c33
< switch t := optype(typ.Under()).(type) {
---
> switch t := optype(typ).(type) {
63c64
< // set up. Must not call Basic()!
---
> // set up. Must not call asBasic()!
79c80
< t := typ.Basic()
---
> t := asBasic(typ)
85c86
< return typ.Interface() != nil
---
> return asInterface(typ) != nil
110c111
< if t := T.TypeParam(); t != nil && optype(t) == theTop {
---
> if t := asTypeParam(T); t != nil && optype(t) == theTop {
114c115
< switch t := optype(T.Under()).(type) {
---
> switch t := optype(T).(type) {
143c144
< switch t := optype(typ.Under()).(type) {
---
> switch t := optype(typ).(type) {
300,301c301,302
< check.completeInterface(nopos, x)
< check.completeInterface(nopos, y)
---
> check.completeInterface(token.NoPos, x)
> check.completeInterface(token.NoPos, y)
Change-Id: I174d8a8a22fbd8814ede25002cb2705588912329
Reviewed-on: https://go-review.googlesource.com/c/go/+/278474
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Make unify.go match the corresponding and reviewed go/types version.
The remaining differences are due to other differences in the packages.
Also, this version of unify opted to preserve the longer comment around
case tj > 0.
$ diff $GOROOT/src/cmd/compile/internal/types2/unify.go $GOROOT/src/go/types/unify.go
7c7
< package types2
---
> package types
9c9,12
< import "sort"
---
> import (
> "go/token"
> "sort"
> )
120,123d122
< // This case is handled like the default case.
< // case tj > 0:
< // // Only the type parameter for y has an inferred type. Use y slot for x.
< // u.x.setIndex(i, tj)
125,126c124,125
< // Neither type parameter has an inferred type. Use y slot for x
< // (or x slot for y, it doesn't matter).
---
> // Either the type parameter for y has an inferred type, or neither type
> // parameter has an inferred type. In either case, use y slot for x.
216c215
< // basic types and type parameters. We use Named() because we only
---
> // basic types and type parameters. We use asNamed() because we only
219,222c218,221
< case !isNamed(x) && y != nil && y.Named() != nil:
< return u.nify(x, y.Under(), p)
< case x != nil && x.Named() != nil && !isNamed(y):
< return u.nify(x.Under(), y, p)
---
> case !isNamed(x) && y != nil && asNamed(y) != nil:
> return u.nify(x, under(y), p)
> case x != nil && asNamed(x) != nil && !isNamed(y):
> return u.nify(under(x), y, p)
353,354c352,353
< u.check.completeInterface(nopos, x)
< u.check.completeInterface(nopos, y)
---
> u.check.completeInterface(token.NoPos, x)
> u.check.completeInterface(token.NoPos, y)
Change-Id: Icb246d4befedfa82cc3dcfdb7dd162cd4127fbe9
Reviewed-on: https://go-review.googlesource.com/c/go/+/278572
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Mach-O relocation addend is signed 24-bit. When external linking,
if the addend is larger, we cannot put it directly into a Mach-O
relocation. This CL handles large addend by creating "label"
symbols at sym+0x800000, sym+(0x800000*2), etc., and emitting
Mach-O relocations that target the label symbols with a smaller
addend. The label symbols are generated late (similar to what
we do for RISC-V64).
One complexity comes from handling of carrier symbols, which does
not track its size or its inner symbols. But relocations can
target them. We track them in a side table (similar to what we
do for XCOFF, xcoffUpdateOuterSize).
Fixes#42738.
Change-Id: I8c53ab2397f8b88870d26f00e9026285e5ff5584
Reviewed-on: https://go-review.googlesource.com/c/go/+/278332
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
When testing if a flag (e.g. "-no-pie") is supported by the
external linker, pass arch-specific flags (like "-marm").
In particular, on the ARM builder, if CGO_LDFLAGS=-march=armv6
is set, the C toolchain fails to build if -marm is not passed.
# cc -march=armv6 1.c
1.c: In function 'main':
1.c:3:1: sorry, unimplemented: Thumb-1 hard-float VFP ABI
int main() {
^~~
This makes the Go linker think "-no-pie" is not supported when it
actually is.
Passing -marm makes it work.
Fixes#43202.
Change-Id: I4e8b71f08818993cbbcb2494b310c68d812d6b50
Reviewed-on: https://go-review.googlesource.com/c/go/+/278592
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
The code in the new (introduced in 1.15) Go object file reader was
casting a pointer-mmaped-memory into a large array prior to performing
a read of the relocations section:
return (*[1<<20]Reloc)(unsafe.Pointer(&r.b[off]))[:n:n]
For very large object files, this artificial array isn't large enough
(that is, there are more than 1048576 relocs to read), so update the
code to use a larger artifical array size.
Fixes#41621.
Change-Id: Ic047c8aef4f8a3839f2e7e3594bce652ebd6bd5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/278492
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Trust: Than McIntosh <thanm@google.com>
The transponder sets up a deferred close on accepted connections which
is fine after the client reads all data. However there are no mutexes
nor channels to block the transponder from closing. If the scheduler
runs close before the client read, it will cause an EOF failure.
Fixes#42720
Change-Id: Ic21b476c5efc9265a80a2c6f8484efdb5af66405
Reviewed-on: https://go-review.googlesource.com/c/go/+/273672
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Damien Neil <dneil@google.com>
Microsoft's linker looks at whether all input objects have an empty
section called @feat.00. If all of them do, then it enables SEH;
otherwise it doesn't enable that feature. So, since around the Windows
XP SP2 era, most tools that make PE objects just tack on that section,
so that it won't gimp Microsoft's linker logic. Go doesn't support SEH,
so in theory, none of this really matters to us. But actually, if the
linker tries to ingest an object with @feat.00 -- which are produced by
LLVM's resource compiler, for example -- it chokes because of the
IMAGE_SYM_ABSOLUTE section that it doesn't know how to deal with. Since
@feat.00 is just a marking anyway, skip IMAGE_SYM_ABSOLUTE sections that
are called @feat.00.
Change-Id: I1d7bfcf6001186c53e2c487c5ac251ca65efefee
Reviewed-on: https://go-review.googlesource.com/c/go/+/268239
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Changes from dev.go2go:
+ Remove support for pointer designation.
+ Remove support for method type parameters in missingMethod. We could
leave this logic in, but it looked sufficiently shaky that I'd rather
not bring in the additional complexity.
+ Remove the strictness flag parameter to assertableTo, since it isn't
used.
Change-Id: I812b8d1c49f3b714b166f061fbb7f2e683a0ce86
Reviewed-on: https://go-review.googlesource.com/c/go/+/278333
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The gofrontend code sees that the denominator is not zero,
so it computes the values. Dividing zero by a non-zero value
produces zero. The language spec doesn't require any of these
cases to report an error, so make the errors compiler-specific.
Change-Id: I5ed759a3121e38b937744d32250adcbdf2c4d3c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/278117
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
The bug429 tests is an exact duplicate of TestSimpleDeadlock in the
runtime package. The runtime package is the right place for this test,
and the version in the runtime package will run faster as the build
step is combined with other runtime package tests.
Change-Id: I6538d24e6df8e8c5e3e399d3ff37d68f3e52be56
Reviewed-on: https://go-review.googlesource.com/c/go/+/278173
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The language spec only requires that floating point values be
represented with 256 bits, which is about 1e75. The issue11371 test
was assuming that the compiler could represent 1e100. Adjusting the
test so that it only assumes 256 bits of precision still keeps the
test valid, and permits it to pass when using the gofrontend.
Change-Id: I9d1006e9adc9438277f4b8002488c912e5d61cc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/278116
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
With the gc compiler the import path implies the package path,
so keeping a canonical path is important. With the gofrontend
this is not the case, so we don't need to report this as a bug.
Change-Id: I245e34f9b66383bd17e79438d4b002a3e20aa994
Reviewed-on: https://go-review.googlesource.com/c/go/+/278115
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The pattern in NNN.dir directories is that if we have a.go,
the other files import "./a". For gc it happens to work to use a path,
but not for gofrontend. Better to be consistent.
Change-Id: I2e023cbf6bd115f9fb77427b097b0ff9b9992f17
Reviewed-on: https://go-review.googlesource.com/c/go/+/278113
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Import changes related to tracking type inferences and sanitizing
types.Info from the dev.go2go branch. Notably, the following were all
intentionally omitted from this import:
+ types.Error.Full is not imported, due to it being a public API that
requires some further thought.
+ The Config.AcceptMethodTypeParams, InferFromConstraints, and Trace
flag are not imported. The expectation is that we will not accept
method type parameters for now, will always infer from constraints,
and will continue to use the trace constant to guard tracing.
+ Some trace annotations are not imported to from the checking pass. We
can add them back later, but for now they seemed verbose.
+ Checker.useBrackets is removed. This is no longer configurable.
Change-Id: I7f6315d66b200c92ffd1e55c9fd425a5d99149ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/278312
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
In package syntax:
- fix parser appendGroup to not add nil entries
- non-string paths are syntax errors per the spec; report in parser
- document ImportDecl.Path invariants
In package types2:
- guard against absent paths
In package gc:
- guard against absent paths
Fixes#43190.
Change-Id: Ic6a06f6a96b7f519feaa1ceaf4376fc5ab0f0129
Reviewed-on: https://go-review.googlesource.com/c/go/+/278114
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The path package doesn't have a Glob function. Adjust the release notes
re. CL 264397 accordingly.
Also add links to the documentation of all mentioned functions.
For #40700.
Change-Id: Ibf3e0530fa6fab36a3f6fbc664f0800869ce9ec7
Reviewed-on: https://go-review.googlesource.com/c/go/+/278213
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
After review, the only non-superficial change was to delegate the call
to under(...) to structuralType. Otherwise, update a few stale comments:
+ correct indices in the documentation for tparamsList
+ update smap->substMap in a few places
+ update type parameter syntax in a couple places
I've spent a good amount of time reviewing this code, and it
fundamentally LGTM (though I wish we didn't have to copy the logic from
identical0). However, as demonstrated in #43056, this code is
complicated and not always easy to reason about, particularly in the
context of type checking where not all types may be complete.
To further understand and verify this code I'd like to write more tests,
but that must wait until the rest of the changes in go/types are
imported from dev.go2go.
Change-Id: Iabb9d3a6af988a2e1b3445cde6bc2431a80f8bfe
Reviewed-on: https://go-review.googlesource.com/c/go/+/276692
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
This CL substantially reworks how imported declarations are handled,
and fixes a number of issues with dot imports. In particular:
1. It eliminates the stub ir.Name declarations that are created
upfront during import-declaration processing, allowing this to be
deferred to when the declarations are actually needed. (Eventually,
this can be deferred even further so we never have to create ir.Names
w/ ONONAME, but this CL is already invasive/subtle enough.)
2. During noding, we now use ir.Idents to represent uses of imported
declarations, including of dot-imported declarations.
3. Unused dot imports are now reported after type checking, so that we
can correctly distinguish whether composite literal keys are a simple
identifier (struct literals) or expressions (array/slice/map literals)
and whether it might be a use of a dot-imported declaration.
4. It changes the "redeclared" error messages to report the previous
position information in the same style as other compiler error
messages that reference other source lines.
Passes buildall w/ toolstash -cmp.
Fixes#6428.
Fixes#43164.
Fixes#43167.
Updates #42990.
Change-Id: I40a0a780ec40daf5700fbc3cfeeb7300e1055981
Reviewed-on: https://go-review.googlesource.com/c/go/+/277713
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
The next CL requires externdcl to be type checked earlier, but this
causes toolstash -cmp to complain because it causes src.PosBases to
get added in a different order. So split out into a separate CL.
Change-Id: Icab4eadd3fa8acffbd3e980bd8100924378351b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/277732
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Sym.pkgDefPtr is supposed to return a pointer to the types.Object
variable currently holding the Sym's package-scope
definition. However, in the case of identifiers that were shadowed in
the current scope, it was incorrectly returning a pointer to a stack
copy of the dclstack variable, rather than a pointer into the dclstack
itself.
This doesn't affect PkgDef, because it only reads from the variable,
so it got the same result anyway. It also happens to not affect our
usage of SetPkgDef today, because we currently only call SetPkgDef for
the builtin/runtime.go symbols, and those are never shadowed.
However, it does affect my upcoming CL to lazily create the ir.Names
for imported objects, as that depends on the ability to use SetPkgDef
to set shadowed identifiers.
Passes buildall w/ toolstash -cmp.
Change-Id: I54fc48b33da0670d31725faa1df1170a8730750a
Reviewed-on: https://go-review.googlesource.com/c/go/+/277712
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
fixedbugs/issue26416.go:24:16: error: unknown field ‘t1f1’ in ‘t2’
fixedbugs/issue26416.go:25:16: error: unknown field ‘t1f2’ in ‘t3’
fixedbugs/issue26416.go:26:16: error: unknown field ‘t2f1’ in ‘t3’
fixedbugs/issue26616.go:15:9: error: single variable set to multiple-value function call
fixedbugs/issue26616.go:9:5: error: incompatible type in initialization (multiple-value function call in single-value context)
fixedbugs/issue26616.go:12:13: error: incompatible type in initialization (multiple-value function call in single-value context)
fixedbugs/issue26616.go:13:13: error: incompatible type in initialization (multiple-value function call in single-value context)
fixedbugs/issue26616.go:15:9: error: incompatible type in initialization (multiple-value function call in single-value context)
fixedbugs/issue26616.go:14:11: error: incompatible types in assignment (multiple-value function call in single-value context)
fixedbugs/issue26855.go:23:12: error: incompatible type for field 1 in struct construction
fixedbugs/issue26855.go:27:12: error: incompatible type for field 1 in struct construction
fixedbugs/issue25958.go:14:18: error: expected ‘<-’ or ‘=’
fixedbugs/issue25958.go:15:35: error: expected ‘<-’ or ‘=’
fixedbugs/issue28079b.go:13:9: error: array bound is not constant
fixedbugs/issue28079b.go:16:22: error: invalid context-determined non-integer type for left operand of shift
fixedbugs/issue28079c.go:14:22: error: invalid context-determined non-integer type for left operand of shift
fixedbugs/issue28450.go:9:19: error: ‘...’ only permits one name
fixedbugs/issue28450.go:10:18: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:11:16: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:11:24: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:13:25: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:15:19: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:16:21: error: ‘...’ must be last parameter
fixedbugs/issue28450.go:16:31: error: ‘...’ must be last parameter
fixedbugs/issue28268.go:20:1: error: method ‘E’ redeclares struct field name
fixedbugs/issue28268.go:19:1: error: method ‘b’ redeclares struct field name
fixedbugs/issue27356.go:14:14: error: expected function
fixedbugs/issue27356.go:18:9: error: expected function
fixedbugs/issue29855.go:13:11: error: unknown field ‘Name’ in ‘T’
fixedbugs/issue27938.go:14:15: error: expected package
fixedbugs/issue27938.go:18:13: error: expected package
fixedbugs/issue27938.go:22:13: error: expected package
fixedbugs/issue27938.go:22:9: error: expected signature or type name
fixedbugs/issue29870b.go:13:9: error: ‘x’ declared but not used
fixedbugs/issue30085.go:10:18: error: wrong number of initializations
fixedbugs/issue30085.go:11:21: error: wrong number of initializations
fixedbugs/issue30087.go:10:18: error: wrong number of initializations
fixedbugs/issue30087.go:11:11: error: number of variables does not match number of values
fixedbugs/issue30087.go:12:9: error: wrong number of initializations
fixedbugs/issue30087.go:13:9: error: wrong number of initializations
fixedbugs/issue28926.go:16:14: error: use of undefined type ‘G’
fixedbugs/issue28926.go:18:14: error: use of undefined type ‘E’
fixedbugs/issue28926.go:22:24: error: use of undefined type ‘T’
fixedbugs/issue30722.go:13:13: error: invalid numeric literal
fixedbugs/issue30722.go:14:13: error: invalid numeric literal
fixedbugs/issue30722.go:15:13: error: invalid numeric literal
fixedbugs/issue33308.go:12:19: error: invalid context-determined non-integer type for left operand of shift
fixedbugs/issue33386.go:16:9: error: expected operand
fixedbugs/issue33386.go:22:9: error: expected operand
fixedbugs/issue33386.go:26:17: error: expected operand
fixedbugs/issue33386.go:27:18: error: expected operand
fixedbugs/issue33386.go:28:29: error: expected operand
fixedbugs/issue33386.go:15:17: error: reference to undefined name ‘send’
fixedbugs/issue33386.go:27:13: error: reference to undefined name ‘a’
fixedbugs/issue33386.go:21:19: error: value computed is not used
fixedbugs/issue33460.go:34:10: error: duplicate key in map literal
fixedbugs/issue33460.go:21:9: error: duplicate case in switch
fixedbugs/issue33460.go:24:9: error: duplicate case in switch
fixedbugs/issue33460.go:25:9: error: duplicate case in switch
fixedbugs/issue32723.go:12:14: error: invalid comparison of non-ordered type
fixedbugs/issue32723.go:13:13: error: invalid comparison of non-ordered type
fixedbugs/issue32723.go:16:16: error: invalid comparison of non-ordered type
fixedbugs/issue32723.go:17:16: error: invalid comparison of non-ordered type
fixedbugs/issue32723.go:18:15: error: invalid comparison of non-ordered type
fixedbugs/issue32723.go:21:15: error: invalid comparison of non-ordered type
fixedbugs/issue35291.go:13:9: error: duplicate value for index 1
fixedbugs/issue38745.go:12:12: error: reference to undefined field or method ‘M’
fixedbugs/issue38745.go:13:16: error: reference to undefined field or method ‘M’
fixedbugs/issue38745.go:17:19: error: reference to undefined field or method ‘M’
fixedbugs/issue38745.go:17:9: error: not enough arguments to return
fixedbugs/issue41500.go:16:22: error: incompatible types in binary expression
fixedbugs/issue41500.go:17:26: error: incompatible types in binary expression
fixedbugs/issue41500.go:18:22: error: incompatible types in binary expression
fixedbugs/issue41500.go:19:26: error: incompatible types in binary expression
fixedbugs/issue41575.go:23:6: error: invalid recursive type
fixedbugs/issue41575.go:9:6: error: invalid recursive type ‘T1’
fixedbugs/issue41575.go:13:6: error: invalid recursive type ‘T2’
fixedbugs/issue41575.go:17:6: error: invalid recursive type ‘a’
fixedbugs/issue41575.go:18:6: error: invalid recursive type ‘b’
fixedbugs/issue41575.go:19:6: error: invalid recursive type ‘c’
fixedbugs/issue41575.go:25:6: error: invalid recursive type ‘g’
fixedbugs/issue41575.go:32:6: error: invalid recursive type ‘x’
fixedbugs/issue41575.go:33:6: error: invalid recursive type ‘y’
fixedbugs/issue4215.go:10:9: error: not enough arguments to return
fixedbugs/issue4215.go:14:9: error: return with value in function with no return type
fixedbugs/issue4215.go:19:17: error: not enough arguments to return
fixedbugs/issue4215.go:21:9: error: not enough arguments to return
fixedbugs/issue4215.go:27:17: error: not enough arguments to return
fixedbugs/issue4215.go:29:17: error: too many values in return statement
fixedbugs/issue4215.go:31:17: error: not enough arguments to return
fixedbugs/issue4215.go:43:17: error: not enough arguments to return
fixedbugs/issue4215.go:46:17: error: not enough arguments to return
fixedbugs/issue4215.go:48:9: error: too many values in return statement
fixedbugs/issue4215.go:52:9: error: too many values in return statement
fixedbugs/issue41247.go:10:16: error: incompatible type for return value 1
fixedbugs/issue41440.go:13:9: error: too many arguments
fixedbugs/issue6772.go:10:16: error: ‘a’ repeated on left side of :=
fixedbugs/issue6772.go:17:16: error: ‘a’ repeated on left side of :=
fixedbugs/issue6402.go:12:16: error: incompatible type for return value 1
fixedbugs/issue6403.go:13:23: error: reference to undefined identifier ‘syscall.X’
fixedbugs/issue6403.go:14:15: error: reference to undefined name ‘voidpkg’
fixedbugs/issue7746.go:24:20: error: constant multiplication overflow
fixedbugs/issue7760.go:15:7: error: invalid constant type
fixedbugs/issue7760.go:16:7: error: invalid constant type
fixedbugs/issue7760.go:18:7: error: invalid constant type
fixedbugs/issue7760.go:19:7: error: invalid constant type
fixedbugs/issue7760.go:21:11: error: expression is not constant
fixedbugs/issue7760.go:22:11: error: expression is not constant
fixedbugs/issue7760.go:24:7: error: invalid constant type
fixedbugs/issue7760.go:25:7: error: invalid constant type
fixedbugs/issue7129.go:18:11: error: argument 1 has incompatible type (cannot use type bool as type int)
fixedbugs/issue7129.go:19:11: error: argument 1 has incompatible type (cannot use type bool as type int)
fixedbugs/issue7129.go:20:11: error: argument 1 has incompatible type (cannot use type bool as type int)
fixedbugs/issue7129.go:20:17: error: argument 2 has incompatible type (cannot use type bool as type int)
fixedbugs/issue7150.go:12:20: error: index expression is negative
fixedbugs/issue7150.go:13:13: error: some element keys in composite literal are out of range
fixedbugs/issue7150.go:14:13: error: some element keys in composite literal are out of range
fixedbugs/issue7150.go:15:13: error: some element keys in composite literal are out of range
fixedbugs/issue7150.go:16:13: error: some element keys in composite literal are out of range
fixedbugs/issue7675.go:16:11: error: argument 1 has incompatible type (cannot use type int as type string)
fixedbugs/issue7675.go:16:24: error: argument 3 has incompatible type (cannot use type string as type float64)
fixedbugs/issue7675.go:16:9: error: not enough arguments
fixedbugs/issue7675.go:16:14: error: floating-point constant truncated to integer
fixedbugs/issue7675.go:18:11: error: argument 1 has incompatible type (cannot use type int as type string)
fixedbugs/issue7675.go:18:24: error: argument 3 has incompatible type (cannot use type string as type float64)
fixedbugs/issue7675.go:18:28: error: argument 4 has incompatible type (cannot use type int as type string)
fixedbugs/issue7675.go:18:9: error: too many arguments
fixedbugs/issue7675.go:18:14: error: floating-point constant truncated to integer
fixedbugs/issue7675.go:19:11: error: argument 1 has incompatible type (cannot use type int as type string)
fixedbugs/issue7675.go:19:9: error: not enough arguments
fixedbugs/issue7675.go:19:14: error: floating-point constant truncated to integer
fixedbugs/issue7675.go:21:11: error: argument 1 has incompatible type (cannot use type int as type string)
fixedbugs/issue7675.go:21:19: error: argument 3 has incompatible type
fixedbugs/issue7675.go:21:14: error: floating-point constant truncated to integer
fixedbugs/issue7675.go:23:14: error: floating-point constant truncated to integer
fixedbugs/issue7153.go:11:15: error: reference to undefined name ‘a’
fixedbugs/issue7153.go:11:18: error: incompatible type for element 1 in composite literal
fixedbugs/issue7153.go:11:24: error: incompatible type for element 2 in composite literal
fixedbugs/issue7310.go:12:13: error: left argument must be a slice
fixedbugs/issue7310.go:13:13: error: second argument must be slice or string
fixedbugs/issue7310.go:14:15: error: incompatible types in binary expression
fixedbugs/issue6964.go:10:13: error: invalid type conversion (cannot use type complex128 as type string)
fixedbugs/issue7538a.go:14:9: error: reference to undefined label ‘_’
fixedbugs/issue8311.go:14:9: error: increment or decrement of non-numeric type
fixedbugs/issue8507.go:12:6: error: invalid recursive type ‘T’
fixedbugs/issue9521.go:16:20: error: argument 2 has incompatible type
fixedbugs/issue9521.go:17:20: error: argument 2 has incompatible type (cannot use type float64 as type int)
fixedbugs/issue8385.go:30:19: error: argument 1 has incompatible type (type has no methods)
fixedbugs/issue8385.go:30:14: error: not enough arguments
fixedbugs/issue8385.go:35:9: error: not enough arguments
fixedbugs/issue8385.go:36:9: error: not enough arguments
fixedbugs/issue8385.go:37:10: error: not enough arguments
fixedbugs/issue8385.go:38:10: error: not enough arguments
fixedbugs/issue8385.go:39:10: error: not enough arguments
fixedbugs/issue8385.go:40:10: error: not enough arguments
fixedbugs/issue8385.go:41:13: error: not enough arguments
fixedbugs/issue8438.go:13:23: error: incompatible type for element 1 in composite literal
fixedbugs/issue8438.go:14:22: error: incompatible type for element 1 in composite literal
fixedbugs/issue8438.go:15:23: error: incompatible type for element 1 in composite literal
fixedbugs/issue8440.go:10:9: error: reference to undefined name ‘n’
Change-Id: I5707aec7d3c9178c4f4d794d4827fc907b52efb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/278032
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
As far as I can tell, the addend is the same for both of these, and in
this context we don't really care about setting or unsetting the thumb
selection bit, so just treat these the same way.
Change-Id: I3756c027239f77778c32b317733df9ac92272580
Reviewed-on: https://go-review.googlesource.com/c/go/+/268238
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
The linker recognizes headers for 386 and amd64 PE objects, but not arm
objects. This is easily overlooked, since its the same as the 386 header
value, except the two nibbles of the first word are swapped. This commit
simply adds the check for this. Without it, .syso objects are rejected,
which means Windows binaries can't have resources built into them. At
the same time, we add comments to better indicate which condition
applies to which arch.
Change-Id: I210411d978504c1a9540e23abc5a180e24f159ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/268237
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Changes from dev.go2go:
+ A potentially latent bug is fixed when nilling out tparams in an
instantiated signature (the resulting type could be Typ[Invalid])
+ Support for pointer designation is removed
+ instantiatedHash is updated to use '[]' rather than '()'
+ Several TODOs were added for me to follow-up on, rather than address
in this CL
+ Error callsites are updated. Deciding on error codes and better error
messages is punted to a later CL
These changes can be reviewed by comparing with Patchset #1 of this CL.
Change-Id: Ib5869586b8395419013010e2085cab877727d2ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/276253
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Most syntax.Nodes are allocated in one place and there didn't
seem a need to provide factory methods - so as a matter of
API design, all nodes are "naked", without any constructors.
However, Name nodes are frequently used/replaced and also
are created as helper nodes in clients (types2). Make an
exception and export NewName.
Change-Id: I4b5c499d65bba74592dea68b0936c118b3edaca7
Reviewed-on: https://go-review.googlesource.com/c/go/+/277572
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The ORANGE structure that is being replaced by this CL was causing
trouble with another CL (CL 275695).
The problem occurs if you typecheck i in the middle of generating the
body of the ORANGE loop. If you typecheck i, it ends up typechecking
its definition, which secretly typechecks the containing ORANGE. If
you then add other items to the ORANGE body, those items will never
get typechecked, as the ORANGE is already marked as typechecked.
Instead, just steal the loop we use for the equality code. Might as
well use the same pattern in both places.
Change-Id: Idb1ac77881d2cc9da08c7437a652b50d3ee45e2e
Reviewed-on: https://go-review.googlesource.com/c/go/+/275713
Trust: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
This bug was introduced by the change from go/ast to syntax which
represents pointer types as (unary) operations rather than dedicated
StarExpr nodes. Accordingly, this bug does not exist for go/types.
It's still ok to backport the test.
Fixes#43125.
Change-Id: Ic55d913f8afc92862856e1eb7c2861d07fc56cfb
Reviewed-on: https://go-review.googlesource.com/c/go/+/278013
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
If the parser reported an error for (string) literals, don't report
a second error during type checking.
This should have a couple of tests but they are tricky to arrange
with the current testing framework as the ERROR comment cannot be
on the line where the string. But the change is straightforward
and we have test/fixedbugs/issue32133.go that is passing now.
Change-Id: I0cd7f002b04e4092b8eb66009c7413288c8bfb23
Reviewed-on: https://go-review.googlesource.com/c/go/+/277993
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The `external_cgo_thread` test in `runtime/race/output_test.go` was
producing intermittent failures. The test was performing a sleep,
which may not be enough depending on how long it takes to setup the
callBack goroutine.
Added a synchronization to make sure callBack finishes before main ends.
Whether the increment to racy++ happens first in the callBack
or in main doesn't matter: the race detector should flag the race
regardless. The output check was changed so that the test passes
regardless of which increment occurs first.
Fixes#43008
Change-Id: I325ec3dea52b3725e739fbf2bd7ae92875d2de10
Reviewed-on: https://go-review.googlesource.com/c/go/+/276752
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
The following files had merge conflicts and were merged manually:
src/cmd/compile/fmtmap_test.go
src/cmd/compile/internal/gc/noder.go
src/go/parser/error_test.go
test/assign.go
test/chan/perm.go
test/fixedbugs/issue22822.go
test/fixedbugs/issue4458.go
test/init.go
test/interface/explicit.go
test/map1.go
test/method2.go
The following files had manual changes to make tests pass:
test/run.go
test/used.go
src/cmd/compile/internal/types2/stdlib_test.go
Change-Id: Ia495aaaa80ce321ee4ec2a9105780fbe913dbd4c
In an executable, the debug_addr and debug_rnglists sections are
assembled by concatenating the input sections, and each input section
has a header, and each header may have different attributes. So just
parsing the single header isn't right. Parsing the header is not
necessary to handle offsets into these sections which is all we do.
Looking at the header is also problematic because GCC with
-gsplit-dwarf when using DWARF versions 2 through 4 emits a
.debug_addr section, but it has no header. The header was only added
for DWARF 5. So we can't parse the header at all for that case, and we
can't even detect that case in general.
This CL also fixes SeekPC with addrx and strx formats, by not using
the wrong compilation unit to find the address or string base.
To make that work when parsing the compilation unit itself, we add
support for delay the resolution of those values until we know the base.
New test binaries built with
gcc -gdwarf-5 -no-pie debug/dwarf/testdata/line[12].c
(gcc (Debian 10.2.0-15) 10.2.0)
clang -gdwarf-5 -no-pie debug/dwarf/testdata/line[12].c
(clang version 9.0.1-14)
Change-Id: I66783e0eded629bf80c467767f781164d344a54d
Reviewed-on: https://go-review.googlesource.com/c/go/+/277233
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
fixedbugs/issue20602.go:13:9: error: argument must have complex type
fixedbugs/issue20602.go:14:9: error: argument must have complex type
fixedbugs/issue19323.go:12:12: error: attempt to slice object that is not array, slice, or string
fixedbugs/issue19323.go:18:13: error: attempt to slice object that is not array, slice, or string
fixedbugs/issue20749.go:12:11: error: array index out of bounds
fixedbugs/issue20749.go:15:11: error: array index out of bounds
fixedbugs/issue20415.go:14:5: error: redefinition of ‘f’
fixedbugs/issue20415.go:12:5: note: previous definition of ‘f’ was here
fixedbugs/issue20415.go:25:5: error: redefinition of ‘g’
fixedbugs/issue20415.go:20:5: note: previous definition of ‘g’ was here
fixedbugs/issue20415.go:33:5: error: redefinition of ‘h’
fixedbugs/issue20415.go:31:5: note: previous definition of ‘h’ was here
fixedbugs/issue19977.go:12:21: error: reference to undefined name ‘a’
fixedbugs/issue20812.go:10:13: error: invalid type conversion (cannot use type string as type int)
fixedbugs/issue20812.go:11:13: error: invalid type conversion (cannot use type int as type bool)
fixedbugs/issue20812.go:12:13: error: invalid type conversion (cannot use type string as type bool)
fixedbugs/issue20812.go:13:13: error: invalid type conversion (cannot use type bool as type int)
fixedbugs/issue20812.go:14:13: error: invalid type conversion (cannot use type bool as type string)
fixedbugs/issue21256.go:9:5: error: redefinition of ‘main’
fixedbugs/issue20813.go:10:11: error: invalid left hand side of assignment
fixedbugs/issue20185.go:22:16: error: ‘t’ declared but not used
fixedbugs/issue20185.go:13:9: error: cannot type switch on non-interface value
fixedbugs/issue20185.go:22:9: error: cannot type switch on non-interface value
fixedbugs/issue20227.go:11:11: error: division by zero
fixedbugs/issue20227.go:12:12: error: division by zero
fixedbugs/issue20227.go:13:12: error: division by zero
fixedbugs/issue20227.go:15:11: error: division by zero
fixedbugs/issue20227.go:16:12: error: division by zero
fixedbugs/issue19880.go:14:13: error: invalid use of type
fixedbugs/issue23093.go:9:5: error: initialization expression for ‘f’ depends upon itself
fixedbugs/issue21979.go:29:13: error: integer constant overflow
fixedbugs/issue21979.go:39:13: error: complex constant truncated to floating-point
fixedbugs/issue21979.go:10:13: error: invalid type conversion (cannot use type string as type bool)
fixedbugs/issue21979.go:11:13: error: invalid type conversion (cannot use type int as type bool)
fixedbugs/issue21979.go:12:13: error: invalid type conversion (cannot use type float64 as type bool)
fixedbugs/issue21979.go:13:13: error: invalid type conversion (cannot use type complex128 as type bool)
fixedbugs/issue21979.go:15:13: error: invalid type conversion (cannot use type bool as type string)
fixedbugs/issue21979.go:17:13: error: invalid type conversion (cannot use type float64 as type string)
fixedbugs/issue21979.go:18:13: error: invalid type conversion (cannot use type complex128 as type string)
fixedbugs/issue21979.go:20:13: error: invalid type conversion (cannot use type string as type int)
fixedbugs/issue21979.go:21:13: error: invalid type conversion (cannot use type bool as type int)
fixedbugs/issue21979.go:27:13: error: invalid type conversion (cannot use type string as type uint)
fixedbugs/issue21979.go:28:13: error: invalid type conversion (cannot use type bool as type uint)
fixedbugs/issue21979.go:34:13: error: invalid type conversion (cannot use type string as type float64)
fixedbugs/issue21979.go:35:13: error: invalid type conversion (cannot use type bool as type float64)
fixedbugs/issue21979.go:41:13: error: invalid type conversion (cannot use type string as type complex128)
fixedbugs/issue21979.go:42:13: error: invalid type conversion (cannot use type bool as type complex128)
fixedbugs/issue21988.go:11:11: error: reference to undefined name ‘Wrong’
fixedbugs/issue22063.go:11:11: error: reference to undefined name ‘Wrong’
fixedbugs/issue22904.go:12:6: error: invalid recursive type ‘a’
fixedbugs/issue22904.go:13:6: error: invalid recursive type ‘b’
fixedbugs/issue22921.go:11:16: error: reference to undefined identifier ‘bytes.nonexist’
fixedbugs/issue22921.go:13:19: error: reference to undefined identifier ‘bytes.nonexist’
fixedbugs/issue22921.go:13:19: error: expected signature or type name
fixedbugs/issue22921.go:17:15: error: reference to undefined identifier ‘bytes.buffer’
fixedbugs/issue23823.go:15:9: error: invalid recursive interface
fixedbugs/issue23823.go:10:9: error: invalid recursive interface
fixedbugs/issue23732.go:24:13: error: too few expressions for struct
fixedbugs/issue23732.go:34:17: error: too many expressions for struct
fixedbugs/issue23732.go:37:13: error: too few expressions for struct
fixedbugs/issue23732.go:40:17: error: too many expressions for struct
fixedbugs/issue22794.go:16:14: error: reference to undefined field or method ‘floats’
fixedbugs/issue22794.go:18:19: error: unknown field ‘floats’ in ‘it’
fixedbugs/issue22794.go:19:17: error: unknown field ‘InneR’ in ‘it’
fixedbugs/issue22794.go:18:9: error: ‘i2’ declared but not used
fixedbugs/issue22822.go:15:17: error: expected function
fixedbugs/issue25727.go:12:10: error: reference to unexported field or method ‘doneChan’
fixedbugs/issue25727.go:13:10: error: reference to undefined field or method ‘DoneChan’
fixedbugs/issue25727.go:14:21: error: unknown field ‘tlsConfig’ in ‘http.Server’
fixedbugs/issue25727.go:15:21: error: unknown field ‘DoneChan’ in ‘http.Server’
fixedbugs/issue25727.go:21:14: error: unknown field ‘bAr’ in ‘foo’
Change-Id: I32ce0b7d80017b2367b8fb479a881632240d4161
Reviewed-on: https://go-review.googlesource.com/c/go/+/277455
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Introduce a new utility routine for analyzing a given function
signature to how its various input and output parameters will be
passed (in registers or on the stack) for a given ABI description,
along with some unit tests.
Change-Id: Id64a98a0a142e42dd9c2dc9f6607c0d827ef84fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/273011
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Trust: Than McIntosh <thanm@google.com>
fixedbugs/issue14136.go:17:16: error: unknown field ‘X’ in ‘T’
fixedbugs/issue14136.go:18:13: error: incompatible type in initialization (cannot use type int as type string)
fixedbugs/issue14520.go:9:37: error: import path contains control character
fixedbugs/issue14520.go:14:2: error: expected ‘)’
fixedbugs/issue14520.go:14:3: error: expected declaration
fixedbugs/issue14652.go:9:7: error: use of undefined type ‘any’
fixedbugs/issue14729.go:13:17: error: embedded type may not be a pointer
fixedbugs/issue15514.dir/c.go:10: error: incompatible type in initialization
fixedbugs/issue15898.go:11:9: error: duplicate type in switch
fixedbugs/issue15898.go:16:9: error: duplicate type in switch
fixedbugs/issue16439.go:10:21: error: index expression is negative
fixedbugs/issue16439.go:13:21: error: index expression is negative
fixedbugs/issue16439.go:16:21: error: index expression is not integer constant
fixedbugs/issue16439.go:18:22: error: index expression is not integer constant
fixedbugs/issue17328.go:11:20: error: expected ‘{’
fixedbugs/issue17328.go:11:20: error: expected ‘;’ or ‘}’ or newline
fixedbugs/issue17328.go:13:1: error: expected declaration
fixedbugs/issue17588.go:14:15: error: expected type
fixedbugs/issue17631.go:20:17: error: unknown field ‘updates’ in ‘unnamed struct’
fixedbugs/issue17645.go:15:13: error: incompatible type in initialization
fixedbugs/issue17758.go:13:1: error: redefinition of ‘foo’
fixedbugs/issue17758.go:9:1: note: previous definition of ‘foo’ was here
fixedbugs/issue18092.go:13:19: error: expected colon
fixedbugs/issue18231.go:17:12: error: may only omit types within composite literals of slice, array, or map type
fixedbugs/issue18393.go:24:38: error: expected type
fixedbugs/issue18419.dir/test.go:12: error: reference to unexported field or method 'member'
fixedbugs/issue18655.go:14:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18655.go:15:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18655.go:16:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18655.go:17:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18655.go:18:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18655.go:20:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18655.go:21:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18655.go:22:1: error: redefinition of ‘m’
fixedbugs/issue18655.go:13:1: note: previous definition of ‘m’ was here
fixedbugs/issue18915.go:13:20: error: expected ‘;’ after statement in if expression
fixedbugs/issue18915.go:16:21: error: parse error in for statement
fixedbugs/issue18915.go:19:24: error: expected ‘;’ after statement in switch expression
fixedbugs/issue18915.go:13:12: error: ‘a’ declared but not used
fixedbugs/issue18915.go:16:13: error: ‘b’ declared but not used
fixedbugs/issue18915.go:19:16: error: ‘c’ declared but not used
fixedbugs/issue19012.go:16:17: error: return with value in function with no return type
fixedbugs/issue19012.go:18:9: error: return with value in function with no return type
fixedbugs/issue19012.go:22:16: error: argument 2 has incompatible type (cannot use type bool as type uint)
fixedbugs/issue19012.go:22:9: error: too many arguments
fixedbugs/issue19012.go:22:16: error: incompatible types in binary expression
fixedbugs/issue19012.go:24:9: error: too many arguments
fixedbugs/issue19056.go:9:9: error: expected operand
fixedbugs/issue19056.go:9:9: error: expected ‘;’ or newline after top level declaration
fixedbugs/issue19482.go:25:15: error: expected struct field name
fixedbugs/issue19482.go:27:15: error: expected struct field name
fixedbugs/issue19482.go:31:19: error: expected struct field name
fixedbugs/issue19482.go:33:15: error: expected struct field name
fixedbugs/issue19667.go:13:1: error: expected operand
fixedbugs/issue19667.go:13:1: error: missing ‘)’
fixedbugs/issue19667.go:13:105: error: expected ‘;’ after statement in if expression
fixedbugs/issue19667.go:13:105: error: expected ‘{’
fixedbugs/issue19667.go:12:19: error: reference to undefined name ‘http’
Change-Id: Ia9c75b9c78671f354f0a0623dbc075157ef8f181
Reviewed-on: https://go-review.googlesource.com/c/go/+/277433
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The type of the shift count must be an unsigned integer. Some s390x
rules for shift have their auxint type being int8. This results in a
compilation failure on s390x with an invalid operation when running
make.bash using older versions of go (e.g: go1.10.4).
This CL adds an auxint type of uint8 and changes the ops for shift and
rotate to use auxint with type uint8. The related rules are also
modified to address this change.
Fixes#43090
Change-Id: I594274b6e3d9b23092fc9e9f4b354870164f2f19
Reviewed-on: https://go-review.googlesource.com/c/go/+/277078
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
The non-simple, phi-insertion algorithm can leave OpFwdRefs in the SSA
graph unresolved if they're in dead blocks. Normally, these would be
harmlessly removed later during SSA dead-code elimination, but those
passes are omitted for -N builds. And so they reach zcse, where the
Value.Aux is used within a hash map.
This became a problem after golang.org/cl/275788, which added
FwdRefAux to wrap OpFwdRef's ir.Node, and to ensure that it's not
compared for equality / used as a map key.
This CL adds a simple fix: if there are any OpFwdRefs remaining after
resolveFwdRef, then they must be dead code and we can simply replace
them with OpUnknown.
Change-Id: I72e4116d52d3f6441ebb0bf6160906617cd59513
Reviewed-on: https://go-review.googlesource.com/c/go/+/277075
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
There were only a few places these were still used, none of which
justify generating all this code. Instead rewrite them to use
fmt.Sprint or simpler means.
Passes buildall w/ toolstash -cmp.
Change-Id: Ibd123a1696941a597f0cb4dcc96cda8ced672140
Reviewed-on: https://go-review.googlesource.com/c/go/+/276072
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
If 'go install' is invoked in module mode outside a module with a
package that could only be loaded from a module, it will now suggest
running 'go install pkg@latest'.
'go install' will still work outside a module on packages in std and
cmd, as well as .go files specified on the command line.
Fixes#42638
Change-Id: Ib0963935f028b7656178bc04a279b1114de35fbb
Reviewed-on: https://go-review.googlesource.com/c/go/+/277355
Run-TryBot: Jay Conrod <jayconrod@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Replaced load.PackagesForBuild with a new function,
load.CheckPackageErrors. Callers should now call PackagesAndErrors,
then CheckPackageErrors for the same functionality.
Removed load.Packages. Callers should call base.Errorf and filter the
package list as needed.
This gives callers more flexibility in handling package load errors.
For #42638
Change-Id: Id75463ba695adc1ca3f8693ceb2c8978b74a3500
Reviewed-on: https://go-review.googlesource.com/c/go/+/277354
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Since CL 270057, there're many attempts to fix the expand_calls pass
with interface{}-typed. But all of them did not fix the root cause. The
main issue is during SSA conversion in gc/ssa.go, for empty interface
case, we make its type as n.Type, instead of BytePtr.
To fix these, we can just use BytePtr for now, since when itab fields
are treated as scalar.
No significal changes on compiler speed, size.
cmd/compile/internal/ssa
expandCalls.func6 9488 -> 9232 (-2.70%)
file before after Δ %
cmd/compile/internal/ssa.s 3992893 3992637 -256 -0.006%
total 20500447 20500191 -256 -0.001%
Fixes#43112
Updates #42784
Updates #42727
Updates #42568
Change-Id: I0b15d9434e0be5448453e61f98ef9c2d6cd93792
Reviewed-on: https://go-review.googlesource.com/c/go/+/276952
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The Go spec requires that select case clauses be evaluated in order,
which is stricter than normal ordering semantics. cmd/compile handled
this correctly for send clauses, but was not correctly handling
receive clauses that involved bare variable references.
Discovered with @cuonglm.
Fixes#43111.
Change-Id: Iec93b6514dd771875b084ba49c15d7f4531b4a6f
Reviewed-on: https://go-review.googlesource.com/c/go/+/277132
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
The various conversion functions just change the format of time values.
They don't use the Unix epoch. Although in practice the values are often
times since the Unix epoch, they aren't always, so referring to the
epoch can be confusing.
Fixes#43010
Change-Id: I640d665f0d2017f0974db05d70858037c7c91eda
Reviewed-on: https://go-review.googlesource.com/c/go/+/277073
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
The tools section TODO can be removed since the tools section looks
complete by now.
All TODOs in the minor changes to the library section have been done,
so the top-level TODO is resolved. Delete it.
The currently highlighted entries under Core library section look
good. It's worth reviewing this further based on feedback from Go
1.16 pre-releases, so keep the TODO but make it non-user-visible
to unblock Go 1.16 Beta 1.
For #40700.
Change-Id: Ie72661bd457b0a93ef92e1bfc0844072f3b618a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/277212
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change adds an additional line explaining the ordering of the
supported metrics list. It's also necessary to ensure "Supported
metrics" is displayed by godoc as a proper header.
This modification does mean the description test, that ensures
descriptions line up with documentation, needs to change slightly
so it it doesn't read this new line as documentation. Make this
new line the line the test uses to decide when to begin.
Change-Id: I654c1c20e97a80ea79c8eb864445153ce91950bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/275852
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
fixedbugs/bug13343.go:10:12: error: initialization expressions for ‘b’ and ‘c’ depend upon each other
fixedbugs/bug13343.go:11:9: note: ‘c’ defined here
fixedbugs/bug13343.go:11:9: error: initialization expression for ‘c’ depends upon itself
fixedbugs/bug13343.go:11:9: error: initialization expressions for ‘c’ and ‘b’ depend upon each other
fixedbugs/bug13343.go:10:12: note: ‘b’ defined here
fixedbugs/issue10700.dir/test.go:24:10: error: reference to method ‘Do’ in type that is pointer to interface, not interface
fixedbugs/issue10700.dir/test.go:25:10: error: reference to method ‘do’ in type that is pointer to interface, not interface
fixedbugs/issue10700.dir/test.go:27:10: error: reference to method ‘Dont’ in type that is pointer to interface, not interface
fixedbugs/issue10700.dir/test.go:28:13: error: reference to undefined field or method ‘Dont’
fixedbugs/issue10700.dir/test.go:31:10: error: reference to undefined field or method ‘do’
fixedbugs/issue10700.dir/test.go:33:13: error: reference to undefined field or method ‘do’
fixedbugs/issue10700.dir/test.go:34:10: error: reference to undefined field or method ‘Dont’
fixedbugs/issue10700.dir/test.go:35:13: error: reference to undefined field or method ‘Dont’
fixedbugs/issue10700.dir/test.go:37:10: error: reference to method ‘Do’ in type that is pointer to interface, not interface
fixedbugs/issue10700.dir/test.go:38:10: error: reference to method ‘do’ in type that is pointer to interface, not interface
fixedbugs/issue10700.dir/test.go:40:13: error: reference to undefined field or method ‘do’
fixedbugs/issue10700.dir/test.go:41:10: error: reference to method ‘Dont’ in type that is pointer to interface, not interface
fixedbugs/issue10700.dir/test.go:42:13: error: reference to undefined field or method ‘Dont’
fixedbugs/issue10700.dir/test.go:43:10: error: reference to method ‘secret’ in type that is pointer to interface, not interface
fixedbugs/issue10700.dir/test.go:44:13: error: reference to unexported field or method ‘secret’
fixedbugs/issue10975.go:13:9: error: interface contains embedded non-interface
fixedbugs/issue11326.go:26:17: error: floating-point constant overflow
fixedbugs/issue11326.go:27:17: error: floating-point constant overflow
fixedbugs/issue11326.go:28:17: error: floating-point constant overflow
fixedbugs/issue11361.go:9:11: error: import file ‘fmt’ not found
fixedbugs/issue11361.go:11:11: error: reference to undefined name ‘fmt’
fixedbugs/issue11371.go:12:15: error: floating-point constant truncated to integer
fixedbugs/issue11371.go:13:15: error: integer constant overflow
fixedbugs/issue11371.go:17:15: error: floating-point constant truncated to integer
fixedbugs/issue11590.go:9:17: error: integer constant overflow
fixedbugs/issue11590.go:9:17: error: integer constant overflow
fixedbugs/issue11590.go:10:22: error: complex real part overflow
fixedbugs/issue11590.go:10:22: error: complex real part overflow
fixedbugs/issue11590.go:11:23: error: complex real part overflow
fixedbugs/issue11590.go:11:23: error: complex real part overflow
fixedbugs/issue11590.go:9:19: error: integer constant overflow
fixedbugs/issue11590.go:10:24: error: complex real part overflow
fixedbugs/issue11590.go:11:25: error: complex real part overflow
fixedbugs/issue11610.go:11:7: error: import path is empty
fixedbugs/issue11610.go:12:4: error: invalid character 0x3f in input file
fixedbugs/issue11610.go:14:1: error: expected identifier
fixedbugs/issue11610.go:14:1: error: expected type
fixedbugs/issue11614.go:14:9: error: interface contains embedded non-interface
fixedbugs/issue13248.go:13:1: error: expected operand
fixedbugs/issue13248.go:13:1: error: missing ‘)’
fixedbugs/issue13248.go:12:5: error: reference to undefined name ‘foo’
fixedbugs/issue13266.go:10:8: error: package name must be an identifier
fixedbugs/issue13266.go:10:8: error: expected ‘;’ or newline after package clause
fixedbugs/issue13266.go:10:8: error: expected declaration
fixedbugs/issue13273.go:50:18: error: expected ‘chan’
fixedbugs/issue13273.go:53:24: error: expected ‘chan’
fixedbugs/issue13274.go:11:58: error: expected ‘}’
fixedbugs/issue13365.go:14:19: error: index expression is negative
fixedbugs/issue13365.go:15:21: error: index expression is negative
fixedbugs/issue13365.go:16:22: error: index expression is negative
fixedbugs/issue13365.go:19:13: error: some element keys in composite literal are out of range
fixedbugs/issue13365.go:22:19: error: incompatible type for element 1 in composite literal
fixedbugs/issue13365.go:23:21: error: incompatible type for element 1 in composite literal
fixedbugs/issue13365.go:24:22: error: incompatible type for element 1 in composite literal
fixedbugs/issue13415.go:14:5: error: redefinition of ‘x’
fixedbugs/issue13415.go:14:5: note: previous definition of ‘x’ was here
fixedbugs/issue13415.go:14:5: error: ‘x’ declared but not used
fixedbugs/issue13471.go:12:25: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:13:25: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:14:25: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:15:24: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:16:23: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:18:26: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:19:26: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:20:26: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:21:25: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:22:24: error: floating-point constant truncated to integer
fixedbugs/issue13471.go:24:24: error: floating-point constant truncated to integer
fixedbugs/issue13821b.go:18:12: error: incompatible types in binary expression
fixedbugs/issue13821b.go:19:13: error: incompatible types in binary expression
fixedbugs/issue13821b.go:20:13: error: incompatible types in binary expression
fixedbugs/issue13821b.go:21:13: error: incompatible types in binary expression
fixedbugs/issue13821b.go:22:13: error: incompatible types in binary expression
fixedbugs/issue13821b.go:24:12: error: incompatible types in binary expression
fixedbugs/issue14006.go:24:18: error: expected ‘;’ or ‘}’ or newline
fixedbugs/issue14006.go:30:18: error: expected ‘;’ or ‘}’ or newline
fixedbugs/issue14006.go:37:22: error: expected ‘;’ or ‘}’ or newline
fixedbugs/issue14006.go:43:22: error: expected ‘;’ or ‘}’ or newline
fixedbugs/issue14006.go:59:17: note: previous definition of ‘labelname’ was here
fixedbugs/issue14006.go:64:17: error: label ‘labelname’ already defined
fixedbugs/issue14006.go:24:17: error: value computed is not used
fixedbugs/issue14006.go:30:17: error: value computed is not used
fixedbugs/issue14006.go:37:20: error: value computed is not used
fixedbugs/issue14006.go:43:20: error: value computed is not used
fixedbugs/issue14006.go:59:17: error: label ‘labelname’ defined and not used
fixedbugs/issue14010.go:13:14: error: invalid left hand side of assignment
fixedbugs/issue14010.go:14:14: error: invalid left hand side of assignment
fixedbugs/issue14010.go:14:9: error: invalid use of type
fixedbugs/issue14321.go:30:10: error: method ‘F’ is ambiguous in type ‘C’
fixedbugs/issue14321.go:31:10: error: ‘G’ is ambiguous via ‘A’ and ‘B’
fixedbugs/issue14321.go:33:10: error: type ‘C’ has no method ‘I’
fixedbugs/issue8183.go:12:14: error: integer constant overflow
fixedbugs/issue9036.go:21:12: error: invalid prefix for floating constant
fixedbugs/issue9036.go:22:12: error: invalid prefix for floating constant
fixedbugs/issue9076.go:14:5: error: incompatible type in initialization (cannot use type uintptr as type int32)
fixedbugs/issue9076.go:15:5: error: incompatible type in initialization (cannot use type uintptr as type int32)
For issue9083.go avoid an error about a variable that is set but not used.
fixedbugs/issue9370.go:105:13: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:106:13: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:107:13: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:108:13: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:109:13: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:110:13: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:112:18: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:113:18: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:114:18: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:115:18: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:116:18: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:117:18: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:119:13: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:119:18: error: cannot use ‘_’ as value
fixedbugs/issue9370.go:36:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:39:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:43:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:46:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:50:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:53:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:56:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:57:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:58:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:59:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:60:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:61:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:65:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:68:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:70:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:71:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:72:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:73:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:74:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:75:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:77:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:78:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:79:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:80:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:81:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:82:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:84:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:85:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:86:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:87:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:88:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:89:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:91:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:92:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:93:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:94:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:95:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:96:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:98:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:99:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:100:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:101:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:102:15: error: invalid operation (func can only be compared to nil)
fixedbugs/issue9370.go:103:15: error: invalid comparison of non-ordered type
fixedbugs/issue9370.go:121:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:122:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:123:15: error: incompatible types in binary expression
fixedbugs/issue9370.go:124:15: error: incompatible types in binary expression
Change-Id: I4089de4919112b08f5f2bbec20f84fcc7dbe3955
Reviewed-on: https://go-review.googlesource.com/c/go/+/276832
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Done with:
go get -d golang.org/x/net@latest
go mod tidy
go mod vendor
go generate -run bundle std
The cmd module was updated as well, but go mod tidy undoes the change
because the x/net module doesn't contribute any packages to cmd module.
cmd/internal/moddeps.TestDependencyVersionsConsistent is happy with it:
// It's ok if there are undetected differences in modules that do not
// provide imported packages: we will not have to pull in any backports of
// fixes to those modules anyway.
Fixes#31192.
Updates #42498.
Change-Id: If303c9a7aa2ce8c2553fcb1ced7fccc9e6652ad6
Reviewed-on: https://go-review.googlesource.com/c/go/+/277012
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
When the -linkshared build mode is in effect, the Go command passes
the "-linkshared" command line option to the compiler so as to insure
special handling for things like builtin functions (which may appear
in a shared library and not the main executable). This patch extends
this behavior to the assembler, since the assembler may also wind up
referencing builtins when emitting a stack-split prolog.
Fixes#43107.
Change-Id: I56eaded79789b083f3c3d800fb140353dee33ba9
Reviewed-on: https://go-review.googlesource.com/c/go/+/276932
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When external linking, in case that the external linker generates
a code signature with a different size (e.g. as it uses a
different identifier), truncate the file after rewriting the code
signature, to make sure that no bytes after the signature (which
will invalidate the signature).
Fixes#43105.
Change-Id: I732f949fedd6de42d9f3cf6d017f7ba3f4e59e7a
Reviewed-on: https://go-review.googlesource.com/c/go/+/276693
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Use the Key position of a syntax.KeyValueExpr (not the position of the
":") when reporting an error for a missing key.
(In go/types, the KeyValueExpr position is the start of the expression
not the ":", so there this works as expected.)
Change-Id: I74147d245927847274cf4e53b4f03dbb5110c324
Reviewed-on: https://go-review.googlesource.com/c/go/+/276813
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
os.ReadDir is a replacement for ioutil.ReadDir that returns
a slice of fs.DirEntry instead of fs.FileInfo, meaning it is the
more efficient form.
This CL updates call sites throughout the Go source tree
wherever possible. As usual, code built using the Go 1.4
bootstrap toolchain is not included. There is also a use in
go/build that appears in the public API and can't be changed,
at least not without additional changes.
Fixes#42026.
Change-Id: Icfc9dd52c6045020f6830e22c72128499462d561
Reviewed-on: https://go-review.googlesource.com/c/go/+/266366
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
As part of #42026, these helpers from io/ioutil were moved to os.
(ioutil.TempFile and TempDir became os.CreateTemp and MkdirTemp.)
Update the Go tree to use the preferred names.
As usual, code compiled with the Go 1.4 bootstrap toolchain
and code vendored from other sources is excluded.
ReadDir changes are in a separate CL, because they are not a
simple search and replace.
For #42026.
Change-Id: If318df0216d57e95ea0c4093b89f65e5b0ababb3
Reviewed-on: https://go-review.googlesource.com/c/go/+/266365
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL adds Ident, which will eventually replace *Name and *PkgName
within the AST for representing uses of declared names. (Originally, I
intended to call it "IdentExpr", but neither go/ast nor
cmd/compile/internal/syntax include the "Expr" suffix for their
respective types.)
To start, this CL converts two uses of *Name to *Ident: the tag
identifier in a TypeSwitchGuard (which doesn't actually declare a
variable by itself), and the not-yet-known placeholder ONONAME
returned by oldname to stand-in for identifiers that might be declared
later in the package.
The TypeSwitchGuard's Name's Used flag was previously used for
detecting whether none of the per-clause variables were used. To avoid
bloating all Idents for this rare use, a "Used" bool is added to
TypeSwitchGuard instead. Eventually it could maybe be packed into
miniNode.bits, but for now this is good enough.
Passes buildall w/ toolstash -cmp.
Change-Id: I393284d86757cbbebd26e1320c7354e2bdcb30b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/276113
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Based on actually using the IR when prototyping adding
type assertions, a few changes to improve it:
- Merge DeferStmt and GoStmt, since they are variants of one thing.
- Introduce LogicalExpr for && and ||, since they (alone) need an init list before Y.
- Add an explicit op to various constructors to make them easier to use.
- Add separate StructKeyExpr - it stores Value in a different abstract location (Left) than KeyExpr (Right).
- Export all fields for use by rewrites (and later reflection).
Passes buildall w/ toolstash -cmp.
Change-Id: Iefbff2386d2bb9ef511ce53b7f92ff6c709dc991
Reviewed-on: https://go-review.googlesource.com/c/go/+/275883
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
ir.Dump is the final (I think!) piece of the compiler that was walking
nodes using Left, Right etc without knowing what they meant.
This CL uses reflection to walk nodes without knowing what they mean instead.
One benefit is that we can print actual meanings (field names).
While we are here, I could not resist fixing a long-standing mental TODO:
make the line number more clearly a line number. I've forgotten where the
line number is in the dumps far too many times in the last decade.
As a small example, here is a fragment of go tool compile -W test/235.go:
. FOR l(28) tc(1)
. . LT-init
. . . AS l(28) tc(1)
. . . . NAME-main..autotmp_4 l(28) x(0) class(PAUTO) esc(N) tc(1) assigned used int
. . . . LEN l(28) tc(1) int
. . . . . NAME-main.xs g(2) l(26) x(0) class(PPARAM) esc(no) tc(1) used SLICE-[]uint64
. . LT l(28) tc(1) hascall bool
. . . NAME-main.i g(4) l(28) x(0) class(PAUTO) esc(no) tc(1) assigned used int
. . . NAME-main..autotmp_4 l(28) x(0) class(PAUTO) esc(N) tc(1) assigned used int
. . BLOCK l(28)
. . BLOCK-list
. . . ASOP-ADD l(28) tc(1) implicit(true) int
. . . . NAME-main.i g(4) l(28) x(0) class(PAUTO) esc(no) tc(1) assigned used int
. . . . LITERAL-1 l(28) tc(1) int
. FOR-body
. . VARKILL l(28) tc(1)
. . . NAME-main..autotmp_4 l(28) x(0) class(PAUTO) esc(N) tc(1) assigned used int
. . IF l(29) tc(1)
. . . LT l(29) tc(1) bool
. . . . INDEX l(29) tc(1) uint64
. . . . . NAME-main.xs g(2) l(26) x(0) class(PPARAM) esc(no) tc(1) used SLICE-[]uint64
. . . . . NAME-main.i g(4) l(28) x(0) class(PAUTO) esc(no) tc(1) assigned used int
. . . . NAME-main.m g(3) l(27) x(0) class(PAUTO) esc(no) tc(1) assigned used uint64
. . IF-body
. . . AS l(30) tc(1)
. . . . NAME-main.m g(3) l(27) x(0) class(PAUTO) esc(no) tc(1) assigned used uint64
. . . . INDEX l(30) tc(1) uint64
. . . . . NAME-main.xs g(2) l(26) x(0) class(PPARAM) esc(no) tc(1) used SLICE-[]uint64
. . . . . NAME-main.i g(4) l(28) x(0) class(PAUTO) esc(no) tc(1) assigned used int
and here it is after this CL:
. FOR tc(1) # 235.go:28
. FOR-Cond
. . LT-init
. . . AS tc(1) # 235.go:28
. . . . NAME-main..autotmp_4 x(0) class(PAUTO) esc(N) tc(1) assigned used int # 235.go:28
. . . . LEN tc(1) int # 235.go:28 int
. . . . . NAME-main.xs g(2) x(0) class(PPARAM) esc(no) tc(1) used SLICE-[]uint64 # 235.go:26
. . LT tc(1) hascall bool # 235.go:28 bool
. . . NAME-main.i g(4) x(0) class(PAUTO) esc(no) tc(1) assigned used int # 235.go:28
. . . NAME-main..autotmp_4 x(0) class(PAUTO) esc(N) tc(1) assigned used int # 235.go:28
. FOR-Post
. . BLOCK # 235.go:28
. . BLOCK-List
. . . ASOP-ADD tc(1) implicit(true) int # 235.go:28 int
. . . . NAME-main.i g(4) x(0) class(PAUTO) esc(no) tc(1) assigned used int # 235.go:28
. . . . LITERAL-1 tc(1) int # 235.go:28
. FOR-Body
. . VARKILL tc(1) # 235.go:28
. . . NAME-main..autotmp_4 x(0) class(PAUTO) esc(N) tc(1) assigned used int # 235.go:28
. . IF tc(1) # 235.go:29
. . IF-Cond
. . . LT tc(1) bool # 235.go:29 bool
. . . . INDEX tc(1) uint64 # 235.go:29 uint64
. . . . . NAME-main.xs g(2) x(0) class(PPARAM) esc(no) tc(1) used SLICE-[]uint64 # 235.go:26
. . . . . NAME-main.i g(4) x(0) class(PAUTO) esc(no) tc(1) assigned used int # 235.go:28
. . . . NAME-main.m g(3) x(0) class(PAUTO) esc(no) tc(1) assigned used uint64 # 235.go:27
. . IF-Body
. . . AS tc(1) # 235.go:30
. . . . NAME-main.m g(3) x(0) class(PAUTO) esc(no) tc(1) assigned used uint64 # 235.go:27
. . . . INDEX tc(1) uint64 # 235.go:30 uint64
. . . . . NAME-main.xs g(2) x(0) class(PPARAM) esc(no) tc(1) used SLICE-[]uint64 # 235.go:26
. . . . . NAME-main.i g(4) x(0) class(PAUTO) esc(no) tc(1) assigned used int # 235.go:28
Note in particular the clear marking of FOR-Cond, FOR-Post, FOR-Body compared to the original.
The only changes to a few test files are the improved field name lines, and of course the line numbers.
Passes buildall w/ toolstash -cmp.
Change-Id: I5b654d9d8ee898976d4c387742ea688a082bac78
Reviewed-on: https://go-review.googlesource.com/c/go/+/275785
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
go test sets the working directory to that of the package being tested,
so opening one of the package source files can be done in a simpler way.
This also allows the test to run in more environments, for example when
GOROOT_FINAL¹ is set.
Also remove the testenv.HasSrc-like check for Go source. The doc.go
file is a part of the package being built and tested, so it's expected
to be available. If it's important for this test to handle when a test
binary is built with go test -c and executed elsewhere without package
source files, something more than testenv.HasSrc would be needed.
¹ https://golang.org/cmd/go/#hdr-Environment_variablesFixes#43085.
Change-Id: Ie6ade395a8fc7beebdadbad6f4873800138dfc26
Reviewed-on: https://go-review.googlesource.com/c/go/+/276452
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Issue #41600 fixed the issue when a second request canceled a connection
while the first request was still in roundTrip.
This uncovered a second issue where a request was being canceled (in
roundtrip) but the connection was put back into the idle pool for a
subsequent request.
The fix is the similar except its now in readLoop instead of roundTrip.
A persistent connection is only added back if it successfully removed
the cancel function; otherwise we know the roundTrip has started
cancelRequest.
Fixes#42942
Change-Id: Ia56add20880ccd0c1ab812d380d8628e45f6f44c
Reviewed-on: https://go-review.googlesource.com/c/go/+/274973
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Damien Neil <dneil@google.com>
Reviewed-by: Damien Neil <dneil@google.com>
This fixes the unexpected growth of stack in child process, which
is caused by stack checking code in runtime.sigfillset called from
runtime.sigset while clearing the signal handlers in child process.
The redundant stack checking code is generated due to missing
'//go:nosplit' directive that should be annotated for
runtime.sigfillset.
Fixes#43066
Updates #21314
Change-Id: I9483a962a4b0747074313991841e2440ee32198c
Reviewed-on: https://go-review.googlesource.com/c/go/+/276173
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
With the plurality of CLs importing dev.go2go changes it's getting hard
to track all of the code review comments that were deferred for later
consideration. Add some TODOs to capture these comments in the source,
so that they may be more easily located.
Change-Id: I5caf085fec11ca8992b7affe6feb0a7aa202f21f
Reviewed-on: https://go-review.googlesource.com/c/go/+/276254
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 is a port of CL 275517 from the dev.typeparams branch, to fix the
positioning of error messages for invalid const init expressions that
are inherited.
Differences from CL 275517:
+ The inherited flag is added to the constDecl intermediate
representation.
+ The errpos override is made a positioner, the internal interface
used by go/types to capture error position and span. For const decls
errpos is just set to a singular point, but using positioner is
correct and causes span start and end positions to also be
overridden.
+ Test cases are updated to assert on just 'overflows', as the go/types
error message is, for example, "cannot use 255 + iota (untyped int
constant 256) as byte value in constant declaration (overflows)".
This is more verbose than the compiler's "constant 256 overflows
byte", but changing that is out of scope.
Fixes#42991
Change-Id: I0a71d2290f7fff5513f2a6e49b83e6f0f4da30e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/276172
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Import the Type changes from the dev.go2go branch, as well as a minimal
set of related changes to the Checker code so that tests pass. This
involved making some decisions about which functionality to import, with
some parts of the Type API (for example instance.expand) carved out as
they pulled in too many additional changes.
Minimal changes were made from the dev.go2go version. Notably:
+ The aType helper struct is removed. It could have been removed in CL
274852 but was missed.
+ writeTParamList was cleaned up for the bracketed parameter style.
+ Some interface iteration functions were simplified.
One observation along the way is that, especially with converter methods
removed from the Type interface, we should probably avoid storing the
Checker on Type instances for lazy evaluation. If a function is only
valid during a checking pass, we should make it a method on Checker
instead of a method on the Type instance. Rather than do this now, which
would make later changes harder to import, I left a couple TODOs to
address this later.
Change-Id: Ie669224614269874474d87e46c68216cb06b6d0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/275441
Reviewed-by: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
This commit adds exactly two "n := n.(*ir.Name)" statements, that are
each immediately preceded by a "case ir.ONAME:" clause in an n.Op()
switch. The rest of the changes are simply replacing "ir.Node" to
"*ir.Name" and removing now unnecessary "n.(*ir.Name)" type
assertions, exposing the latent typing details.
Passes buildall w/ toolstash -cmp.
Updates #42982.
Change-Id: I8ea3bbb7ddf0c7192245cafa49a19c0e7a556a39
Reviewed-on: https://go-review.googlesource.com/c/go/+/275791
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Now that the only remaining ir.Node implementation that is stored
(directly) into ssa.Aux, we can rewrite all of the conversions between
ir.Node and ssa.Aux to use *ir.Name instead.
rf doesn't have a way to rewrite the type switch case clauses, so we
just use sed instead. There's only a handful, and they're the only
times that "case ir.Node" appears anyway.
The next CL will move the tag method declarations so that ir.Node no
longer implements ssa.Aux.
Passes buildall w/ toolstash -cmp.
Updates #42982.
[git-generate]
cd src/cmd/compile/internal
sed -i -e 's/case ir.Node/case *ir.Name/' gc/plive.go */ssa.go
cd ssa
rf '
ex . ../gc {
import "cmd/compile/internal/ir"
var v *Value
v.Aux.(ir.Node) -> v.Aux.(*ir.Name)
var n ir.Node
var asAux func(Aux)
strict n # only match ir.Node-typed expressions; not *ir.Name
implicit asAux # match implicit assignments to ssa.Aux
asAux(n) -> n.(*ir.Name)
}
'
Change-Id: I3206ef5f12a7cfa37c5fecc67a1ca02ea4d52b32
Reviewed-on: https://go-review.googlesource.com/c/go/+/275789
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
OpFwdRef is the only SSA value that needs the ability to store an
arbitrary ir.Node in its Aux field. Every other SSA value always uses
an *ir.Name.
This CL introduces FwdRefAux, which wraps an ir.Node and implements
the ssa.Aux tag interface, so that a subsequent refactoring can change
ir.Node to not implement ssa.Aux.
Passes buildall w/ toolstash -cmp.
Updates #42982.
Change-Id: Id1475b28847579573cd376e82f28761d84cd1c23
Reviewed-on: https://go-review.googlesource.com/c/go/+/275788
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Position independent code expects that R25 (aka $t9) contains the address of the
called function. As such, use R25 when calling from sigfwd.
Change-Id: I66b2b9bfa1f1bb983c7385eb2eaa19d9cd87d9fb
Reviewed-on: https://go-review.googlesource.com/c/go/+/275893
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
It's currently hard to automate refactorings around the Value.Aux
field, because we don't have any static typing information for it.
Adding a tag interface will make subsequent CLs easier and safer.
Passes buildall w/ toolstash -cmp.
Updates #42982.
Change-Id: I41ae8e411a66bda3195a0957b60c2fe8a8002893
Reviewed-on: https://go-review.googlesource.com/c/go/+/275756
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
The plan was always to export them once we remove the getters
and setters, but do it a bit early, with _ suffixes as needed, so that
the reflection-based ir.Dump can access the fields.
Passes buildall w/ toolstash -cmp.
[git-generate]
cd src/cmd/compile/internal/ir
rf '
mv AddStringExpr.list AddStringExpr.List_
mv BlockStmt.list BlockStmt.List_
mv CallExpr.body CallExpr.Body_
mv CaseStmt.list CaseStmt.List_
mv CaseStmt.body CaseStmt.Body_
mv ClosureExpr.fn ClosureExpr.Func_
mv CompLitExpr.list CompLitExpr.List_
mv ForStmt.body ForStmt.Body_
mv Func.body Func.Body_
mv IfStmt.body IfStmt.Body_
mv InlinedCallExpr.body InlinedCallExpr.Body_
mv RangeStmt.body RangeStmt.Body_
mv SliceExpr.list SliceExpr.List_
mv SliceHeaderExpr.lenCap SliceHeaderExpr.LenCap_
mv TypeSwitchGuard.name TypeSwitchGuard.Name_
'
go generate
Change-Id: I06e65920cecbcc51bea2254f52fcd7d5c5d0dc90
Reviewed-on: https://go-review.googlesource.com/c/go/+/275784
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The next CL will rename Func.body to Func.Body_.
At some point in the future we will rename it to Func.Body.
Make the generator not get confused.
Passes buildall w/ toolstash -cmp.
Change-Id: Iee3f4915889a8287377bf3304d5b9250a909477e
Reviewed-on: https://go-review.googlesource.com/c/go/+/275783
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
On ir.Node, ir.Nodes, and ir.Op, # is ignored, so %#v is %v.
On ir.Node, %S is the same as %v.
On types.Type, # is ignored, so %#L is %L, %#v is %v.
On types.Type, 0 is ignored, so %0S is %S.
Rewrite all these using go test cmd/compile -r, plus a
few multiline formats mentioning %0S on types updated by hand.
Now the formats used in the compiler match the documentation
for the format methods, a minor miracle.
Passes buildall w/ toolstash -cmp.
Change-Id: I3d4a3fae543145a68da13eede91166632c5b1ceb
Reviewed-on: https://go-review.googlesource.com/c/go/+/275782
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The format map is going to keep growing as we add more use of
concrete node types. Stop that by reporting all Node implementations
as Node.
Also, there's little point to reporting uses of %v, %p, %T, nor to reporting
formatting of basic types like int and []byte. Remove those too.
(Vet takes care of mistakes involving basic types now.)
Passes buildall w/ toolstash -cmp.
Change-Id: Ia9fb39b401c29bf0c76ffebaa24836c70acd773f
Reviewed-on: https://go-review.googlesource.com/c/go/+/275781
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Some cleanup left over from moving the Type and Sym formatting to types.
And then document what the type formats are, now that it's clear.
Passes buildall w/ toolstash -cmp.
Change-Id: I35cb8978f1627db1056cb8ab343ce6ba6c99afad
Reviewed-on: https://go-review.googlesource.com/c/go/+/275780
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Move the printing of types.Type and types.Sym out of ir
into package types, where it properly belongs. This wasn't
done originally (when the code was in gc) because the Type
and Sym printing was a bit tangled up with the Node printing.
But now they are untangled and can move into the correct
package.
This CL is automatically generated.
A followup CL will clean up a little bit more by hand.
Passes buildall w/ toolstash -cmp.
[git-generate]
cd src/cmd/compile/internal/ir
rf '
mv FmtMode fmtMode
mv FErr fmtGo
mv FDbg fmtDebug
mv FTypeId fmtTypeID
mv FTypeIdName fmtTypeIDName
mv methodSymName SymMethodName
mv BuiltinPkg LocalPkg BlankSym OrigSym NumImport \
fmtMode fmtGo symFormat sconv sconv2 symfmt SymMethodName \
BasicTypeNames fmtBufferPool InstallTypeFormats typeFormat tconv tconv2 fldconv FmtConst \
typefmt.go
mv typefmt.go cmd/compile/internal/types
'
cd ../types
mv typefmt.go fmt.go
Change-Id: I6f3fd818323733ab8446f00594937c1628760b27
Reviewed-on: https://go-review.googlesource.com/c/go/+/275779
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
It turns out that the FmtFlag is really only tracking the FmtLong and FmtShort bits,
and the others simply mirror the state of the FmtMode and are copied out and
back in repeatedly.
Simplify to FmtFlag being the verb itself ('S', 'L', or 'v').
Now there is only one formatting enumeration, making it a bit
easier to understand what's going on.
Passes buildall w/ toolstash -cmp.
Change-Id: I85bde2183eb22228fcf46d19d003401d588d9825
Reviewed-on: https://go-review.googlesource.com/c/go/+/275778
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This code is now hardly used and not worth the complexity.
It also tangles together Nodes and Types in a way that keeps
this code in package ir instead of package types.
Passes buildall w/ toolstash -cmp.
Change-Id: I2e829c1f6b602acbdc8ab4aac3b798f9ded762ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/275777
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Narrow the interface between package ir and package types
to make it easier to clean up the type formatting code all in one place.
Also introduce ir.BlankSym for use by OrigSym, so that later
OrigSym can move to package types without needing to reference
a variable of type ir.Node.
Passes buildall w/ toolstash -cmp.
Change-Id: I39fa419a1c8fb3318203e31cacc8d06399deeff9
Reviewed-on: https://go-review.googlesource.com/c/go/+/275776
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
nconvFmt calls base.Fatalf if mode is anything but FErr,
proving that the only formats that matter for nodes are
plain %v, %S, and %L. And the nodes formatter can only get to %v.
(%S and %v are the same; we'll clean that up separately.)
Node and Nodes can therefore ignore mode, and all the mode
code can be removed from those implementations, removing
quite a few layers of abstraction.
Op similarly only runs in one mode and can be simplified.
Passes buildall w/ toolstash -cmp.
Change-Id: Ibfd845033e9c68181a20fb81c8f3dd428463920a
Reviewed-on: https://go-review.googlesource.com/c/go/+/275775
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The Node printing code is tangled up due to the multiple printing modes.
Split out the Dump mode into its own code, which clarifies it considerably.
We are going to have to change the code for the new Node representations,
so it is nice to have it in an understandable form first.
The output of Dump is unchanged except for the removal of spurious
mid-Dump blank lines that have been printed for a while but don't
really make sense and appear to be a bug.
The %+v verb on Op prints the name ("ADD" not "+"), matching
%+v on Node and %+v on Nodes to get Dump and DumpList formats.
Passes buildall w/ toolstash -cmp.
Change-Id: I07f0f245859f1f785e10bdd671855ca43c51b545
Reviewed-on: https://go-review.googlesource.com/c/go/+/275774
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This code is a few layer of abstraction stacked up on top
of each other, and they're hard to see all at the same time
because the file is pretty mixed up. As much as I try to avoid
code rearrangement to keep history, this one is long overdue.
A followup CL will cut out some of the layers, and the diff will be
much clearer what's going on with the code ordered with
callers near callees, as it is now.
Passes buildall w/ toolstash -cmp.
Change-Id: Iffc49d43cf4be9fab47e2dd59a5f98930573350f
Reviewed-on: https://go-review.googlesource.com/c/go/+/275773
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This is unreachable code - the only way short can be true is
if verb == 'S', but jconv is only called when verb == 'j'.
Simplify by removing.
Passes buildall w/ toolstash -cmp.
Change-Id: I27bd38319f72215069e940b320b5c82608e2651a
Reviewed-on: https://go-review.googlesource.com/c/go/+/275772
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Ending typecheck1 in the switch makes it safe for each case
to do an appropriate type assertion. The main change is dropping
the computation of "ok" and using the syntax nodes themselves
to decide what's OK.
Passes buildall w/ toolstash -cmp.
Change-Id: I2a1873a51e3f1194d74bb87a6653cb9857a02a1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/275444
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Add Node method generator by Matthew Dempsky,
lightly adapted to account for a few special cases.
No more writing these by hand.
Change-Id: I6933b895df666928b851bddf81b994799c0c97f7
Reviewed-on: https://go-review.googlesource.com/c/go/+/275434
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The gofrontend code would in some circumstances incorrectly generate a
type descriptor for an alias type, causing the type to fail to be
equal to the unaliased type.
Change-Id: I47d33b0bfde3c72a9a186049539732bdd5a6a96e
Reviewed-on: https://go-review.googlesource.com/c/go/+/275632
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In the past, we had a lot of trouble with misusing *types.Sym
throughout the frontend, so I tried to push us towards always passing
around ONAMEs instead. But for constructing and writing out the symbol
indexes for the indexed export data, keying by *types.Sym is exactly
what we want.
Passes buildall w/ toolstash -cmp.
Updates #42982.
Change-Id: Idd8f1fb057d75a52a34ebc7788d9332fb49caf8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/275755
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Similar to the previous CL, the only two users of NodeQueue only
needed it for tracking objects, not arbitrary AST nodes. So change
it's signature to use *Name instead of Node.
This does require a tweak to the nowritebarrierrec checker, because
previously it was pushing the ODCLFUNC *Func pointers into the queue,
whereas now we push the ONAME/PFUNC *Name pointers instead. However,
it's trivial and safe to flip between them.
Also, this changes a handful of export-related code from Node to
*Name, to avoid introducing type assertions within iexport.go.
Passes buildall w/ toolstash -cmp.
Updates #42982.
Change-Id: I867f9752121509fc3da753978c6a41d5015bc0ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/275753
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The only user of NodeSet (computing initialization dependencies) only
needs to store *Names in this structure. So change its definition to
match that need, and update the code in initorder.go accordingly.
Passes buildall w/ toolstash -cmp.
Updates #42982.
Change-Id: I181a8aaf9bc71e88f4ac009c4f381a718080e48f
Reviewed-on: https://go-review.googlesource.com/c/go/+/275752
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
According to [1], this function returns NULL when it errors, rather than
INVALID_HANDLE_VALUE, which other Win32 functions return. This was
pointed out in CL 273446 for the x/sys package, and this patch here
cleans it up for the syscall package and updates the vendored x/sys
package using the usual `go get/go mod vendor` dance. The function is
currently in use by crypto/x509/root_windows.go, which calls
CertOpenStore(CERT_STORE_PROV_MEMORY), which I assume can fail under OOM
or other weird conditions. Quick reversing indicates that [1] is
correct, as there's a `xor eax, eax` in the error paths of the function
just before jumping to the epilogue.
[1] https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-certopenstore#return-value
Change-Id: I77c0b0319c13313212f8710785252c494da56ed5
Reviewed-on: https://go-review.googlesource.com/c/go/+/273827
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Currently, because we use the same *Name to represent both declaration
and uses of an object, it's ambiguous what "n1 == n2" means when
comparing two Node values. It can mean any of: Are these the same
syntactic element? Is n1 a use of declared variable n2? Are n1 and n2
both uses of the same declared variable?
We'd like to introduce a new IdentExpr node to replace use of Name
within the AST, but that means those three cases need to be handled
differently. The first case needs to stay "n1 == n2", but the other
cases need to become "n1.Name() == n2" and "n1.Name() == n2.Name()",
respectively. ("n1.Name() == n2.Name()" also currently works for the
second case, but eventually we'll want to get rid of the Name.Name
method.)
This CL introduces helper functions SameSource and Uses to handle
these cases. It also introduces DeclaredBy, which is another somewhat
common case that the next CL introduces uses of.
Passes buildall w/ toolstash -cmp.
Updates #42990.
Change-Id: Ia816c124446e9067645d5820a8163f295968794f
Reviewed-on: https://go-review.googlesource.com/c/go/+/275305
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
The only reason for the DeepCopyNode interface was to
allow the type syntaxes to avoid being constrained by
Left, Right etc. methods. Now those are gone, so the
general traversal methods they implement (doChildren, editChildren)
do the right thing for DeepCopy.
Passes buildall w/ toolstash -cmp.
Change-Id: I54672c011114a95efabff32dbcf02e6071f91b9e
Reviewed-on: https://go-review.googlesource.com/c/go/+/275379
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
deadcode is trying to walk the statements it can find,
but it can sweep in other nodes too. Stop doing that:
only walk known statements containing statements.
Otherwise, if we put panics in expression accessors that
shouldn't be used anymore, deadcode can trip them.
deadcode would be a good candidate to rewrite using
EditChildren, but that would certainly cause toolstash
changes, since deadcode is so ad-hoc about exactly
which parts of the function it looks at. For now just
remove the general traversal and leave as is.
Passes buildall w/ toolstash -cmp.
Change-Id: I06481eb87350905597600203c4fa724d55645b46
Reviewed-on: https://go-review.googlesource.com/c/go/+/275377
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Put each node in charge of its EditChildren implementation.
This removes the final generic use of Left, SetLeft, Right, SetRight,
and so on in package ir.
Passes buildall w/ toolstash -cmp.
Change-Id: I9821cc20f5b91cc9b44eb1f386cc82f20cd6770c
Reviewed-on: https://go-review.googlesource.com/c/go/+/275376
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Put each node in charge of its DoChildren implementation.
This removes a generic use of Left, Right, and so on
in func DoChildren, heading toward removing those even from
being used in package ir.
Passes buildall w/ toolstash -cmp.
Change-Id: Ibdf56f36801217cf24549e063da0078c1820a56b
Reviewed-on: https://go-review.googlesource.com/c/go/+/275375
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Put each node in charge of making copies of its own slices.
This removes a generic use of Body, SetBody, and so on
in func Copy, heading toward removing those even from
being used in package ir.
Passes buildall w/ toolstash -cmp.
Change-Id: I249b7fe54cf72e9d2f0467b10f3f257abf9b29b9
Reviewed-on: https://go-review.googlesource.com/c/go/+/275374
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This CL rephrases the general inlining rewriter in terms of ir.EditChildren.
It is the final part of the code that was processing arbitrary nodes using
Left, SetLeft, and so on. After this CL, there should be none left except
for the implementations of DoChildren and EditChildren, which fall next.
Passes buildall w/ toolstash -cmp.
Change-Id: I9c36053360cd040710716f0b39397a80114be713
Reviewed-on: https://go-review.googlesource.com/c/go/+/275373
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This CL converts all the generic searching traversal to use ir.Find
instead of relying on direct access to Left, Right, and so on.
Passes buildall w/ toolstash -cmp.
Change-Id: I4d951aef630c00bf333f24be79565cc564694d04
Reviewed-on: https://go-review.googlesource.com/c/go/+/275372
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This CL introduces the general visitor functionality that will replace
the Left, SetLeft, Right, SetRight, etc methods in the Node interface.
For now, the CL defines the functionality in terms of those methods,
but eventually the Nodes themselves will implement DoChildren
and EditChildren and be relieved of implementing Left, SetLeft, and so on.
The CL also updates Inspect (which moved to visit.go) and DeepCopy
to use the new functionality.
The Find helper is not used in this CL but will be used in a future one.
Passes buildall w/ toolstash -cmp.
Change-Id: Id0eea654a884ab3ea25f48bd8bdd71712b5dcb44
Reviewed-on: https://go-review.googlesource.com/c/go/+/275311
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
DeepCopy is not called DeepSepCopy, so it should use Copy, not SepCopy.
Also, the old gc.treecopy, which became ir.DeepCopy, only copied
the Left, Right, and List fields - not Init, Rlist, Body - and I didn't
notice when I moved it over. A general utility function should of
course copy the whole node, so do that.
Finally, the semantics of Copy should not depend on whether a
particular child node is held directly in a field or in a slice,
so make Copy duplicate the slice backing arrays as well.
(Logically, those backing arrays are part of the node storage.)
Passes buildall w/ toolstash -cmp.
Change-Id: I18fbe3f2b40078f566ed6370684d5585052b36a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/275309
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The upcoming general iterators will process nodes in
source code order, meaning that the "then" block comes
before the "else" block. But for an if node, "then" is Body
while "else" is Rlist, and the inliner processes Rlist first.
The order of processing changes the order of inlining decisions,
which can affect which functions are inlined, but in general
won't affect much. (It's not like we know that we should prefer
to inline functions in else bodies over then bodies.)
Swapping these is not safe for toolstash -cmp.
Doing it in a separate CL lets the upcoming CLs all be toolstash-safe.
Change-Id: Id16172849239b0564930d2bbff1260ad6d03d5ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/275308
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Sub provides a convenient way to refer to a subdirectory
automatically in future operations, like Unix's chdir(2).
The CL also includes updates to fstest to check Sub implementations.
As part of updating fstest, I changed the meaning of TestFS's
expected list to introduce a special case: if you list no expected files,
that means the FS must be empty. In general it's OK not to list all
the expected files, but if you list none, that's almost certainly a
mistake - if your FS were broken and empty, you wouldn't find out.
Making no expected files mean "must be empty" makes the mistake
less likely - if your file system ever worked, then your test will keep
it working.
That change found a testing bug: embedtest was making exactly
that mistake.
Fixes#42322.
Change-Id: I63fd4aa866b30061a0e51ca9a1927e576d6ec41e
Reviewed-on: https://go-review.googlesource.com/c/go/+/274856
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This CL consolidates and cleans up fmt.go's logic for skipping past
Nodes introduced during typechecking. This allows eliminating SetOrig
on ConvExpr and Name. Also changes ConstExpr.SetOrig to a panic for
good measure.
The only remaining SetOrig uses now are for rewriting multi-value
"f(g())" calls and "return g()" statements, and type-checking
composite literals. It should be possible to eliminate both of those
as well.
Passes buildall w/ toolstash -cmp.
Change-Id: I478aea1a17dfb7a784293b930bf9081637eb2d7a
Reviewed-on: https://go-review.googlesource.com/c/go/+/275179
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Replace existing ad-hoc file exclusion mechanism with list of
excluded files; i.e., files for which the compiler with -G
option doesn't produce matching error messages yet.
Remove -G option since we now always run all passing tests.
Change-Id: I0655d2cf8bc135b3f50b1a811b8f49090c427580
Reviewed-on: https://go-review.googlesource.com/c/go/+/275212
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An address of offset(SP) may point to the callee args area, and
may be used to move things into/out of the args/results. If an
address like that is spilled and picked up by the GC, it may hold
an arg/result live in the callee, which may not actually be live
(e.g. a result not initialized at function entry). Make sure
they are rematerializeable, so they are always short-lived and
never picked up by the GC.
This CL changes 386, PPC64, and Wasm. On AMD64 we already have
the rule (line 2159). On other architectures, we already have
similar rules like
(OffPtr [off] ptr:(SP)) => (MOVDaddr [int32(off)] ptr)
to avoid this problem. (Probably me in the past had run into
this...)
Fixes#42944.
Change-Id: Id2ec73ac08f8df1829a9a7ceb8f749d67fe86d1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/275174
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
timer.when must always be positive. addtimer and modtimer already check
that it is non-negative; we expand it to include zero. Also upgrade from
pinning bad values to throwing, as these values shouldn't be possible to
pass (except as below).
timeSleep may overflow timer.nextwhen. This would previously have been
pinned by resetForSleep, now we fix it manually.
runOneTimer may overflow timer.when when adding timer.period. Detect
this and pin to maxWhen.
addtimer is now too strict to allow TestOverflowRuntimeTimer to test an
overflowed timer. Such a timer should not be possible; to help guard
against accidental inclusion siftup / siftdown will check timers as it
goes. This has been replaced with tests for period and sleep overflows.
Change-Id: I17f9739e27ebcb20d87945c635050316fb8e9226
Reviewed-on: https://go-review.googlesource.com/c/go/+/274853
Trust: Michael Pratt <mpratt@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
timer when == 0, in the context of timer0When and timerModifiedEarliest,
is a sentinel value meaning there are no timers on the heap.
TestCheckRuntimeTimerOverflow reaching into the runtime to set a timer
to when = 0 when it is otherwise not possible breaks this invariant.
After golang.org/cl/258303, we will no longer detect and run this timer,
thus blocking any other timers lower on the heap from running. This
manifests as random timers failing to fire in other tests.
The need to set this overflowed timer to when = 0 is gone with the old
timer proc implementation, so we can simply remove it.
Fixes#42424
Change-Id: Iea32100136ad8ec1bedfa77b1e7d9ed868812838
Reviewed-on: https://go-review.googlesource.com/c/go/+/274632
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Pratt <mpratt@google.com>
It's useful to have quick access to the types.Field that a given
selector or method value expression refer to. Previously we abused Opt
for this, but couldn't do that for OCALLPART because escape analysis
uses Opt.
Now that we have more flexibility, we can simply add additional
pointer fields for this. This also allows getting rid of an unneeded
ONAME node for OCALLPART.
Passes buildall w/ toolstash -cmp.
Change-Id: I980d7bdb19abfd0b6f58a232876861b88dee1e47
Reviewed-on: https://go-review.googlesource.com/c/go/+/275034
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
The s390x assembly for shlVU does a forward copy when the shift amount s
is 0. This causes corruption of the result z when z is aliased to the
input x.
This fix removes the s390x assembly for both shlVU and shrVU so the pure
go implementations will be used.
Test cases have been added to the existing TestShiftOverlap test to
cover shift values of 0, 1 and (_W - 1).
Fixes#42838
Change-Id: I75ca0e98f3acfaa6366a26355dcd9dd82499a48b
Reviewed-on: https://go-review.googlesource.com/c/go/+/274442
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Robert Griesemer <gri@golang.org>
The next CL adds ConstExpr, which is a more memory efficient
representation for constant expressions than Name. However, currently
a bunch of Val helper methods are defined on Name. This CL changes
them into standalone functions that work with any Node.Val
implementation.
There's also an existing standalone function named Int64Val, which
takes a Type argument to specify what type of integer is expected. So
to avoid collisions, this CL renames it to IntVal.
Passes buildall w/ toolstash -cmp.
[git-generate]
cd src/cmd/compile/internal/ir
rf 'mv Int64Val IntVal'
sed -i -E -e 's/\(n \*Name\) (CanInt64|((I|Ui)nt64|Bool|String)Val)\(/\1(n Node/' name.go
cd ../gc
rf '
ex {
import "cmd/compile/internal/ir"
var n ir.Node
n.CanInt64() -> ir.CanInt64(n)
n.Int64Val() -> ir.Int64Val(n)
n.Uint64Val() -> ir.Uint64Val(n)
n.BoolVal() -> ir.BoolVal(n)
n.StringVal() -> ir.StringVal(n)
}
'
cd ../ir
rf '
mv CanInt64 Int64Val Uint64Val BoolVal StringVal val.go
rm Node.CanInt64 Node.Int64Val Node.Uint64Val Node.BoolVal Node.StringVal
'
Change-Id: I003140bda1690d770fd608bdd087e6d4ff00fb1f
Reviewed-on: https://go-review.googlesource.com/c/go/+/275032
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
With this CL, the first ~500 errorcheck tests pass when running
go run run.go -v -G
in the $GOROOT/test directory (the log output includes a few dozen
tests that are currently skipped).
Change-Id: I9eaa2319fb39a090df54f8699ddc29ffe58b1bf1
Reviewed-on: https://go-review.googlesource.com/c/go/+/274975
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
All instructions in the FMA extension on x86 are VEX prefixed.
VEX prefixed instructions generally require OSXSAVE to be enabled.
The execution of FMA instructions emitted by the Go compiler on amd64
will generate an invalid opcode exception if OSXSAVE is not enabled.
Fixes#41022
Change-Id: I49881630e7195c804110a2bd81b5bec8cac31ba8
Reviewed-on: https://go-review.googlesource.com/c/go/+/274479
Trust: Martin Möhrmann <moehrmann@google.com>
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
assign.go:59:28: error: ‘x’ repeated on left side of :=
assign.go:65:20: error: ‘a’ repeated on left side of :=
method2.go:36:11: error: reference to method ‘val’ in type that is pointer to interface, not interface
method2.go:37:11: error: reference to method ‘val’ in type that is pointer to interface, not interface
Change-Id: I8f385c75a82fae4eacf4618df8f9f65932826494
Reviewed-on: https://go-review.googlesource.com/c/go/+/274447
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
This CL improves handling of OCONVNOP nodes during ssa generation,
so it is not toolstash safe.
An OCONVNOP wrapper is necessary for the "for" condition of
certain compiled range loops, and the boolean evaluator was
not looking through them properly, generating unnecessary
temporaries. That change saved 8k of the (13 MB) go binary.
The other changes just streamline the handling of OCONVNOP
to be more like what OSTMTEXPR will be like. They have no
effect on output size but do tweak the ssa graph a little, which
causes different register decisions and therefore different output.
Change-Id: I9e1dcd413b60944e21554c3e3f2bdc9adcee7634
Reviewed-on: https://go-review.googlesource.com/c/go/+/274598
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Returning an error about integer overflow is needlessly pedantic.
The meaning of ReadForm(MaxInt64) is easily understood
(accept a lot of data) and can be implemented.
Fixes#40430.
Change-Id: I8a522033dd9a2f9ad31dd2ad82cf08d553736ab9
Reviewed-on: https://go-review.googlesource.com/c/go/+/275112
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently, for data moving, we generate an msanread of the source,
followed by an msanwrite of the destination. msanread checks
the source is initialized.
This has a problem: if the source is an aggregate type containing
alignment paddings, the padding bytes may not be thought as
initialized by MSAN. If we copy the aggregate type by value, if
it counts as a read, MSAN reports using uninitialized data. This
CL changes it to use __msan_memmove for data copying, which tells
MSAN to propagate initialized-ness but not check for it.
Caveat: technically __msan_memmove is not a public API of MSAN,
although the C compiler does generate direct calls to it.
Also, when instrumenting a load of a struct, split the
instrumentation to fields, instead of generating an msanread for
the whole struct. This skips padding bytes, which may not be
considered initialized in MSAN.
Fixes#42820.
Change-Id: Id861c8bbfd94cfcccefcc58eaf9e4eb43b4d85c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/270859
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Initial setup of types2.Info structure to provide access to types
computed by generic typechecker.
Use -G flag to control compiler phases with new typechecker:
-G (or -G=1) parsing and typechecking ony
-G -G (or -G=2) parsing, typechecking, and noding
-G=3 continue after noding (currently will run old
typechecker again, leading to duplicate errors
Change-Id: I87dd54f7c3773228f288f7a134ac809d9481ca95
Reviewed-on: https://go-review.googlesource.com/c/go/+/274444
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
For statements like goto that don't need an init, use an
explicit block statement instead of forcing them to have one.
There is also one call to addinit that is being replaced with
a block. That call is the source of much of my confusion
regarding init statements: walkstmt calls addinit on a statement,
whereas all the other uses of addinit are on expressions.
After this CL, they're all expressions.
Passes buildall w/ toolstash -cmp.
Change-Id: Ifdef9d318c236dc1a7567f9e9ef4a6bedd3fe81f
Reviewed-on: https://go-review.googlesource.com/c/go/+/274597
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Import go/printer changes from the dev.go2go branch, with the following
modifications:
- update tests to only use bracketed notation for type parameters
- remove the UseBrackets mode, since it is now implied
- remove guards on ast.Field.Type != nil
Patchset #1 contains the dev.go2go source, unmodified except to resolve
merge conflicts.
Change-Id: I3ddecfd3bee0fc32425a30fe6bd93b24fd3187e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/273226
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
OEMPTY is an empty *statement*, but it confusingly
gets handled as an expression in a few places.
More confusingly, OEMPTY often has an init list,
making it not empty at all. Replace uses and analysis
of OEMPTY with OBLOCK instead.
Passes buildall w/ toolstash -cmp.
Change-Id: I8d4fcef151e4f441fa19b1b96da5272d778131d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/274594
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
It turned out that "go get" was using the network to look up
https://github.com?go-get=1 while resolving github.com/google/go-cmp,
and that is not the fastest page to load.
Stop that lookup by adjusting the path prefixes in the vcs table.
It also turned out that "go get" was using the network to look up
https://rsc.io?go-get=1 while resolving https://rsc.io/nonexist.svn.
That's a bit more defensible maybe, since rsc.io is not a known VCS host.
But for tests we really want to avoid the network entirely, so this CL
adds a special case in repoRootFromVCSPaths that returns a hard error
for plain "rsc.io" instead of doing the web fetch.
To keep us honest in the future, I added two automatically-set env
variables TESTGONETWORK=panic and TESTGOVCS=panic.
These cause the go command to panic rather than make a network request
or invoke a VCS command.
go test -short cmd/go now passes with these checks.
This reduced the time spent in go test -short cmd/go on my
Google workstation from 154s to 30s. (Yay network firewalls.)
Change-Id: I49207fca7f901fa011765fb984dc9cec8b691f11
Reviewed-on: https://go-review.googlesource.com/c/go/+/274441
Trust: Russ Cox <rsc@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Unbuffered channels passed into signal.Notify can be lost
as the docs for signal.Notify caution with:
Package signal will not block sending to c: the caller must ensure
that c has sufficient buffer space to keep up with the expected signal
rate. For a channel used for notification of just one signal value,
a buffer of size 1 is sufficient.
Found by a static analyzer from Orijtech, Inc. called "sigchanyzer", but
it'll be donated to the Go project soon.
Updates #9399.
Change-Id: Ia0690e447582da028694ed65ace7b97961997b84
Reviewed-on: https://go-review.googlesource.com/c/go/+/274332
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Now that filepath.WalkDir is available, it is more efficient
and should be used in place of filepath.Walk.
Update the tree to reflect best practices.
As usual, the code compiled with Go 1.4 during bootstrap is excluded.
(In this CL, that's only cmd/dist.)
For #42027.
Change-Id: Ib0f7b1e43e50b789052f9835a63ced701d8c411c
Reviewed-on: https://go-review.googlesource.com/c/go/+/267719
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
Pseudo branch instructions BGT, BGTU, BLE, and BLEU implemented In
CL 226397 were translated inconsistently compared to other ones due
to the inversion of registers. For instance, while "BLT a, b" generates
"jump if a < b", "BLE a, b" generates "jump if b <= a."
This CL fixes the translation in the assembler and the tests.
Change-Id: Ia757be73e848734ca5b3a790e081f7c4f98c30f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/271911
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
This allows directly creating an ONONAME, which is a primordial Name
before having its Op initialized. Then after an Op is assigned, we
never allow it to be reassigned.
Passes buildall w/ toolstash -cmp.
Change-Id: Ibc2f413dc68c0af6a96abfe653c25ce31b184287
Reviewed-on: https://go-review.googlesource.com/c/go/+/274620
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
This CL adds the remaining constructors needed to abstract away
construction of Types, and updates the compiler to use them
throughout. There's now just a couple uses within test cases to
remove.
While at it, I also replace the Func.Outnamed field with a simple
helper function, which reduces the size of function types somewhat.
Passes toolstash/buildall.
Change-Id: If1aa1095c98ae34b00380d0b3531bd63c10ce885
Reviewed-on: https://go-review.googlesource.com/c/go/+/274713
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
There's no need for the bucket type to be precise. The compiler
doesn't actually generate code that references these fields; it just
needs it for size and GC bitmap calculations.
However, changing the type field does alter the runtime type
descriptor and relocations emitted by the compiler, so this change
isn't safe for toolstash.
Change-Id: Icf79d6c4326515889b13435a575d618e3bbfbcd7
Reviewed-on: https://go-review.googlesource.com/c/go/+/274712
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The gofrontend code doesn't distinguish semicolon and newline,
and it doesn't have special treatment for EOF.
syntax/semi6.go:9:47: error: unexpected semicolon or newline in type declaration
syntax/semi6.go:11:62: error: unexpected semicolon or newline in type declaration
Change-Id: I9996b59a4fc78ad1935e779f354ddf75c0fb44e0
Reviewed-on: https://go-review.googlesource.com/c/go/+/274692
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
As the code signature contains hashes of the entire file (except
the signature itself), rewriting buildid will invalidate the
signature. This CL makes it regenerate the signature when
rewriting the buildid. It only does it when the file already has
a code signature, with proper size (darwin/arm64 binaries
generated by the Go linker should have).
Updates #38485, #42684.
Change-Id: I082d9e5808b0ee6a35f9c362d7262aadd9113c81
Reviewed-on: https://go-review.googlesource.com/c/go/+/272257
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This CL lets the linker code-sign output binaries on
darwin/arm64, as the kernel requires binaries must be signed in
order to run.
This signature will likely be invalidated when we stamp the
buildid after linking. We still do it in the linker, for
- plain "go tool link" works.
- the linker generates the LC_CODE_SIGNATURE load command with
the right size and offset, so we don't need to update it when
stamping the buildid.
Updates #38485, #42684.
Change-Id: Ia306328906d73217221ba31093fe61a935a46122
Reviewed-on: https://go-review.googlesource.com/c/go/+/272256
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
These replacement rules assume that TST and TEQ set V. But TST and
TEQ do not set V. This is a problem because instructions like LT are
actually checking for N!=V. But with TST and TEQ not setting V, LT
doesn't do anything meaningful. It's possible to construct trivial
miscompilations from this, such as:
package main
var x = [4]int32{-0x7fffffff, 0x7fffffff, 2, 4}
func main() {
if x[0] > x[1] {
panic("fail 1")
}
if x[2]&x[3] < 0 {
panic("fail 2") // Fails here
}
}
That first comparison sets V, via the CMP that subtracts the values
causing the overflow. Then the second comparison operation thinks that
it uses the result of TST, when it actually uses the V from CMP.
Before this fix:
TST R0, R1
BLT loc_6C164
After this fix:
TST R0, R1
BMI loc_6C164
The BMI instruction checks the N flag, which TST sets. This commit
fixes the issue by using [LG][TE]noov instead of vanilla [LG][TE], and
also adds a test case for the direct issue.
Fixes#42876.
Change-Id: I13c62c88d18574247ad002b671b38d2d0b0fc6fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/274026
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Just clearing away some scaffolding artifacts from previous
refactorings.
[git-generate]
cd src/cmd/compile/internal/gc
rf '
ex {
import "cmd/compile/internal/ir"
import "cmd/compile/internal/types"
var n *ir.Name; n.Name() -> n
var f *ir.Func; f.Func() -> f
var o types.Object
ir.AsNode(o).Sym() -> o.Sym()
ir.AsNode(o).Type() -> o.Type()
ir.AsNode(o).(*ir.Name) -> o.(*ir.Name)
ir.AsNode(o).(*ir.Func) -> o.(*ir.Func)
var x ir.Node
ir.AsNode(o) != x -> o != x
}
'
Change-Id: I946ec344bd7ee274900a392da53b95308ceaade4
Reviewed-on: https://go-review.googlesource.com/c/go/+/274592
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
If the new Config.IgnoreBranches flag is set, the typechecker
ignores errors due to misplaced labels, break, continue,
fallthrough, or goto statements.
Since the syntax parser already checks these errors, we need
to disable a 2nd check by the typechecker to avoid duplicate
errors when running the compiler with the new typechecker.
Adjusted test/run.go to not ignore some of the tests that
used to fail because of duplicate errors.
Change-Id: I8756eb1d44f67afef5e57da289cd604b8e1716db
Reviewed-on: https://go-review.googlesource.com/c/go/+/274612
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Added a new flag -G to run. Setting -G (as in: go run run.go -G)
will run tests marked with "errorcheck" (and no other flags) also
with the compiler using the new typechecker.
Many tests don't pass yet (due to discrepancies in error messages).
The top-level tests in the test directory which don't pass yet have
been explicitly excluded, permitting to see the current status.
Future CLs will bring error messages in sync and eventually all
tests should pass.
Change-Id: I7caf5eff413e173f68d092af4bbe458434718d74
Reviewed-on: https://go-review.googlesource.com/c/go/+/274313
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
In order to get types2 usable by the compiler, we need to
pass all the compiler tests with respect to error messages.
Sometimes the compiler error messages are better, sometimes
the types2 error messages are better. Where we can, we decide
on a case-by-case basis; but sometimes, for expediency's sake,
we just choose the compiler error message as it may reduce the
amount of tests that we need to update.
This CL introduces a new Config flag: CompilerErrorMessages.
If set, the typechecker emits an error message that matches
the expected errors in the tests most easily. Eventually, we
need to get rid of this flag by either adjusting the typechecker
errors or the test cases; t.b.d. on a case-by-case basis.
This CL also adjust a few error typechecker error messages already.
Change-Id: I9d4e491efadf87e999fc0d5b5151ec02a059f891
Reviewed-on: https://go-review.googlesource.com/c/go/+/274312
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The code signature contains hashes of the entire file (except the
signature itself), including the buildid. Therefore, the buildid
cannot depend on the signature. Otherwise updating buildid will
invalidate the signature, and vice versa. As we cannot change the
code-signing algorithm, we can only change buildid calculation.
This CL changes the buildid calculation to exclude the Mach-O
code signature. So updating code signature after stamping the
buildid will not invalidate the buildid.
Updates #38485, #42684.
Change-Id: I8a9e2e25ca9dc00d9556d13b81652f43bbf6a084
Reviewed-on: https://go-review.googlesource.com/c/go/+/272255
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
On macOS/ARM64, the kernel requires that binaries must have a
valid code signature to run. The C toolchain code-signs the
binary at link time. We do the same.
It is more subtle for Go because we stamp the buildid after
linking. As the signature contains hashes of the entire file
(except the signature itself), we must (re)generate the signature
after stamping the buildid.
This CL adds a new codesign package, which provides
functionality to generate the code signature. It is a separate
internal package so it can be used both in the linker and by the
go command. The next CLs will add code-signing to the linker and
the go command.
Updates #38485, #42684.
Change-Id: Id46801a6665beebaab0eb413ff2e64c5b9467059
Reviewed-on: https://go-review.googlesource.com/c/go/+/272254
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
It's difficult for module authors to provide installation instructions
that work in both Go 1.15 and 1.16. We'll wait until 1.17 to print a
deprecation warning for installing executables with 'go get'.
Fixes#42885
Change-Id: I835b447e83e760f48fd664e8a117749e0cb59f83
Reviewed-on: https://go-review.googlesource.com/c/go/+/274552
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>
If one was using http.Transport with DisableKeepAlives and trying
to upgrade a connection against net/http's Server, the Server
would not allow a "Connection: Upgrade" header to be written
and instead override it to "Connection: Close" which would
break the handshake.
This change ensures net/http's Server does not override the
connection header for successful protocol switch responses.
Fixes#36381.
Change-Id: I882aad8539e6c87ff5f37c20e20b3a7fa1a30357
GitHub-Last-Rev: dc0de83201
GitHub-Pull-Request: golang/go#36382
Reviewed-on: https://go-review.googlesource.com/c/go/+/213277
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Added notes for:
* go test -c and -i flags used with unknown flags
* GO111MODULE=on by default
* GOVCS
* Dropped requirements on excluded versions
Removed TODOs for documentation on the retract directive and
'go install pkg@version'. These pages will be written after the beta.
Change-Id: Ic9877a62f908be177a6035a039b72e969e7b7f22
Reviewed-on: https://go-review.googlesource.com/c/go/+/274438
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
There's not really any use to tracking function-scoped constants and
types on Curfn.Dcl, and there's sloppy code that assumes all of the
declarations are variables (e.g., cmpstackvarlt).
Change-Id: I5d10dc681dac2c161c7b73ba808403052ca0608e
Reviewed-on: https://go-review.googlesource.com/c/go/+/274436
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
This CL introduces types.NewBasic, for creating the predeclared
universal types, and reorganizes how the universe is initialized so
that all predeclared types are uniformly constructed.
There are now a bunch of Type fields that are no longer assigned
outside of the package, so this CL also introduces some new accessor
methods that a subsequent CL will mechanically introduce uses of.
Change-Id: Ie7996c3d5f1ca46cd5bfe45ecc91ebfa6a7b6c7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/274435
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
The start of abstracting away Type fields. This adds a new constructor
for named types, styled after go/types.NewNamed. Along with helper
methods for SetNod and Pos, this allows hiding Nod.
Change-Id: Ica107034b6346c7b523bf6ae2a34009e350a9aa8
Reviewed-on: https://go-review.googlesource.com/c/go/+/274434
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Now that setUnderlying is decoupled from Nodes, it can be moved into
package types, where it really belongs.
[git-generate]
cd src/cmd/compile/internal/gc
rf '
mv setUnderlying SetUnderlying
mv SetUnderlying typex.go
mv typex.go cmd/compile/internal/types
'
cd ../types
rf '
mv typex.go type.go
'
Change-Id: I76e2d4d8a6df599f24a731c4d8e5774ec83a119c
Reviewed-on: https://go-review.googlesource.com/c/go/+/274433
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
The code for type-checking defined types was scattered between
typecheckdef, typecheckdeftype, and setUnderlying. There was redundant
work between them, and setUnderlying also needed to redo a lot of work
because of its brute-force solution of just copying all Type fields.
This CL reorders things so as many of the defined type's fields are
set in advance (in typecheckdeftype), and then setUnderlying only
copies over the details actually needed from the underlying type.
Incidentally, this evidently improves our error handling for an
existing test case, by allowing us to report an additional error.
Passes toolstash/buildall.
Change-Id: Id59a24341e7e960edd1f7366c3e2356da91b9fe7
Reviewed-on: https://go-review.googlesource.com/c/go/+/274432
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Allows emitting errors about ineffectual //go:linkname directives.
In particular, this exposed: a typo in os2_aix.go; redundant (but
harmless) directives for libc_pipe in both os3_solaris.go and
syscall2_solaris.go; and a bunch of useless //go:linkname directives
in macOS wrapper code.
However, because there's also ineffectual directives in the vendored
macOS code from x/sys, that can't be an error just yet. So instead we
print a warning (including a heads up that it will be promoted to an
error in Go 1.17) to prevent backsliding while we fix and re-vendor
that code.
Passes toolstash-check.
Change-Id: I59badeab5df0d8b3abfd14c6066e9bb00e840f73
Reviewed-on: https://go-review.googlesource.com/c/go/+/273986
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
RawCopy breaks the invariant that ir.Orig depends on for
allowing nodes to omit keeping their own orig fields.
Avoid surprises by unexporting it.
The only use in package gc was removed in the previous CL.
This one is a straight global search and replace RawCopy -> rawCopy.
Change-Id: Ia99c0f4665bf7ed4f878cc44456d5fbdf33bab8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/274293
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The ONIL export bug happened because the logic about
maintaining an “implicit” orig pointer in the comments
around ir.Orig only applies to Copy and SepCopy, not to
direct use of RawCopy. I'd forgotten those could exist.
The sole direct use of RawCopy was for the OLITERAL/ONIL case.
The ONIL is now provably indistinguishable from Copy, since
NilExpr does not have an explicit Orig field, so for NilExpr
RawCopy and Copy are the same.
The OLITERAL is not, but we can reconstruct the effect
with Copy+SetOrig to be explicit that we need the orig link.
The next CL will unexport RawCopy.
Also fix a typo in MapType doc comment.
Passes buildall w/ toolstash -cmp.
Change-Id: I876a85ff188e6d1cd4c0dfa385be32482e0de0d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/274292
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
When checking if a defined type is part of a type loop, we can
short-circuit if it was defined in another package. We can assume any
package we import already successfully compiled, so any types it
contains cannot be part of a type loop.
This also allows us to simplify the logic for recursing into the type
used in the type declaration, because any defined type from this
package will have a properly setup node.
Change-Id: Ic024814d95533afd9e59f2103c8ddb22bd87e900
Reviewed-on: https://go-review.googlesource.com/c/go/+/274294
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Currently, in the non-DynlinkingGo case with external linking, we generate a
R_X86_64_GOTPCREL relocation for the imported symbol. This results in the
external linker turning this into a R_X86_64_GLOB_DAT relocation, rather
than a R_X86_64_JUMP_SLOT. Always generate R_X86_64_PLT32 for SDYNIMPORT
calls so that these calls work correctly.
Update #36435Fixes#42671
Change-Id: I8a28884b7853cb4135053ed817bedc919482f4ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/270377
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
These are fairly rote implementations of structs appropriate to
each Op (or group of Ops).
The names of these are unknown except to ir.NodAt for now.
A later, automated change will introduce direct use of the types
throughout package gc.
(This CL is expressions; the previous one was statements.)
This is the last of the Ops that were previously handled by the
generic node struct, so that struct and its methods can be
and are deleted in this CL.
Passes buildall w/ toolstash -cmp.
Change-Id: I1703f35f24dcd3f7c5782a278e53c3fe04e87c37
Reviewed-on: https://go-review.googlesource.com/c/go/+/274109
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
It's not types's responsibility to understand how package
initialization is implemented. Instead, have gc keep track of the
order that packages were imported, and then look for inittask
declarations.
Also, use resolve to force importing of the inittask's export data, so
that we can get the appropriate linker symbol index. (This is also why
this CL doesn't satisfy "toolstash -cmp".)
Change-Id: I5b706497d4a8d1c4439178863b4a8dba4da0f5a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/274006
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The compile -h flag is *meant* to panic, so you can see the stack
trace where the error is being printed. Make it do that again.
Change-Id: Ieb0042863582d7a4c5d08d2f866a144962915b06
Reviewed-on: https://go-review.googlesource.com/c/go/+/274116
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
These are fairly rote implementations of structs appropriate to
each Op (or group of Ops).
The names of these are unknown except to ir.NodAt for now.
A later, automated change will introduce direct use of the types
throughout package gc.
Passes buildall w/ toolstash -cmp.
Change-Id: Ie9835fcd2b214fda5b2149e187af369d76534487
Reviewed-on: https://go-review.googlesource.com/c/go/+/274108
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The list is no longer needed and can be deleted.
Doing so reduces the inlining cost of any function containing
an explicit call to new by 1 point, so this change is not
toolstash -cmp safe.
Change-Id: Id29e115d68e466a353708ab4b8c1021e9c85a628
Reviewed-on: https://go-review.googlesource.com/c/go/+/274132
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Using expression nodes restricts the set of valid SetOp operations,
because you can't SetOp across representation. Rewrite various code
to avoid crossing those as-yet-unintroduced boundaries.
This also includes choosing a single representation for any given Op.
For example, OCLOSE starts out as an OCALL, so it starts with a List
of one node and then moves that node to Left. That's no good with
real data structures, so the code picks a single canonical implementation
and prepares it during the conversion from one Op to the next.
In this case, the conversion of an OCALL to an OCLOSE now creates
a new node with Left initialized from the start. This pattern repeats.
Passes buildall w/ toolstash -cmp.
Change-Id: I55a0872c614d883cac9d64976c46aeeaa639e25d
Reviewed-on: https://go-review.googlesource.com/c/go/+/274107
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Using statement nodes restricts the set of valid SetOp operations,
because you can't SetOp across representation. Rewrite various
code to avoid crossing those as-yet-unintroduced boundaries.
In particular, code like
x, y := v.(T)
x, y := f()
x, y := m[k]
x, y := <-c
starts out with Op = OAS2, and then it turns into a specific Op
OAS2DOTTYPE, OAS2FUNC, OAS2MAPR, OAS2RECV, and then
later in walk is lowered to an OAS2 again.
In the middle, the specific forms move the right-hand side from
n.Rlist().First() to n.Right(), and then the conversion to OAS2 moves
it back. This is unnecessary and makes it hard for these all to
share an underlying Node implementation.
This CL changes these specific forms to leave the right-hand side
in n.Rlist().First().
Similarly, OSELRECV2 is really just a temporary form of OAS2.
This CL changes it to use same fields too.
Finally, this CL fixes the printing of OAS2 nodes in ir/fmt.go,
which formerly printed n.Right() instead of n.Rlist().
This results in a (correct!) update to cmd/compile/internal/logopt's
expected output: ~R0 = <N> becomes ~R0 = &y.b.
Passes buildall w/ toolstash -cmp.
Change-Id: I164aa2e17dc55bfb292024de53d7d250192ad64a
Reviewed-on: https://go-review.googlesource.com/c/go/+/274105
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Apparently, the macOS ARM64 kernel has a bug where when a signal
arrives and the signal stack is not currently faulted in, it may
kill the program with a SIGILL. Work around it by mlock the
signal stacks.
Fixes#42774.
Change-Id: I99a4b3fdb6d8af1c945725ddc2c25568d81c510a
Reviewed-on: https://go-review.googlesource.com/c/go/+/273686
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The handling of ONIL and Orig has been a mess for a while, and dates
back to how fmt.go used to print out typed nils. That hasn't applied
for a while, but we've kept dragging it along to appease toolstash
with the intention of someday finally removing it.
Today is that day.
Change-Id: I9a441628e53068ab1993cd2b67b977574d8117b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/274212
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
This matches the error messages after CL 273890.
syntax/semi4.go:11:9: error: unexpected semicolon or newline, expecting ‘{’ after for clause
syntax/semi4.go:10:13: error: reference to undefined name ‘x’
syntax/semi4.go:12:17: error: reference to undefined name ‘z’
Change-Id: Ic88ff6e27d50bf70f5b2114383b84c42c0682f39
Reviewed-on: https://go-review.googlesource.com/c/go/+/273891
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The type syntax is reused to stand in for the actual type once typechecked,
to avoid updating all the possible references to the original type syntax.
So all these implementations allow changing their Op from the raw syntax
like OTMAP to the finished form OTYPE, even though obviously the
representation does not change.
Passes buildall w/ toolstash -cmp.
Change-Id: I4acca1a5b35fa2f48ee08e8f1e5a330a004c284b
Reviewed-on: https://go-review.googlesource.com/c/go/+/274103
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is a general operation on IR nodes, so it belongs in ir.
The copied implementation is adapted to support the
extension pattern, allowing nodes to implement their
own DeepCopy implementations if needed.
This is the first step toward higher-level operations instead
of Left, Right, etc. It will allow the new type syntax nodes
to be properly immutable and opt out of those fine-grained methods.
Passes buildall w/ toolstash -cmp.
Change-Id: Ibd64061e01daf14aebc6586cb2eb2b12057ca85a
Reviewed-on: https://go-review.googlesource.com/c/go/+/274102
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Now there are no longer any generic nodes with a non-nil
associated Func, so node.fn can be deleted. Also all manipulation
of func fields is done with concrete types, so Node.SetFunc can be
deleted, along with generic implementations.
Passes buildall w/ toolstash -cmp.
Change-Id: I4fee99870951ec9dc224f146d87b22e2bfe16889
Reviewed-on: https://go-review.googlesource.com/c/go/+/274099
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Closures are another reference to Funcs,
and it cleans up the code quite a bit to be clear about types.
OCLOSUREVAR is renamed to OCLOSUREREAD to make
clearer that it is unrelated to the list Func.ClosureVars.
Passes buildall w/ toolstash -cmp.
Change-Id: Id0d28df2d4d6e9954e34df7a39ea226995eee937
Reviewed-on: https://go-review.googlesource.com/c/go/+/274098
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Now that we have specific types for ONAME and ODCLFUNC nodes
(*Name and *Func), use them throughout the compiler to be more
precise about what data is being operated on.
This is a somewhat large CL, but once you start applying the types
in a few places, you end up needing to apply them to many other
places to keep everything type-checking. A lot of code also melts
away as types are added.
Passes buildall w/ toolstash -cmp.
Change-Id: I21dd9b945d701c470332bac5394fca744a5b232d
Reviewed-on: https://go-review.googlesource.com/c/go/+/274097
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Before this CL, an ODCLFUNC Node was represented by both
a node struct and a Func struct (and a Name for the ONAME,
which isn't changing here). Now Func can be repurposed as
the ODCLFUNC implementation, replacing the two structs
totaling 280+144 = 424 bytes (64-bit) with a single 320-byte struct.
Using the *Func as the node also gives us a clear, typed answer to
“which node should we use to represent functions?”
The next CL will clean up uses. This CL is just the trivial
change in representation.
Passes buildall w/ toolstash -cmp.
Change-Id: Ie6d670da91d6eb8d67a85f8f83630b9586dc7443
Reviewed-on: https://go-review.googlesource.com/c/go/+/274096
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Before this CL, an ONAME Node was represented by three structs
linked together: a node, a Name, and a Param. Previous CLs removed
OLABEL and OPACK from the set of nodes that knew about Name.
Now Name can be repurposed to *be* the ONAME Node implementation,
replacing three linked structs totaling 152+64+88 = 304 bytes (64-bit)
with a single 232-byte struct.
Many expressions in the code become simpler as well, without having
to use .Param. and sometimes even .Name().
(For a node n where n.Name() != nil, n.Name() == n.(*Name) now.)
Passes buildall w/ toolstash -cmp.
Change-Id: Ie719f1285c05623b9fd2faaa059e5b360a64b3be
Reviewed-on: https://go-review.googlesource.com/c/go/+/274094
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
These are the first three specific implementations of Node.
They are both a bit of a warmup and also working toward
removing references to Name from Node types other than
the proper named things - ONAME, ONONAME, OTYPE, OLITERAL.
(In this case, BranchStmt and LabelStmt.)
Passes buildall w/ toolstash -cmp.
Change-Id: Ide816b162025ee4c858dd061d7c29ed633fb7baf
Reviewed-on: https://go-review.googlesource.com/c/go/+/274091
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
In preparation for OEMPTY being its own Node implementation,
remove SetOp(OEMPTY) calls that assume other implementations
can be turned into OEMPTY.
Passes buildall w/ toolstash -cmp.
Change-Id: Icac16d12548f35f52a5efa9d09dacf8260f42075
Reviewed-on: https://go-review.googlesource.com/c/go/+/274090
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
These are only needed for a few opcodes, and we can avoid
wasting storage in every implementation by using the extension
interface pattern with a helper function for access.
Of course, in the current codebase, there is only one Node
implementation (*node) and it has these methods, so there
is no danger of a functional change in this particular CL.
Passes buildall w/ toolstash -cmp.
Change-Id: I440c6c232f1fe7b56b852a00dc530f8f49a6b12d
Reviewed-on: https://go-review.googlesource.com/c/go/+/274089
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Start a list of which ops are valid for the default
node struct implementation (currently all of them).
Add a Node implementation helper for a minimal node.
Passes buildall w/ toolstash -cmp.
Change-Id: I7ae45f2cf2be85013cb71ab00524be53f243e13d
Reviewed-on: https://go-review.googlesource.com/c/go/+/274088
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
- The use of a label's Name.Defn to point at the named for/select/switch
means that any rewrite of the for/select/switch must overwrite the original
or else the pointer will dangle. Remove that pointer by adding the label
name directly to the for/select/switch representation instead.
- The only uses of a label's Sym.Label were ephemeral values during
markbreak and escape analysis. Use a map for each. Although in general
we are not going to replace all computed fields with maps (too slow),
the one in markbreak is only for labeled for/select/switch, and the one
in escape is for all labels, but even so, labels are fairly rare.
In theory this cleanup should make it easy to allow labeled for/select/switch
in inlined bodies, but this CL does not attempt that. It's only concerned
with cleanup to enable a new Node representation.
Passes buildall w/ toolstash -cmp.
Change-Id: I7e36ee98d2ea40dbae94e6722d585f007b7afcfa
Reviewed-on: https://go-review.googlesource.com/c/go/+/274086
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
On illumos systems, libc can under some conditions make use of files
from /proc. In the case of this test, the creation of new threads was
(in the target thread) causing libc to open and close
"/proc/self/lwp/5/lwpname" to set the thread name, which raced with the
leaking descriptor check (see detailed analysis in #42431).
This change requests that the Go runtime use less threads in the child
process used to check for leaked descriptors, without just disabling the
test. After a thousand repeated trials, the test no longer fails on
illumos.
Fixes#42431.
Change-Id: Iefda26134fc91f7cb205754676e9845d9b7205cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/273966
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
This is blocking forward progress of the de-bitrotting work, and I don't
know off hand how to fix this. Seeing as its disabled on other
platforms, I suspect pprof might not be a very reliable feature, so just
allow for the tests to fail for now, until somebody more motivated comes
along to fix it.
Updates #42862.
Change-Id: Ibc5cd1d82d97b9c2f887d7f3565f2fa70207c8b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/273826
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
These changes match the following gofrontend error messages:
blank1.go:16:1: error: may not define methods on non-local type
chan/perm.go:28:9: error: expected channel
chan/perm.go:29:11: error: left operand of ‘<-’ must be channel
chan/perm.go:69:9: error: argument must be channel
complit1.go:25:16: error: attempt to slice object that is not array, slice, or string
complit1.go:26:16: error: attempt to slice object that is not array, slice, or string
complit1.go:27:17: error: attempt to slice object that is not array, slice, or string
complit1.go:49:41: error: may only omit types within composite literals of slice, array, or map type
complit1.go:50:14: error: expected struct, slice, array, or map type for composite literal
convlit.go:24:9: error: invalid type conversion (cannot use type unsafe.Pointer as type string)
convlit.go:25:9: error: invalid type conversion (cannot use type unsafe.Pointer as type float64)
convlit.go:26:9: error: invalid type conversion (cannot use type unsafe.Pointer as type int)
ddd1.go:63:9: error: invalid use of ‘...’ calling non-variadic function
fixedbugs/bug176.go:12:18: error: index expression is not integer constant
fixedbugs/bug332.go:17:10: error: use of undefined type ‘T’
fixedbugs/issue4232.go:22:16: error: integer constant overflow
fixedbugs/issue4232.go:33:16: error: integer constant overflow
fixedbugs/issue4232.go:44:25: error: integer constant overflow
fixedbugs/issue4232.go:55:16: error: integer constant overflow
fixedbugs/issue4458.go:19:14: error: type has no method ‘foo’
fixedbugs/issue5172.go:24:14: error: too many expressions for struct
init.go:17:9: error: reference to undefined name ‘runtime’
initializerr.go:26:29: error: duplicate value for index 1
interface/explicit.go:60:14: error: type assertion only valid for interface types
label.go:64:9: error: reference to undefined label ‘go2’
label1.go:18:97: error: continue statement not within for
label1.go:22:97: error: continue statement not within for
label1.go:106:89: error: continue statement not within for
label1.go:108:26: error: invalid continue label ‘on’
label1.go:111:118: error: break statement not within for or switch or select
label1.go:113:23: error: invalid break label ‘dance’
map1.go:64:9: error: not enough arguments
map1.go:65:9: error: not enough arguments
map1.go:67:9: error: argument 1 must be a map
method2.go:36:11: error: reference to undefined field or method ‘val’
method2.go:37:11: error: reference to undefined field or method ‘val’
method2.go:41:12: error: method requires pointer (use ‘(*T).g’)
syntax/chan1.go:13:19: error: send statement used as value; use select for non-blocking send
syntax/chan1.go:17:11: error: send statement used as value; use select for non-blocking send
Change-Id: I98047b60a376e3d2788836300f7fcac3f2c285cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/273527
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
If the linker thinks that it's in exe mode instead of pie mode, it
won't emit relocations when generating the pcln table, and we wind
up with crashes like this on windows/arm, where all binaries are
in fact relocated:
Building Go toolchain2 using go_bootstrap and Go toolchain1.
fatal error: minpc or maxpc invalid
runtime: panic before malloc heap initialized
This problem was already solved by darwin/arm64, so solve it the same
way here for windows/arm.
Fixes CL 228478.
Fixes#42786.
Change-Id: I6d1db6907c131183649fc263ccca06783188f344
Reviewed-on: https://go-review.googlesource.com/c/go/+/273566
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
This function's prototype includes a return value, so return a value.
Otherwise clang gets upset:
--- FAIL: TestDLLPreloadMitigation (1.40s)
syscall_windows_test.go:986: failed to build dll: exit status 1 - nojack.c:7:1: error: non-void function does not return a value [-Werror,-Wreturn-type]
}
^
1 error generated.
Fixes#42860.
Change-Id: I65b8eb9ccb502692c5b65bd34829f331cd86eef0
Reviewed-on: https://go-review.googlesource.com/c/go/+/273726
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
None of the other, older, doc comments use the '*Logger' form, and while
'Logger' and 'logger' are both used in the package doc comment, the
common term used with the intended meaning is 'standard logger', which
appears another eleven times in doc comments.
Change-Id: I089103198fc82390517615eb27bbe7ef77107d34
Reviewed-on: https://go-review.googlesource.com/c/go/+/273486
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
In CL 145200, I changed OBREAK, OCONTINUE, OGOTO, and OLABEL to just
use Sym instead of Node. However, within the export data, I forgot to
update the code for OBREAK and OCONTINUE.
This isn't currently an issue because the inliner currently disallows
these anyway, but it'll be an issue in the future once we add support
for inlining them. Also, Russ independently ran into it in CL 273246.
Updates #14768.
Change-Id: I94575df59c08a750b0dce1d3ce612aba7bfeeb76
Reviewed-on: https://go-review.googlesource.com/c/go/+/273270
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Many of the standard library changes that were added before CL 272871
ended up in the "Core library" section. That section is meant for
major changes like new packages, and most of these aren't.
Consolidate all changes in the "Minor changes to the library" section
for now, so that it's easier to get a complete picture of changes for
each package, along with the remaining TODOs. Add a TODO to read them
over at the end and factor out items that are worth highlighting.
Apply minor other fixups to improve consistency.
For #40700.
Change-Id: I7dc2e7ebf2ea3385fce0c207bae4ce467998a717
Reviewed-on: https://go-review.googlesource.com/c/go/+/273267
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
The plan is to introduce a Node interface that replaces the old *Node pointer-to-struct.
The previous CL defined an interface INode modeling a *Node.
This CL:
- Changes all references outside internal/ir to use INode,
along with many references inside internal/ir as well.
- Renames Node to node.
- Renames INode to Node
So now ir.Node is an interface implemented by *ir.node, which is otherwise inaccessible,
and the code outside package ir is now (clearly) using only the interface.
The usual rule is never to redefine an existing name with a new meaning,
so that old code that hasn't been updated gets a "unknown name" error
instead of more mysterious errors or silent misbehavior. That rule would
caution against replacing Node-the-struct with Node-the-interface,
as in this CL, because code that says *Node would now be using a pointer
to an interface. But this CL is being landed at the same time as another that
moves Node from gc to ir. So the net effect is to replace *gc.Node with ir.Node,
which does follow the rule: any lingering references to gc.Node will be told
it's gone, not silently start using pointers to interfaces. So the rule is followed
by the CL sequence, just not this specific CL.
Overall, the loss of inlining caused by using interfaces cuts the compiler speed
by about 6%, a not insignificant amount. However, as we convert the representation
to concrete structs that are not the giant Node over the next weeks, that speed
should come back as more of the compiler starts operating directly on concrete types
and the memory taken up by the graph of Nodes drops due to the more precise
structs. Honestly, I was expecting worse.
% benchstat bench.old bench.new
name old time/op new time/op delta
Template 168ms ± 4% 182ms ± 2% +8.34% (p=0.000 n=9+9)
Unicode 72.2ms ±10% 82.5ms ± 6% +14.38% (p=0.000 n=9+9)
GoTypes 563ms ± 8% 598ms ± 2% +6.14% (p=0.006 n=9+9)
Compiler 2.89s ± 4% 3.04s ± 2% +5.37% (p=0.000 n=10+9)
SSA 6.45s ± 4% 7.25s ± 5% +12.41% (p=0.000 n=9+10)
Flate 105ms ± 2% 115ms ± 1% +9.66% (p=0.000 n=10+8)
GoParser 144ms ±10% 152ms ± 2% +5.79% (p=0.011 n=9+8)
Reflect 345ms ± 9% 370ms ± 4% +7.28% (p=0.001 n=10+9)
Tar 149ms ± 9% 161ms ± 5% +8.05% (p=0.001 n=10+9)
XML 190ms ± 3% 209ms ± 2% +9.54% (p=0.000 n=9+8)
LinkCompiler 327ms ± 2% 325ms ± 2% ~ (p=0.382 n=8+8)
ExternalLinkCompiler 1.77s ± 4% 1.73s ± 6% ~ (p=0.113 n=9+10)
LinkWithoutDebugCompiler 214ms ± 4% 211ms ± 2% ~ (p=0.360 n=10+8)
StdCmd 14.8s ± 3% 15.9s ± 1% +6.98% (p=0.000 n=10+9)
[Geo mean] 480ms 510ms +6.31%
name old user-time/op new user-time/op delta
Template 223ms ± 3% 237ms ± 3% +6.16% (p=0.000 n=9+10)
Unicode 103ms ± 6% 113ms ± 3% +9.53% (p=0.000 n=9+9)
GoTypes 758ms ± 8% 800ms ± 2% +5.55% (p=0.003 n=10+9)
Compiler 3.95s ± 2% 4.12s ± 2% +4.34% (p=0.000 n=10+9)
SSA 9.43s ± 1% 9.74s ± 4% +3.25% (p=0.000 n=8+10)
Flate 132ms ± 2% 141ms ± 2% +6.89% (p=0.000 n=9+9)
GoParser 177ms ± 9% 183ms ± 4% ~ (p=0.050 n=9+9)
Reflect 467ms ±10% 495ms ± 7% +6.17% (p=0.029 n=10+10)
Tar 183ms ± 9% 197ms ± 5% +7.92% (p=0.001 n=10+10)
XML 249ms ± 5% 268ms ± 4% +7.82% (p=0.000 n=10+9)
LinkCompiler 544ms ± 5% 544ms ± 6% ~ (p=0.863 n=9+9)
ExternalLinkCompiler 1.79s ± 4% 1.75s ± 6% ~ (p=0.075 n=10+10)
LinkWithoutDebugCompiler 248ms ± 6% 246ms ± 2% ~ (p=0.965 n=10+8)
[Geo mean] 483ms 504ms +4.41%
[git-generate]
cd src/cmd/compile/internal/ir
: # We need to do the conversion in multiple steps, so we introduce
: # a temporary type alias that will start out meaning the pointer-to-struct
: # and then change to mean the interface.
rf '
mv Node OldNode
add node.go \
type Node = *OldNode
'
: # It should work to do this ex in ir, but it misses test files, due to a bug in rf.
: # Run the command in gc to handle gc's tests, and then again in ssa for ssa's tests.
cd ../gc
rf '
ex . ../arm ../riscv64 ../arm64 ../mips64 ../ppc64 ../mips ../wasm {
import "cmd/compile/internal/ir"
*ir.OldNode -> ir.Node
}
'
cd ../ssa
rf '
ex {
import "cmd/compile/internal/ir"
*ir.OldNode -> ir.Node
}
'
: # Back in ir, finish conversion clumsily with sed,
: # because type checking and circular aliases do not mix.
cd ../ir
sed -i '' '
/type Node = \*OldNode/d
s/\*OldNode/Node/g
s/^func (n Node)/func (n *OldNode)/
s/OldNode/node/g
s/type INode interface/type Node interface/
s/var _ INode = (Node)(nil)/var _ Node = (*node)(nil)/
' *.go
gofmt -w *.go
sed -i '' '
s/{Func{}, 136, 248}/{Func{}, 152, 280}/
s/{Name{}, 32, 56}/{Name{}, 44, 80}/
s/{Param{}, 24, 48}/{Param{}, 44, 88}/
s/{node{}, 76, 128}/{node{}, 88, 152}/
' sizeof_test.go
cd ../ssa
sed -i '' '
s/{LocalSlot{}, 28, 40}/{LocalSlot{}, 32, 48}/
' sizeof_test.go
cd ../gc
sed -i '' 's/\*ir.Node/ir.Node/' mkbuiltin.go
cd ../../../..
go install std cmd
cd cmd/compile
go test -u || go test -u
Change-Id: I196bbe3b648e4701662e4a2bada40bf155e2a553
Reviewed-on: https://go-review.googlesource.com/c/go/+/272935
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The pointer hack was nice and saved a word, but it's untenable
in a world where nodes are themselves interfaces with different
underlying types. Bite the bullet and use an interface to hold the
Node when in types.Sym and types.Type.
This has the nice benefit of removing AsTypesNode entirely.
AsNode is still useful because of its nil handling.
Change-Id: I298cba9ff788b956ee287283bec78010e8b601e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/272933
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
These are trivial rewrites that are only OK because it turns out that n has no side effects.
Separated into a different CL for easy inspection.
[git-generate]
cd src/cmd/compile/internal/gc
rf '
ex . ../ir ../ssa {
import "cmd/compile/internal/ir"
var n *ir.Node
var i int64
n.Xoffset++ -> n.Xoffset = n.Xoffset + 1
n.Xoffset-- -> n.Xoffset = n.Xoffset - 1
n.Xoffset += i -> n.Xoffset = n.Xoffset + i
n.Xoffset -= i -> n.Xoffset = n.Xoffset - i
}
'
Change-Id: If7b4b7f7cbdafeee988e04d03924ef0e1dd867b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/272932
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The cycle hacks existed because gc needed to import ssa
which need to know about gc.Node. But now that's ir.Node,
and there's no cycle anymore.
Don't know how much it matters but LocalSlot is now
one word shorter than before, because it holds a pointer
instead of an interface for the *Node. That won't last long.
Now that they're not necessary for interface satisfaction,
IsSynthetic and IsAutoTmp can move to top-level ir functions.
Change-Id: Ie511e93466cfa2b17d9a91afc4bd8d53fdb80453
Reviewed-on: https://go-review.googlesource.com/c/go/+/272931
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
If we want to break up package gc at all, we will need to move
the compiler IR it defines into a separate package that can be
imported by packages that gc itself imports. This CL does that.
It also removes the TINT8 etc aliases so that all code is clear
about which package things are coming from.
This CL is automatically generated by the script below.
See the comments in the script for details about the changes.
[git-generate]
cd src/cmd/compile/internal/gc
rf '
# These names were never fully qualified
# when the types package was added.
# Do it now, to avoid confusion about where they live.
inline -rm \
Txxx \
TINT8 \
TUINT8 \
TINT16 \
TUINT16 \
TINT32 \
TUINT32 \
TINT64 \
TUINT64 \
TINT \
TUINT \
TUINTPTR \
TCOMPLEX64 \
TCOMPLEX128 \
TFLOAT32 \
TFLOAT64 \
TBOOL \
TPTR \
TFUNC \
TSLICE \
TARRAY \
TSTRUCT \
TCHAN \
TMAP \
TINTER \
TFORW \
TANY \
TSTRING \
TUNSAFEPTR \
TIDEAL \
TNIL \
TBLANK \
TFUNCARGS \
TCHANARGS \
NTYPE \
BADWIDTH
# esc.go and escape.go do not need to be split.
# Append esc.go onto the end of escape.go.
mv esc.go escape.go
# Pull out the type format installation from func Main,
# so it can be carried into package ir.
mv Main:/Sconv.=/-0,/TypeLinkSym/-1 InstallTypeFormats
# Names that need to be exported for use by code left in gc.
mv Isconst IsConst
mv asNode AsNode
mv asNodes AsNodes
mv asTypesNode AsTypesNode
mv basicnames BasicTypeNames
mv builtinpkg BuiltinPkg
mv consttype ConstType
mv dumplist DumpList
mv fdumplist FDumpList
mv fmtMode FmtMode
mv goopnames OpNames
mv inspect Inspect
mv inspectList InspectList
mv localpkg LocalPkg
mv nblank BlankNode
mv numImport NumImport
mv opprec OpPrec
mv origSym OrigSym
mv stmtwithinit StmtWithInit
mv dump DumpAny
mv fdump FDumpAny
mv nod Nod
mv nodl NodAt
mv newname NewName
mv newnamel NewNameAt
mv assertRepresents AssertValidTypeForConst
mv represents ValidTypeForConst
mv nodlit NewLiteral
# Types and fields that need to be exported for use by gc.
mv nowritebarrierrecCallSym SymAndPos
mv SymAndPos.lineno SymAndPos.Pos
mv SymAndPos.target SymAndPos.Sym
mv Func.lsym Func.LSym
mv Func.setWBPos Func.SetWBPos
mv Func.numReturns Func.NumReturns
mv Func.numDefers Func.NumDefers
mv Func.nwbrCalls Func.NWBRCalls
# initLSym is an algorithm left behind in gc,
# not an operation on Func itself.
mv Func.initLSym initLSym
mv nodeQueue NodeQueue
mv NodeQueue.empty NodeQueue.Empty
mv NodeQueue.popLeft NodeQueue.PopLeft
mv NodeQueue.pushRight NodeQueue.PushRight
# Many methods on Node are actually algorithms that
# would apply to any node implementation.
# Those become plain functions.
mv Node.funcname FuncName
mv Node.isBlank IsBlank
mv Node.isGoConst isGoConst
mv Node.isNil IsNil
mv Node.isParamHeapCopy isParamHeapCopy
mv Node.isParamStackCopy isParamStackCopy
mv Node.isSimpleName isSimpleName
mv Node.mayBeShared MayBeShared
mv Node.pkgFuncName PkgFuncName
mv Node.backingArrayPtrLen backingArrayPtrLen
mv Node.isterminating isTermNode
mv Node.labeledControl labeledControl
mv Nodes.isterminating isTermNodes
mv Nodes.sigerr fmtSignature
mv Node.MethodName methodExprName
mv Node.MethodFunc methodExprFunc
mv Node.IsMethod IsMethod
# Every node will need to implement RawCopy;
# Copy and SepCopy algorithms will use it.
mv Node.rawcopy Node.RawCopy
mv Node.copy Copy
mv Node.sepcopy SepCopy
# Extract Node.Format method body into func FmtNode,
# but leave method wrapper behind.
mv Node.Format:0,$ FmtNode
# Formatting helpers that will apply to all node implementations.
mv Node.Line Line
mv Node.exprfmt exprFmt
mv Node.jconv jconvFmt
mv Node.modeString modeString
mv Node.nconv nconvFmt
mv Node.nodedump nodeDumpFmt
mv Node.nodefmt nodeFmt
mv Node.stmtfmt stmtFmt
# Constant support needed for code moving to ir.
mv okforconst OKForConst
mv vconv FmtConst
mv int64Val Int64Val
mv float64Val Float64Val
mv Node.ValueInterface ConstValue
# Organize code into files.
mv LocalPkg BuiltinPkg ir.go
mv NumImport InstallTypeFormats Line fmt.go
mv syntax.go Nod NodAt NewNameAt Class Pxxx PragmaFlag Nointerface SymAndPos \
AsNode AsTypesNode BlankNode OrigSym \
Node.SliceBounds Node.SetSliceBounds Op.IsSlice3 \
IsConst Node.Int64Val Node.CanInt64 Node.Uint64Val Node.BoolVal Node.StringVal \
Node.RawCopy SepCopy Copy \
IsNil IsBlank IsMethod \
Node.Typ Node.StorageClass node.go
mv ConstType ConstValue Int64Val Float64Val AssertValidTypeForConst ValidTypeForConst NewLiteral idealType OKForConst val.go
# Move files to new ir package.
mv bitset.go class_string.go dump.go fmt.go \
ir.go node.go op_string.go val.go \
sizeof_test.go cmd/compile/internal/ir
'
: # fix mkbuiltin.go to generate the changes made to builtin.go during rf
sed -i '' '
s/\[T/[types.T/g
s/\*Node/*ir.Node/g
/internal\/types/c \
fmt.Fprintln(&b, `import (`) \
fmt.Fprintln(&b, ` "cmd/compile/internal/ir"`) \
fmt.Fprintln(&b, ` "cmd/compile/internal/types"`) \
fmt.Fprintln(&b, `)`)
' mkbuiltin.go
gofmt -w mkbuiltin.go
: # update cmd/dist to add internal/ir
cd ../../../dist
sed -i '' '/compile.internal.gc/a\
"cmd/compile/internal/ir",
' buildtool.go
gofmt -w buildtool.go
: # update cmd/compile TestFormats
cd ../..
go install std cmd
cd cmd/compile
go test -u || go test # first one updates but fails; second passes
Change-Id: I5f7caf6b20629b51970279e81231a3574d5b51db
Reviewed-on: https://go-review.googlesource.com/c/go/+/273008
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Move Flag, Debug, Ctxt, Exit, and error messages to
new package cmd/compile/internal/base.
These are the core functionality that everything in gc uses
and which otherwise prevent splitting any other code
out of gc into different packages.
A minor milestone: the compiler source code
no longer contains the string "yy".
[git-generate]
cd src/cmd/compile/internal/gc
rf '
mv atExit AtExit
mv Ctxt atExitFuncs AtExit Exit base.go
mv lineno Pos
mv linestr FmtPos
mv flusherrors FlushErrors
mv yyerror Errorf
mv yyerrorl ErrorfAt
mv yyerrorv ErrorfVers
mv noder.yyerrorpos noder.errorAt
mv Warnl WarnfAt
mv errorexit ErrorExit
mv base.go debug.go flag.go print.go cmd/compile/internal/base
'
: # update comments
sed -i '' 's/yyerrorl/ErrorfAt/g; s/yyerror/Errorf/g' *.go
: # bootstrap.go is not built by default so invisible to rf
sed -i '' 's/Fatalf/base.Fatalf/' bootstrap.go
goimports -w bootstrap.go
: # update cmd/dist to add internal/base
cd ../../../dist
sed -i '' '/internal.amd64/a\
"cmd/compile/internal/base",
' buildtool.go
gofmt -w buildtool.go
Change-Id: I59903c7084222d6eaee38823fd222159ba24a31a
Reviewed-on: https://go-review.googlesource.com/c/go/+/272250
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Now that the debug settings are in a struct, use struct tags to set
the usage messages and use reflection to populate debugtab,
much like we did for the Flag struct.
Change-Id: Id2ba30c30a9158c062527715a68bf4dd94679457
Reviewed-on: https://go-review.googlesource.com/c/go/+/272247
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The debug table is not as haphazard as flags, but there are still
a few mismatches between command-line names and variable names.
This CL moves them all into a consistent home (var Debug, like var Flag).
Code updated automatically using the rf command below.
A followup CL will make a few manual cleanups, leaving this CL
completely automated and easier to regenerate during merge
conflicts.
[git-generate]
cd src/cmd/compile/internal/gc
rf '
add main.go var Debug struct{}
mv Debug_append Debug.Append
mv Debug_checkptr Debug.Checkptr
mv Debug_closure Debug.Closure
mv Debug_compilelater Debug.CompileLater
mv disable_checknil Debug.DisableNil
mv debug_dclstack Debug.DclStack
mv Debug_gcprog Debug.GCProg
mv Debug_libfuzzer Debug.Libfuzzer
mv Debug_checknil Debug.Nil
mv Debug_panic Debug.Panic
mv Debug_slice Debug.Slice
mv Debug_typeassert Debug.TypeAssert
mv Debug_wb Debug.WB
mv Debug_export Debug.Export
mv Debug_pctab Debug.PCTab
mv Debug_locationlist Debug.LocationLists
mv Debug_typecheckinl Debug.TypecheckInl
mv Debug_gendwarfinl Debug.DwarfInl
mv Debug_softfloat Debug.SoftFloat
mv Debug_defer Debug.Defer
mv Debug_dumpptrs Debug.DumpPtrs
mv flag.go:/parse.-d/-1,/unknown.debug/+2 parseDebug
mv debugtab Debug parseDebug \
debugHelpHeader debugHelpFooter \
debug.go
# Remove //go:generate line copied from main.go
rm debug.go:/go:generate/-+
'
Change-Id: I625761ca5659be4052f7161a83baa00df75cca91
Reviewed-on: https://go-review.googlesource.com/c/go/+/272246
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Now that all flags are in a struct, use struct tags to set the usage messages
and use reflection to walk the struct and register all the flags.
Also move some flag usage back into main.go that shouldn't
come with the rest of flag.go into package base.
Change-Id: Ie655582194906c9ab425c3d01ad8c304bc49bfe0
Reviewed-on: https://go-review.googlesource.com/c/go/+/271668
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
CL 34641 changed the Go runtime to assume GOARM=7 support on Android.
This change completes that by assuming GOARM=7 in the toolchain, fixing
the gotcha of inexplicably slow performance on non-arm64 Android devices.
There is already code in cmd/dist to force GOARM to 7 on GOOS=android. However,
dist is most likely run with GOOS != android.
Change-Id: I5e2bf11c3ecd0f6c193229eaa8ddc570722799d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/272846
Run-TryBot: Elias Naur <mail@eliasnaur.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Elias Naur <mail@eliasnaur.com>
When c.elemsize==0 we call raceacquire() and racerelease()
as opposed to calling racereleaseacquire()
The reason for this change is that, when elemsize==0, we don't
allocate a full buffer for the channel. Instead of individual
buffer entries, the race detector uses the c.buf as the only
buffer entry. This simplification prevents us following the
memory model's happens-before rules implemented in racereleaseacquire().
So, instead of calling racereleaseacquire(), we accumulate
happens-before information in the synchronization object associated
with c.buf.
The functionality in this change is implemented in a new function
called racenotify()
Fixes#42598
Change-Id: I75b92708633fdfde658dc52e06264e2171824e51
Reviewed-on: https://go-review.googlesource.com/c/go/+/271987
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Dmitry Vyukov <dvyukov@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
In the previous CL, I had incorrectly removed one of the error
messages from issue20232.go, because I thought go/constant was just
handling it. But actually the compiler was panicking in nodlit,
because it didn't handle constant.Unknown. So this CL makes it leave
n.Type == nil for unknown constant.Values.
While here, also address #42732 by making sure to report an error
message when origConst is called with an unknown constant.Value (as
can happen when multiplying two floating-point constants overflows).
Finally, add OXOR and OBITNOT to the list of operations to report
errors about, since they're also constant expressions that can produce
a constant with a greater bit length than their operands.
Fixes#42732.
Change-Id: I4a538fbae9b3ac4c553d7de5625dc0c87d9acce3
Reviewed-on: https://go-review.googlesource.com/c/go/+/272928
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
The existing code introduces many types in what appears to be an
attempt to avoid allocation when converting formatting argument lists.
Simplify by accepting that allocation is going to happen, especially
when Node itself turns into an interface.
Change-Id: I3c0d45ca01eace4924deb43c0ea7dc6d65943d08
Reviewed-on: https://go-review.googlesource.com/c/go/+/272929
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The goal is to move Node to being an interface and then break
up the one big struct into many implementations.
Step 1 is to convert all current uses of Node to only use methods,
so that the existing algorithms keep working even as the underlying
implementations are adjusted.
Step 0 - this CL - is to add the getters and setters for Step 1.
Change-Id: I0570d8727c3ccb64113627bb9bebcb0dc39da07a
Reviewed-on: https://go-review.googlesource.com/c/go/+/273007
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
For the upcoming rewrite to access methods, a few direct accesses
are problematic for the automated tool, most notably direct copies
or use of Node structs as opposed to pointers.
Fix these manually.
Passes toolstash -cmp.
Change-Id: I8bdbb33216737c09e1edda284d5c414422d86284
Reviewed-on: https://go-review.googlesource.com/c/go/+/273006
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently, gentraceback decides which frames to print or elide when
unwinding inlined frames using only the name of the outermost
function. If the outermost function should be elided, then inlined
functions will also be elided, even if they shouldn't be.
This happens in practice in at least one situation. As of CL 258938,
exported Go functions (and functions they call) can now be inlined
into the generated _cgoexp_HASH_FN function. The runtime elides
_cgoexp_HASH_FN from tracebacks because it doesn't contain a ".".
Because of this bug, it also elides anything that was inlined into it.
This CL fixes this by synthesizing a funcInfo for the inlined
functions to pass to showframe.
Fixes#42754.
Change-Id: Ie6c663a4a1ac7f0d4beb1aa60bc26fc8cddd0f9d
Reviewed-on: https://go-review.googlesource.com/c/go/+/272131
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
evconst is one of the largest sources of Op rewrites,
which prevent separating different kinds of nodes
(in this case, arithmetic nodes and OLITERAL nodes).
The change in swt.go is necessary because otherwise
the syntax graph ends up containing that OLEN expression
multiple times, which violates the invariant that it's a tree
except for ONAME, OLITERAL, and OTYPE nodes.
(Before, the OLEN was overwritten by an OLITERAL, so the
invariant still held, but now that we don't overwrite it,
we need a different copy for each instance.)
Passes toolstash -cmp.
Change-Id: Ia004774ab6852fb384805d0f9f9f234b40842811
Reviewed-on: https://go-review.googlesource.com/c/go/+/272869
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The leftover n.List is clearly unnecessary, but it makes the
inlining cost of the expression unnecessarily high.
This change breaks toolstash -cmp:
# cmd/internal/src
toolstash: compiler output differs, with optimizers disabled (-N)
inconsistent log line:
/tmp/go-build866291351/b230/_pkg_.a.log:77:
/Users/rsc/go/src/cmd/internal/src/pos.go:275:6: can inline (*PosBase).SymFilename with cost 9 as: method(*PosBase) func() string { if b != nil { return b.symFilename }; return "gofile..??" }
/tmp/go-build866291351/b230/_pkg_.a.stash.log:77:
/Users/rsc/go/src/cmd/internal/src/pos.go:275:6: can inline (*PosBase).SymFilename with cost 11 as: method(*PosBase) func() string { if b != nil { return b.symFilename }; return "gofile..??" }
Separated from other constant work so that the bigger CL can pass toolstash -cmp.
Change-Id: I5c7ddbc8373207b5b9824eafb8639488da0ca1b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/272868
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
A method expression today is an ONAME that has none of the
invariants or properties of other ONAMEs and is always a special case
(hence the Node.IsMethodExpression method).
Remove the special cases by making a separate Op.
Passes toolstash -cmp.
Change-Id: I7667693c9155d5486a6924dbf75ebb59891c4afc
Reviewed-on: https://go-review.googlesource.com/c/go/+/272867
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This CL is obviously OK but does not pass toolstash -cmp,
because it renumbers the Op codes. In a separate CL so that
we can use toolstash -cmp on the CL with real changes
related to OMETHEXPR.
Change-Id: I1db978e3f2652b3bdf51f7981a3ba5137641c8c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/272866
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The original meaning of type Func was "extra fields factored out
of a few cases of type Node having to do with functions",
but those specific cases didn't necessarily have any relation.
A typical declared function is represented by an ODCLFUNC Node
at its declaration and an ONAME node at its uses, and both those
have a .Func field, but they are *different* Funcs.
Similarly, a closure is represented both by an OCLOSURE Node for
the value itself and an ODCLFUNC Node for the underlying function
implementing the closure. Those too have *different* Funcs,
and the Func.Closure field in one points to the other and vice versa.
This has led to no end of confusion over the years.
This CL elevates type Func to be the canonical identifier for
a given Go function.
This looks like a trivial CL but in fact is the result of a lot of
scaffolding and rewriting, discarded once the result was achieved, to
separate out the three different kinds of Func nodes into three
separate fields, limited in use to each specific Node type, to
understand which Func fields are used by which Node types and what the
possible overlaps are. There were a few overlaps, most notably around
closures, which led to more fields being added to type Func to keep
them separate even though there is now a single Func instead of two
different ones for each function.
A future CL can and should change Curfn to be a *Func instead of
a *Node, finally eliminating the confusion about whether Curfn
is an ODCLFUNC node (as it is most of the time) or an ONAME node
(as it is when type-checking an inlined function body).
Although sizeof_test.go makes it look like Func is growing by two
words, there are now half as many Funcs in a running compilation,
so the memory footprint has actually been reduced substantially.
Change-Id: I598bd96c95728093dc769a835d48f2154a406a61
Reviewed-on: https://go-review.googlesource.com/c/go/+/272253
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The additions were generated using golang.org/x/build/cmd/relnote
at CL 272907. It was modified to find previously-missed entries
by querying the Gerrit API in addition to the maintner corpus.
For #40700.
Updates #41849.
Change-Id: If575984fe40e0133ad5e8fc5411ea5063457250d
Reviewed-on: https://go-review.googlesource.com/c/go/+/272871
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Support is added for parsing type parameters only if the ParseTypeParams
mode is set, otherwise emitting syntax errors for source code that is
invalid without type parameters.
Rather than have large conditional blocks switching between legacy
parser logic and new parser logic, effort is made to minimize special
handling for ParseTypeParams.
Change-Id: I243f6c4b9b8eb1313b838e8649b6cc1e5e8339ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/271218
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
This CL imports changes on the go2go branch to support parsing type
params, as well as the unsubmitted changes from CL 269300 to remove
support for parenthesize type parameter syntax.
Change-Id: I27ab942ce69eab62c2a1800f8f9661c4dcb233fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/270857
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
go/constant relies on strconv for parsing Go literals, while older
versions of strconv either lack recent Go language features (e.g., Go
1.13's new numeric literals) or have errors (e.g., mishandling of
carriage returns in raw string literals prior to Go 1.8).
This requires two changes:
1. Splitting out the internal/bytealg dependency into a separate file,
which can be easily substituted with a simple loop for bootstrap
builds.
2. Updating eisel_lemire.go to not utilize Go 1.13 functionality
(underscores in numeric literals and signed shift counts).
Change-Id: Ib48a858a03b155eebdcd08d577aec2254337e70e
Reviewed-on: https://go-review.googlesource.com/c/go/+/272749
Reviewed-by: Robert Griesemer <gri@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Since CL 255217, we've been able to rely on types.UntypedRune to
identify untyped rune literals, rather than needing Mpint.Rune /
CTRUNE. This makes way for switching to using go/constant, which
doesn't have a separate notion of rune constants distinct from integer
constants.
Passes toolstash-check.
Change-Id: I319861f4758aeea17345c101b167cb307e706a0e
Reviewed-on: https://go-review.googlesource.com/c/go/+/272652
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Properly speaking, "nil" is a zero value, not a constant. So
go/constant does not have a representation for it. To allow replacing
Val with constant.Value, we split out ONIL separately from OLITERAL so
we can get rid of CTNIL.
Passes toolstash-check.
Change-Id: I4c8e60cae3b3c91bbac43b3b0cf2a4ade028d6cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/272650
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Address outstanding TODO, which simplifies subsequent CLs.
Now the compiler always type checks type-switch case clauses (like
gccgo), but it treats clause variables as broken if an appropriate
type cannot be determined for it (like go/types).
Passes toolstash-check.
Change-Id: Iedfe9cdf38c6865211e4b93391f1cf72c1bed136
Reviewed-on: https://go-review.googlesource.com/c/go/+/272648
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
When type switching from interface{} to T, and then returning the T as
interface{} again, it's better to return the original interface{}
value. This avoids needing to heap allocate the T for
non-pointer-shaped types (i.e., int64Val, complexVal, stringVal).
Change-Id: I25c83b3f9ec9bd2ffeec5a65279b68f4fcef8a19
Reviewed-on: https://go-review.googlesource.com/c/go/+/272647
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
The next CL will introduce a package ir to hold the IR definitions.
This CL adjusts a few names and makes a few other minor changes
to make the next CL - an automated one - smoother.
Change-Id: Ie787a34732efd5b3d171bf0c1220b6dd91994ce3
Reviewed-on: https://go-review.googlesource.com/c/go/+/272251
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Prepare for factoring the error API out of this package by
cleaning it up. The doc comments use the intended new names,
which will be introduced in the next CL.
Change-Id: Ie4c8d4262422da32a9a9f750fda42c225b6b42a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/272248
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The current implementation copies Debug, clears a bunch of flags
that are meant to be considered OK, and then checks the result
against the zero value. But more flags are cleared than remain:
it's easier to write and to understand to just check the ones that
need checking.
This phrasing also makes it safe to move more flags into the struct.
It turns out that some of the flags being checked should probably
not be checked, but this CL is meant to be a strict semantic no-op,
so left a TODO to clean up the function a bit more later.
Change-Id: I7afe6d7b32b5b889c40dd339568e8602e02df9bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/271666
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Automated factoring produced by rf script below to replace uses of
Func.Nname with Field.Nname or Node.MethodName as appropriate.
Some dead assignments to Func.Nname are left behind; these will be
removed in a subequent remove-only CL.
Passes toolstash-check.
[git-generate]
cd src/cmd/compile/internal/gc
rf '
ex \
import "cmd/compile/internal/types"; \
var f *types.Field; \
var n *types.Node; \
f.Type.Nname() -> f.Nname; \
f.Type.SetNname(n) -> f.Nname = n; \
f.Type.FuncType().Nname -> f.Nname
ex \
var n *Node; \
asNode(n.Type.Nname()) -> n.MethodName(); \
asNode(n.Type.FuncType().Nname) -> n.MethodName(); \
asNode(callpartMethod(n).Type.Nname()) -> n.MethodName()
'
Change-Id: Iaae054324dfe7da6f5d8b8d57a1e05b58cc5968c
Reviewed-on: https://go-review.googlesource.com/c/go/+/272389
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
There are three bits of method-handling code where we separately go
from Field->Type and then Type->Node. By shuffling the code around a
little to go Field->Type->Node in a single statement, we're able to
more easily remove Type from the operation.
Passes toolstash-check.
Change-Id: Ife98216d70d3b867fa153449abef0e56a4fb242a
Reviewed-on: https://go-review.googlesource.com/c/go/+/272388
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
A common operation throughout the front end is getting the ONAME for a
method used in a method selector, method expression, or method value.
This CL adds MethodName as a uniform API for doing this for all of
these kinds of nodes.
For method selectors (ODOTMETH) and method expressions (ONAMEs where
isMethodExpression reports true), we take advantage of the Node.Opt
field to save the types.Field. This is the approach we already started
taking in golang.org/cl/271217 (caching types.Field in Node.Opt for
ODOT).
For method values (OCALLPART), we continue using the existing
callpartMethod helper function. Escape analysis already uses Node.Opt
for tracking the method value's closure's data flow.
A subsequent, automated refactoring CL will make more use of this
method. For now, we just address a few cases in inl.go that aren't
easily automated.
Passes toolstash-check.
Change-Id: Ic92b288b2d8b2fa7e18e3b68634326b8ef0d869b
Reviewed-on: https://go-review.googlesource.com/c/go/+/272387
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
These are almost always set, so might as well expect callers to
provide them. They're also all required by go/types's corresponding
New{Field,Func,Param,Var} functions, so this eases API compatibility.
Passes toolstash-check.
Change-Id: Ib3fa355d4961243cd285b41915e87652ae2c22f6
Reviewed-on: https://go-review.googlesource.com/c/go/+/272386
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
This aligns the naming with GOARCH using 386 as a build target for
this architecture and makes it more easily found when searching
for documentation related to the build target.
Change-Id: I393bb89dd2f71e568124107b13e1b288fbd0c76a
Reviewed-on: https://go-review.googlesource.com/c/go/+/271988
Trust: Martin Möhrmann <moehrmann@google.com>
Run-TryBot: Martin Möhrmann <martisch@uos.de>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Because we're expecting for future functions to be unavailable, we
should add an Unwrap() function to the DLLError struct, so that people
can test for this situation easily via:
if errors.Is(err, syscall.ERROR_PROC_NOT_FOUND) { ... }
DLLError already was wrapping the underlying Errno error, but never got
the Go 1.13 helper method.
Fixesgolang/go#42584
Change-Id: I0f32a5146946b1b37a30897ba825a56faefc792c
Reviewed-on: https://go-review.googlesource.com/c/go/+/269761
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
The Reqs function returns an mvs.Reqs implemention for the global
build list. The API that it presents assumes that the build list is
globally consistent (problematic for #40775) and readily available
(problematic for #36460).
Fortunately, it is no longer used outside of the modload package.
We can instead use individual instances of the unexported mvsReqs
struct, making the dependency on the global build list more explicit.
For #36460
For #40775
Change-Id: I8674442f2a86416b0bf9c3395cb591c1e724c9d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/272129
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Move the declaration of the -overlay flag to base.AddModCommonFlags,
where other flags that are needed for go mod commands and for builds
are declared. The flag's already initialized in modload.Init so
there's no additional work needed to be done to support it in the go
mod commands.
For #39958
Change-Id: I70725d620cc69cb820f6ed923d626f4fe041b1c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/272126
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
ListModules was used to download .info files so that 'go list -m all'
would succeed later when offline. However, 'go list -m all' may
already fail when offline after 'go mod tidy', so it doesn't make
sense to add complexity to 'go get'.
Instead, remove the ListModules call and fix the test that
accidentally depended on it.
For #42723
Change-Id: I692597cf5ca15c23fa6fc9d2bac4b6e044299482
Reviewed-on: https://go-review.googlesource.com/c/go/+/271577
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
As of CL 271646, all external callers have been eliminated. Replace
the remaining internal caller with a direct reference to the buildList
variable and remove the exported function to prevent backsliding.
For #36460
Change-Id: Iea82df1e3e604ada602dda3e830c06d441eee2a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/271647
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The modload.EditBuildList call added in CL 270980 already ensures that
installMod does not require a newer version of itself, so the condition
that this loop is checking for is redundant.
(I had meant for this change to be included in CL 270980, but
apparently somehow reverted it prior to mailing.)
For #36460
Change-Id: I4dd746b927f7012d950187cac9c510cd6fec8fd9
Reviewed-on: https://go-review.googlesource.com/c/go/+/271646
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Trust: Bryan C. Mills <bcmills@google.com>
With this change, constant literals (and results of constant
operations) that internally become infinities are represented
externally (to go/constant) as "unknown" values.
The language has no provisions to deal with infinite constants,
and producing unknown values allows the typechecker to report
errors and avoid invalid operations (such as multiplication of
zero with infinity).
Fixes#20583.
Change-Id: I12f36a17d262ff7957b0d3880241b5a8b2984777
Reviewed-on: https://go-review.googlesource.com/c/go/+/271706
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
At this point in installOutsideModule the build list is empty, so
Selected trivially returns "none" for all modules.
(This change could have been made in CL 266657, but it was a bit
simpler to update the QueryPattern call sites mechanically to ensure
that there would be no unintentional semantic drift.)
For #36460
Change-Id: I44fb73794985bfeebb1dde0c092313f319c2945a
Reviewed-on: https://go-review.googlesource.com/c/go/+/271419
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The 'go install' command does not support the -gccgo flag.
(I'm not sure why, but it doesn't.)
gccgo also uses system-native assembly syntax instead of cmd/compile's
Plan 9 derivative. I've added an assembly file that seems to work on
Linux, but I haven't tested it on other platforms; if it fails on
other platforms, we can refine the test as needed.
Fixes#42688
Change-Id: I0693a6a9eb58975f20cdc4160ef5f9a948563c88
Reviewed-on: https://go-review.googlesource.com/c/go/+/270978
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
The printing of the ptr values can mean that two dump outputs can't easily be
compared for the identical structure, so adding the "-d=dumpptrs" option to make
printing of Node pointer values be an option.
Change-Id: I0e92b02f069e9de2e6fa036a7841645d13cdd7a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/271339
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This updates the callbacks implementation on windows/arm for the
changes made in CL 258938. At the time, that was left as a TODO.
At the same time, it also extends the previous support for only 4
arguments to also support additional arguments on the stack. This is
required for functions like SetWinEventHook, which take 7 arguments. It
does this by pushing r0-r3 onto the stack before the normal prologue,
and then pointing the args struct to that location.
This is derived from CL 270077 and CL 270078.
Updates #40724.
Fixes#42591.
Change-Id: Icc199e7f2c24205e41be4e00015283c7e2a9b797
Reviewed-on: https://go-review.googlesource.com/c/go/+/271178
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Austin Clements <austin@google.com>
For the last remaining call site (in cmd/go/internal/work, added for
the new 'go install pkg@version' codepath in CL 254365), use
EditBuildList instead.
SetBuildList assumes that the caller has enough information to produce
a complete, coherent build list. With lazy loading, producing a
complete, coherent build list is no longer quite so trivial.
In CL 263267, I rewrote the main caller of SetBuildList (the 'go get'
command), and in the process added a more targeted modload hook
(EditBuildList). That hook also suffices for 'go install pkg@version'.
The resulting error messages are perhaps not as smooth as they ought
to be, but if they are too awkward we should probably fix them for
'go get' too, and the commands can continue to share the edit hook.
For #36460
Updates #40276
Change-Id: I698a9dcd2efe6378a4d91f21362880aa8e50001b
Reviewed-on: https://go-review.googlesource.com/c/go/+/270980
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
modload.LoadedModules reveals more information than necessary about
whether modules have been loaded lazily. The 'vendor' subcommand
doesn't actually need that much information: it has all of the
information that it needs from prior calls to LoadPackages and
ModFile.
For #36460
Change-Id: If08733cca930b2b80616b037b63985ecfd6a320b
Reviewed-on: https://go-review.googlesource.com/c/go/+/270979
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The parser reports syntactic errors in constant literals.
The go/constant package produces an "unknown" value for
syntactically correct numeric constants that are too small
or too large. Check for the unknown value and report an
error rather than silently continuing.
Fixes#42695.
Change-Id: I414214559a285d67ed50184dc750f106960b5620
Reviewed-on: https://go-review.googlesource.com/c/go/+/271377
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
When inlining a function call expression, it's possible that the
function callee subexpression has side effects that need to be
preserved. This used to not be an issue, because inlining wouldn't
recognize these as inlinable anyway. But golang.org/cl/266199 extended
the inlining logic to recognize more cases, but did not notice that
the actual inlining code was discarding side effects.
Issue identified by danscales@.
Fixes#42703.
Change-Id: I95f8fc076b6ca4e9362e80ec26dad9d87a5bc44a
Reviewed-on: https://go-review.googlesource.com/c/go/+/271219
Reviewed-by: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
Within the frontend, we generally don't guarantee uniqueness of
anonymous types. For example, each struct type literal gets
represented by its own types.Type instance.
However, the field tracking code was using the struct type as a map
key. This broke in golang.org/cl/256457, because that CL started
changing the inlined parameter variables from using the types.Type of
the declared parameter to that of the call site argument. These are
always identical types (e.g., types.Identical would report true), but
they can be different pointer values, causing the map lookup to fail.
The easiest fix is to simply get rid of the map and instead use
Node.Opt for tracking the types.Field. To mitigate against more latent
field tracking failures (e.g., if any other code were to start trying
to use Opt on ODOT/ODOTPTR fields), we store this field
unconditionally. I also expect having the types.Field will be useful
to other frontend code in the future.
Finally, to make it easier to test field tracking without having to
run make.bash with GOEXPERIMENT=fieldtrack, this commit adds a
-d=fieldtrack flag as an alternative way to enable field tracking
within the compiler. See also #42681.
Fixes#42686.
Change-Id: I6923d206d5e2cab1e6798cba36cae96c1eeaea55
Reviewed-on: https://go-review.googlesource.com/c/go/+/271217
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
RWMutex provides explicit acquire/release synchronization events to the
race detector to model the mutex. It disables sync events within the
methods to avoid e.g., the atomics from adding false synchronization
events, which could cause false negatives in the race detector.
Change-Id: I5126ce2efaab151811ac264864aab1fa025a4aaf
Reviewed-on: https://go-review.googlesource.com/c/go/+/270865
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Michael Pratt <mpratt@google.com>
The child in TestPanicSystemstack prints "x\n" and then blocks on a
lock. Receiving those bytes only indicates that the child is _about to
block_. Since we don't have a way to know when it is fully blocked,
sleep a bit to give it time to block. This makes us less likely to lose
the race and signal before the child blocks, which will fail the test as
the stack trace cannot be read from a running G.
Fixes#33626
Change-Id: I8a27b1b114bf75e1e5bcb2a7a33aa69cdbc22f40
Reviewed-on: https://go-review.googlesource.com/c/go/+/268578
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
On FreeBSD >= 11 with a kernel built with COMPAT_FREEBSD11 but not
COMPAT_FREEBSD10, the pipe syscall is not available. Thus, tests using
runtime.pipe fail with ENOSYS. As suggested by Ian, fix this by calling
pipe2(0) in these tests and fall back to pipe() in case of ENOSYS.
Fixes#42659
Change-Id: Ifbb8008884b7901fe87830d162ad326122c5fab9
Reviewed-on: https://go-review.googlesource.com/c/go/+/270917
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Previously, 'go get' loaded retractions for every module in the build
list, which took a long time and usually wasn't helpful.
This rolls forward CL 269019, which was reverted in CL 270521. The new
revision adds a call to modload.ListModules at the end of 'go get' to
ensure .info files are cached for everything in the build list.
Fixes#42185
Change-Id: I684f66c5e674384d5a0176fbc8317e5530b8a915
Reviewed-on: https://go-review.googlesource.com/c/go/+/270858
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Immediately after a forward Seek, the offset we're writing to is
beyond len(buf)+len(heap):
|<--- buf --->|<--- heap --->|
^
off
If we do a copyHeap at this point, the new heapPos should not be
0:
|<---------- buf ----------->|<-heap->|
^
off
Recompute it.
For #42082.
Change-Id: Icb3e4e1c7bf7d1fd3d76a2e0d7dfcb319c661534
Reviewed-on: https://go-review.googlesource.com/c/go/+/270941
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
The shift amount in SRAconst needs to be in the [0,31] range, so stop
MOVWing -1 to SRA in the Rsh lowering rules.
Also see CL 270117.
Passes
$ GOARCH=mips go build -toolexec 'toolstash -cmp' -a std
$ GOARCH=mipsle go build -toolexec 'toolstash -cmp' -a std
Updates #42587
Change-Id: Ib5eb99b82310e404cc2d6f0c619b21b8a15406ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/270558
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The existing code for map index expressions checked the
wrong variable (x rather than key) to see if the index
assignment was correct. Since x.mode was always valid in
that case, type-checking didn't follow the error exit in
case of an incorrect map index expression.
However, since we know the correct map element type
irrespective of the validity of the map key, the existing
code path is preferrable over exiting early via an error
because the map index expression returns a valid type which
then can be used for further type-checking.
Removed the unneeded 'if' statement and added a test case
producing the expected two errors (rather than only one if
we would "correct" the 'if' statement instead).
In summary, this commit adds a test but doesn't change the
behavior of type-checking of map index expressions.
Change-Id: I67845bfaa03600c9400f9a1462d7a68a66921ad4
Reviewed-on: https://go-review.googlesource.com/c/go/+/270658
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Repair the code that generates PC ranges for DWARF inlined routine
instances to insure that if II Y is a child of II X within the inline
tree, X's ranges include the ranges from Y. This is similar to what
we're already doing for DWARF scopes.
Updates #33188.
Change-Id: I9bb552777fcd1ae93dc01872707667ad092b1dd9
Reviewed-on: https://go-review.googlesource.com/c/go/+/248724
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Trust: Than McIntosh <thanm@google.com>
Some rules for PPC64 were checking for a case
where a shift followed by an 'and' of a mask could
be lowered, depending on the format of the mask. The
function to verify if the mask was valid for this purpose
was not checking if the mask was 0 which we don't want to
allow. This case can happen if previous optimizations
resulted in that mask value.
This fixes isPPC64ValidShiftMask to check for a mask of 0 and return
false.
This also adds a codegen testcase to verify it doesn't try to
match the rules in the future.
Fixes#42610
Change-Id: I565d94e88495f51321ab365d6388c01e791b4dbb
Reviewed-on: https://go-review.googlesource.com/c/go/+/270358
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Paul Murphy <murp@ibm.com>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
When linking internally on OpenBSD, dedup libraries treating versioned
and unversioned libraries as equivalents. Versioned libraries are preferred
and are retained over unversioned libraries.
This avoids the situation where the use of cgo results in a DT_NEEDED for a
versioned library (for example, libc.so.96.1), while a dynamic import
specifies an unversioned library (for example, libc.so). Without deduplication
this would result in two DT_NEEDED entries, causing a failure when ld.so
attempts to load the Go binrary.
Updates #36435Fixes#39257
Change-Id: I4a4942f259dece01d97bb51df9e13d67c9f94d34
Reviewed-on: https://go-review.googlesource.com/c/go/+/249978
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
A missed newline was added for one case in CL 162957, but
the parallel no-output case was missed.
Add the missed newline for the second case and update the test to
cover the full line for both cases.
Updates #30263
Change-Id: I02aa523290295a6d409cd68066b45c6990e6fb6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/258758
Reviewed-by: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
A typo caused the validation rule to check against -WL,-O... which is
not a regular flag because the L should be lowercase as in the other
rules. This caused valid linker flags to be rejected and people had to
work around this by filtering their default flags that include, e.g.,
-Wl,-O1 for a simple link optimization.
Fix the typo that wrongly rejected -Wl,-O... but allowed a non-existing
-WL,-O flag.
Change-Id: Ia3bf730f16f5ad98a39d7f17159de17b44075462
GitHub-Last-Rev: 2ec7f2a2b9
GitHub-Pull-Request: golang/go#42631
Reviewed-on: https://go-review.googlesource.com/c/go/+/270278
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
mips SRA/SLL/SRL shift amounts are used mod 32; this change aligns the
XXXconst rules to mask the shift amount by &31.
Passes
$ GOARCH=mips go build -toolexec 'toolstash -cmp' -a std
$ GOARCH=mipsle go build -toolexec 'toolstash -cmp' -a std
Fixes#42587
Change-Id: I6003ebd0bc500fba4cf6fb10254e1b557bf8c48f
Reviewed-on: https://go-review.googlesource.com/c/go/+/270117
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In certain cases, the declkared type of an OpIData is interface{}.
This was not expected (since interface{} is a pair, right?) and
thus caused a crash. What is intended is that these be treated as
a byteptr, so do that instead (this is what happens in 1.15).
Fixes#42568.
Change-Id: Id7c9e5dc2cbb5d7c71c6748832491ea62b0b339f
Reviewed-on: https://go-review.googlesource.com/c/go/+/270057
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
CL 258938 changed the way C to Go calls work such that they now
construct a C struct on the C side for the arguments and space for the
results. Any pointers in the result space must be zeroed, so we just
zero the whole struct.
However, C makes it surprisingly hard to robustly zero any struct
type. We had used a "{0}" initializer, which works in the vast
majority of cases, but fails if the type is empty or effectively
empty.
This CL fixes this by changing how the cgo tool zero-initializes the
argument struct to be more robust.
Fixes#42495.
Change-Id: Id1749b9d751e59eb7a02a9d44fec0698a2bf63cd
Reviewed-on: https://go-review.googlesource.com/c/go/+/269337
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In chansend() and chanrecv() of chan.go, the order of calls to
raceacquire() and racerelease() was swapped, which meant that the
code was not following the memory model "by the letter of the law."
Similar for bufrecv and bufsend in select.go
The memory model says:
- A send happens before the corresponding receive completes, and
- the kth receive on a channel with capacity C happens before the
k+C send on that channel completes.
The operative word here is "completes." For example, a sender obtains
happens-before information on completion of the send-operation, which
means, after the sender has deposited its message onto the channel.
Similarly for receives.
If the order of raceacquire() and racerelease() is incorrect, the race
detector may fail to report some race conditions.
The fix is minimal from the point of view of Go. The fix does, however,
rely on a new function added to TSan:
https://reviews.llvm.org/D76322
This commit only affects execution when race detection is enabled.
Added two tests into `runtime/race/output_test.go`:
- `chanmm` tests for the issue addressed by this patch
- `mutex` is a test for inverted semaphores, which must not be broken
by this (or any other) patch
Fixes#37355
Change-Id: I5e886879ead2bd456a4b7dd1d17253641b767f63
Reviewed-on: https://go-review.googlesource.com/c/go/+/220419
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
These ioctls take a pid_t (generally a C integer aka int32) and not an int64 - we
currently get away with this on little endian 64 bit platforms, since the bytes
fall into the correct place, however this breaks on big endian 64 bit platforms
(like openbsd/mips64).
Update #40995
Change-Id: I622a0543fd562d97f76a7376a84fd2641e6d6a24
Reviewed-on: https://go-review.googlesource.com/c/go/+/267605
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This change moves the code in work.(*Builder).cgo that, when there is
an overlay, copies non-Go files to objdir into work.(*Builder).Build,
and creates an overlay structure mapping from the nominal file paths
into the copies in objdir. That's propagated through to
work.(*Builder).ccompile, which will use it to pass in the path to the
overlaid contents in objdir when calling the compiler.
This allows for overlays of C/C++/Fortran files.
For #39958
Change-Id: I9a2e3d3ba6afdf7ce19be1dbf4eee34805cdc05f
Reviewed-on: https://go-review.googlesource.com/c/go/+/266376
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
A hand-edited object file can have a symbol name that uses newline and
other normally invalid characters. The cgo tool will generate Go files
containing symbol names, unquoted. That can permit those symbol names
to inject Go code into a cgo-generated file. If that Go code uses the
//go:cgo_ldflag pragma, it can cause the C linker to run arbitrary
code when building a package. If you build an imported package we
permit arbitrary code at run time, but we don't want to permit it at
package build time. This CL prevents this in two ways.
In cgo, reject invalid symbols that contain non-printable or space
characters, or that contain anything that looks like a Go comment.
In the go tool, double check all //go:cgo_ldflag directives in
generated code, to make sure they follow the existing LDFLAG restrictions.
Thanks to Imre Rad / https://www.linkedin.com/in/imre-rad-2358749b for
reporting this.
Fixes CVE-2020-28367
Change-Id: Ia1ad8f3791ea79612690fa7d26ac451d0f6df7c1
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/895832
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/269658
Trust: Katie Hockman <katie@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
Run-TryBot: Katie Hockman <katie@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
TestSetuidEtc() was failing sporadically on linux-ppc64. From the
three https://build.golang.org/ logs, it looked like the logged
errors could be associated with threads dying, but proc reads
were, in some way, racing with their demise.
Exploring ways to increase thread demise, revealed that races
of this type can happen on non-ppc64 systems, and that
os.IsNotExist(err) was not a sufficient error condition test
for a thread's status file disappearing. This change includes a
fix for that to.
The actual issue on linux-ppc64 appears to be tied to PID reaping
and reuse latency on whatever the build test environment is for
linux-ppc64-buildlet. I suspect this can happen on any linux
system, however, especially where the container has a limited PID
range.
The fix for this, limited to the test (the runtime syscall support
is unchanged), is to confirm that the Pid for the interrogated
thread's /proc/<TID>/status file confirms that it is still
associated with the test-process' PID.
linux-ppc64-buildlet:
go/bin/go test syscall -run=TestSetuidEtc -count=10000
ok syscall 104.285s
Fixes#42462
Change-Id: I55c84ab8361003570a405fa52ffec4949bf91113
Reviewed-on: https://go-review.googlesource.com/c/go/+/268717
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Store the PC instead of the string name of the function, and defer
that conversion until we need it.
Helper is still relatively expensive in CPU time (few hundred ns),
but memory allocation is now constant for a test rather than linear in
the number of times Helper is called.
benchstat:
name old time/op new time/op delta
TBHelper-4 1.30µs ±27% 0.53µs ± 1% -59.03% (p=0.008 n=5+5)
name old alloc/op new alloc/op delta
TBHelper-4 216B ± 0% 0B -100.00% (p=0.008 n=5+5)
name old allocs/op new allocs/op delta
TBHelper-4 2.00 ± 0% 0.00 -100.00% (p=0.008 n=5+5)
Change-Id: I6565feb491513815e1058637d086b0374fa94e19
GitHub-Last-Rev: c2329cf225
GitHub-Pull-Request: golang/go#38834
Reviewed-on: https://go-review.googlesource.com/c/go/+/231717
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
This cl is a roll-forward of golang.org/cl/265758, which was rolled back
in golang.org/cl/268900. The changes made are removing cgofiles
from the list of files that are copied to objdir (because the cgofiles
themselves aren't actually provided to the compiler) and fixing test
cases to properly provide the overlay flag and to allow for paths with
backslashes (as in Windows).
The previous cl (golang.org/cl/262618) copied non-overlaid cgo files
to objdir, mostly to get around the issue that otherwise cgo-generated
files were written out with the wrong names (they'd get the base path
of the overlay file containing the replaced contents, instead of the
base path of the path whose contents are being replaced). So that CL
it would copy the files to objdir with the base path of the file
being replaced to circumvent that.
This CL changes cmd/go and cmd/cgo so that instead of copying
files, it passes the actual path of the file on disk either of
the original file (if it is not overlaid) or its replacement
file (if it is) as well as a flag --path_rewrite, newly added to
cmd/cgo, that specifies the actual original file path that corresponds
to the replaced files.
Updates #39958
Change-Id: Ia45b022f9d27cfce0f9ec6da5f3a9f53654c67b8
Reviewed-on: https://go-review.googlesource.com/c/go/+/269017
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The comment explains differences between WalkDirFunc and WalkFunc,
but when this code moved out of path/filepath, we forgot to change
the reference to be filepath.WalkFunc. Fix that.
(The text should not be deleted, because path/filepath does not
contain this type - WalkDirFunc - nor this text anymore.)
Pointed out by Carl Johnson on CL 243916 post-submit.
For #41190.
Change-Id: I44c64d0b7e60cd6d3694cfd6d0b95468ec4612fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/268417
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
The Go 1.16 code freeze has recently started. This is a time to update
all golang.org/x/... module versions that contribute packages to the
std and cmd modules in the standard library to latest master versions.
Those versions have already gone through code review, and now they
will undergo additional testing during the upcoming freeze period.
If new issues in these dependencies are discovered, we have the freeze
period to address them. By the end of the freeze period, we will have
confidence that the Go 1.16 release and the dependency versions it has
selected are robust.
The dependency module versions that are selected in this commit are:
github.com/google/pprof v0.0.0-20201007051231-1066cbb265c7
github.com/ianlancetaylor/demangle v0.0.0-20200414190113-039b1ae3a340
golang.org/x/arch v0.0.0-20201008161808-52c3e6f60cff
golang.org/x/crypto v0.0.0-20201016220609-9e8e0b390897
golang.org/x/mod v0.3.1-0.20200828183125-ce943fd02449
golang.org/x/net v0.0.0-20201029221708-28c70e62bb1d
golang.org/x/sys v0.0.0-20201110211018-35f3e6cf4a65
golang.org/x/text v0.3.4
golang.org/x/tools v0.0.0-20201110201400-7099162a900a
golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1
This change was created with a program from CL 256357 patch set 3
(which updates golang.org/x modules only) and the latest bundle tool,
but replacing golang.org/x/net version with a slightly older commit
golang/net@28c70e62bb due to #42498:
$ updatestd -goroot=$HOME/gotip -branch=master
> go version
go version devel +ecc3f5112e Thu Nov 5 23:21:33 2020 +0000 darwin/amd64
> go env GOROOT
/Users/dmitshur/gotip
> go version -m /Users/dmitshur/go/bin/bundle
/Users/dmitshur/go/bin/bundle: go1.15.4
path golang.org/x/tools/cmd/bundle
mod golang.org/x/tools v0.0.0-20201110201400-7099162a900a h1:5E6TPwSBG74zT8xSrVc8W59K4ch4NFobVTnh2BYzHyU=
dep golang.org/x/mod v0.3.0 h1:RM4zey1++hCTbCVQfnWeKs9/IEsaBLA8vTkd0WVtmH4=
dep golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1 h1:go1bK/D/BFZV2I8cIQd1NKEZ+0owSTG1fDTci4IqFcE=
updating module cmd in /Users/dmitshur/gotip/src/cmd
skipping github.com/chzyer/logex (out of scope, it's not a golang.org/x dependency)
skipping github.com/chzyer/readline (out of scope, it's not a golang.org/x dependency)
skipping github.com/chzyer/test (out of scope, it's not a golang.org/x dependency)
skipping github.com/google/pprof (out of scope, it's not a golang.org/x dependency)
skipping github.com/ianlancetaylor/demangle (out of scope, it's not a golang.org/x dependency)
skipping github.com/yuin/goldmark (out of scope, it's not a golang.org/x dependency)
skipping rsc.io/pdf (out of scope, it's not a golang.org/x dependency)
> go mod edit -go=1.16
> go get -d golang.org/x/arch@52c3e6f60cffa0133a3f9b2fc7f6862504a6cba0 golang.org/x/crypto@9e8e0b390897c84cad53ebe9ed2d1d331a5394d9 golang.org/x/mod@ce943fd02449f621243c9ea6e64098e84752b92b golang.org/x/net@28c70e62bb1d140c3f2579fb7bb5095134d9cb1e golang.org/x/sync@67f06af15bc961c363a7260195bcd53487529a21 golang.org/x/sys@35f3e6cf4a65a85bc280e5fe63faed8ac8b25721 golang.org/x/text@22f1617af38ed4cd65b3b96e02bab267e560155c golang.org/x/tools@7099162a900ae8260c5b97cfaf5f374243dfa742 golang.org/x/xerrors@5ec99f83aff198f5fbd629d6c8d8eb38a04218ca
> go mod tidy
> go mod vendor
updating module std in /Users/dmitshur/gotip/src
> go mod edit -go=1.16
> go get -d golang.org/x/crypto@9e8e0b390897c84cad53ebe9ed2d1d331a5394d9 golang.org/x/net@28c70e62bb1d140c3f2579fb7bb5095134d9cb1e golang.org/x/sys@35f3e6cf4a65a85bc280e5fe63faed8ac8b25721 golang.org/x/text@22f1617af38ed4cd65b3b96e02bab267e560155c golang.org/x/tools@7099162a900ae8260c5b97cfaf5f374243dfa742
> go mod tidy
> go mod vendor
updating bundles in /Users/dmitshur/gotip/src
> go generate -run=bundle std cmd
golang.org/x/net will be updated further later, after #42498 is fixed.
github.com/google/pprof and github.com/ianlancetaylor/demangle
contribute packages but are out of scope for this generated CL.
Also rename http2configureTransport in net/http to follow the internal
rename that happened in CL 264017 to fix the build.
For #36905.
Updates #41721.
Updates #42498.
Change-Id: Ifcd2e76f0406e389b6db88041ca51cd0a2115152
Reviewed-on: https://go-review.googlesource.com/c/go/+/266898
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
This is an extra variable available via 'go env', but not read from the
user's environment. It corresponds to the same string that
runtime.Version returns, assuming a program is built by the same version
of Go.
It's similar to the output of 'go version', but without the "go version"
prefix nor the "$GOOS/$GOARCH" suffix.
The main use case here is tools, which often use 'go env' to query basic
information about the installed Go tree. Its version was one missing
piece of information, which required an extra call to 'go version'
before this change.
Fixes#41116.
Change-Id: I5c9d8c2ba856c816c9f4c462ba73c907b3441445
Reviewed-on: https://go-review.googlesource.com/c/go/+/265637
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Trust: Daniel Martí <mvdan@mvdan.cc>
The previous cl (golang.org/cl/262618) copied non-overlaid cgo files
to objdir, mostly to get around the issue that otherwise cgo-generated
files were written out with the wrong names (they'd get the base path
of the overlay file containing the replaced contents, instead of the
base path of the path whose contents are being replaced). So that CL
it would copy the files to objdir with the base path of the file
being replaced to circumvent that.
This CL changes cmd/go and cmd/cgo so that instead of copying
files, it passes the actual path of the file on disk either of
the original file (if it is not overlaid) or its replacement
file (if it is) as well as a flag --path_rewrite, newly added to
cmd/cgo, that specifies the actual original file path that corresponds
to the replaced files.
Updates #39958
Change-Id: Ic4aae5ef77fe405011fcdce7f6c162488d13daa2
Reviewed-on: https://go-review.googlesource.com/c/go/+/265758
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
SYNC is supposed to correspond to 'fast-BCR-serialization' which is
encoded as 'bcr 14,0'. In CL 197178 I accidentally modified the
encoding to 'bcr 7,0' which is a no-op. This CL reverses that change.
Fixes#42479.
Change-Id: I9918d93d720f5e12acc3014cde20d2d32cc87ee5
Reviewed-on: https://go-review.googlesource.com/c/go/+/268797
Run-TryBot: Michael Munday <mike.munday@ibm.com>
Trust: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
https://man7.org/linux/man-pages/man2/copy_file_range.2.html#VERSIONS states:
A major rework of the kernel implementation occurred in 5.3. Areas
of the API that weren't clearly defined were clarified and the API
bounds are much more strictly checked than on earlier kernels.
Applications should target the behaviour and requirements of 5.3
kernels.
Rather than attempting to detect the file system for source and
destination files (which means two additional statfs syscalls) and skip
copy_file_range in case of known defects (e.g. CIFS -> CIFS), just
assume copy_file_range to be broken on kernels < 5.3.
Fixes#42400
Change-Id: I3a531296182c1d6e341772cc9d2be5bf83e52575
Reviewed-on: https://go-review.googlesource.com/c/go/+/268338
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
test_race_install checks that 'go test -i -race …' does not rebuild
already installed packages, by also passing '-v' and verifying that no
package names are printed to stderr.
CL 266368 added a deprecation message for the '-i' flag that caused
the stderr output to be non-empty, although it still does not print
any package names.
Updates #41696
Change-Id: I13e10e49b7c33139be9b13f24cb393c9f58fd85d
Reviewed-on: https://go-review.googlesource.com/c/go/+/268581
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
When either the server or client are lacking hardware support for
AES-GCM ciphers, indicated by the server lacking the relevant
instructions and by the client not putting AES-GCM ciphers at the top
of its preference list, reorder the preference list to de-prioritize
AES-GCM based ciphers when they are adjacent to other AEAD ciphers.
Also updates a number of recorded openssl TLS tests which previously
only specified TLS 1.2 cipher preferences (using -cipher), but not
TLS 1.3 cipher preferences (using -ciphersuites), to specify both
preferences, making these tests more predictable.
Fixes#41181.
Change-Id: Ied896c96c095481e755aaff9ff0746fb4cb9568e
Reviewed-on: https://go-review.googlesource.com/c/go/+/262857
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
Trust: Katie Hockman <katie@golang.org>
This reverts commit 3a81338622.
Reason for revert: Some edge cases not properly covered due to changes within runtime traceback generation since 2017, that need to be examined. This change landed very late in the Go1.16 cycle.
Change-Id: I8cf6f46ea0ef6161d878e79943e6c7cdac94bccf
Reviewed-on: https://go-review.googlesource.com/c/go/+/268577
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This code was preserved just to do side-by-side testing while
transitioning to the Go implementation. There haven't been mismatch
issues, so drop the cgo code, which was making it hard to improve the Go
code without diverging.
Change-Id: I2a23039c31a46e88b94250aafbc98d4ea8daf22f
Reviewed-on: https://go-review.googlesource.com/c/go/+/232397
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This is a SHALL in RFC 7301, Section 3.2.
Also some more cleanup after NPN, which worked the other way around
(with the possibility that the client could pick a protocol the server
did not suggest).
Change-Id: I83cc43ca1b3c686dfece8315436441c077065d82
Reviewed-on: https://go-review.googlesource.com/c/go/+/239748
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
This is a roll-forward of golang.org/cl/267197, which was reverted in
golang.org/cl/267357. It makes the following changes in addition to
the ones in the next paragraph: It avoids outputting trimpath
arguments for an overlay unless the overlay affects the package being
compiled (to avoid hitting windows command line argument limits), and
it fixes processing of regexps in the script test framework to treat
the first *non flag* argument to grep, stdout, and stderr as a regexp,
not just the first argument.
golang.org/cl/267917 was a roll-forward of golang.org/cl/262618, which
was reverted in golang.org/cl/267037. The only differences between
this CL and the original were the three calls to fflush from the C
files in build_overlay.txt, to guarantee that the string we were
expecting was
actually written out.
The CL requires rewriting the paths of the files passed to the cgo
tool toolchain to use the overlaid paths instead of the disk paths of
files. Because the directories of the overlaid paths don't exist in
general, the cgo tool have been updated to run in base.Cwd instead of
the package directory.
For #39958
Change-Id: I1bd96db257564bcfd95b3502aeca14d04bd28618
Reviewed-on: https://go-review.googlesource.com/c/go/+/267797
Trust: Michael Matloob <matloob@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Adds the (*tls.Conn).HandshakeContext method. This allows
us to pass the context provided down the call stack to
eventually reach the tls.ClientHelloInfo and
tls.CertificateRequestInfo structs.
These contexts are exposed to the user as read-only via Context()
methods.
This allows users of (*tls.Config).GetCertificate and
(*tls.Config).GetClientCertificate to use the context for
request scoped parameters and cancellation.
Replace uses of (*tls.Conn).Handshake with (*tls.Conn).HandshakeContext
where appropriate, to propagate existing contexts.
Fixes#32406
Change-Id: I33c228904fe82dcf57683b63627497d3eb841ff2
Reviewed-on: https://go-review.googlesource.com/c/go/+/246338
Run-TryBot: Filippo Valsorda <filippo@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Previously windows only returned the certificate-chain with the highest quality.
This change makes it so chains with a potentially lower quality
originating from other root certificates are also returned by verify.
Tests in verify_test flagged with systemLax are now allowed to pass if the system returns additional chains
Fixes#40604
Change-Id: I66edc233219f581039d47a15f2200ff627154691
Reviewed-on: https://go-review.googlesource.com/c/go/+/257257
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Without HOME or FOSSIL_HOME set, this test fails for me when run with
fossil 2.12.1.
Also verify that the 'go get' command produces an executable, which
helps to verify that the files extracted by fossil are not corrupted.
Updates #42323
Change-Id: Ie6f5d2eab6a6338e997a4f85591195e5bd9a0d37
Reviewed-on: https://go-review.googlesource.com/c/go/+/267884
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Adds the following additional convenience fields to CertificateRequest:
* KeyUsage
* ExtKeyUsage
* UnknownExtKeyUsage
* IsCA
* MaxPathLen
* BasicConstraintsValid
* MaxPathLenZero
* SubjectKeyId
* PolicyIdentifier
These fields are parsed during ParseCertificateRequest and marshalled
during CreateCertificateRequest. The parsing/marshalling code is
factored out of parseCertificate and buildExtensions (which is renamed
buildCertExtensions). This has the side effect of making these methods
somewhat easier to read.
Documentation for the fields is copied from Certificate.
Example CSR created with all of these fields parsed with openssl:
$ openssl req -in ~/test-csr.pem -noout -text
Certificate Request:
Data:
Version: 0 (0x0)
Subject:
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (256 bit)
pub:
04:a4:cb:64:35:8e:dd:8c:2b:a6:f1:aa:39:d1:be:
d0:b9:95:1e:59:19:82:76:28:d3:85:1b:c6:88:62:
e1:15:33:be:26:18:80:14:fe:f4:d4:91:66:4e:a4:
a4:47:bd:53:db:f7:2e:e3:31:ce:5f:86:cb:92:59:
93:bb:d0:7f:a2
ASN1 OID: prime256v1
NIST CURVE: P-256
Attributes:
Requested Extensions:
X509v3 Key Usage: critical
Certificate Sign
X509v3 Extended Key Usage:
Any Extended Key Usage, 1.2.3
X509v3 Basic Constraints: critical
CA:TRUE, pathlen:0
X509v3 Subject Key Identifier:
01:02:03
X509v3 Certificate Policies:
Policy: 1.2.3
Signature Algorithm: ecdsa-with-SHA256
30:45:02:21:00:a7:88:e5:96:d4:ad:ae:24:26:ab:5f:15:6a:
3f:22:6d:0e:a6:ba:15:64:8d:78:34:f4:c4:7d:ac:37:b0:2a:
84:02:20:68:44:f0:8e:8a:1b:c1:68:be:14:a6:e3:83:41:fd:
2d:cc:00:aa:bc:50:f6:50:56:12:9e:a4:09:84:5c:bf:c1
Fixes#37172
Change-Id: Ife79d01e203827ef0ac3c787aa13c00d0751a1ec
Reviewed-on: https://go-review.googlesource.com/c/go/+/233163
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Trust: Katie Hockman <katie@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
When a variable symbol is both imported (possibly through
inlining) and linkname'd, make sure its LSym is marked as
non-package for symbol indexing in the object file, so it is
resolved by name and dedup'd with the original definition.
Fixes#42401.
Change-Id: I8e90c0418c6f46a048945c5fdc06c022b77ed68d
Reviewed-on: https://go-review.googlesource.com/c/go/+/268178
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
The go command runs commands like git and hg to download modules.
In the past, we have had problems with security bugs in version
control systems becoming security bugs in “go get”.
The original modules draft design removed use of these commands
entirely, saying:
> We want to move away from invoking version control tools such as bzr,
> fossil, git, hg, and svn to download source code. These fragment the
> ecosystem: packages developed using Bazaar or Fossil, for example, are
> effectively unavailable to users who cannot or choose not to install
> these tools. The version control tools have also been a source of
> exciting security problems. It would be good to move them outside the
> security perimeter.
The removal of these commands was not possible in the end: being able
to fetch directly from Git repos is too important, especially for
closed source. But the security exposure has not gone away.
We remain vulnerable to problems in VCS systems, especially the less
scrutinized ones.
This change adds a GOVCS setting to let users control which version
control systems are allowed by default.
It also changes the default allowed version control systems to git and hg
for public code and any version control system for private code
(import path or module path matched by the GOPRIVATE setting).
See the changes in alldocs.go for detailed documentation.
See #41730 for proposal and discussion.
Fixes#41730.
[Replay of CL 266420. See changes from Patch Set 1 for updates to fix
a few long tests.]
Change-Id: I4fe93804548956c42aea985368b4571bdb220f48
Reviewed-on: https://go-review.googlesource.com/c/go/+/267888
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Extended the sorting logic to be stable even when there are two roots
with the same name and notBefore timestamp, like the GlobalSign ones.
Updates #38843
Change-Id: Ie4db0bb8b6a8b5ffbb7390b6bd527fc0c3badaca
Reviewed-on: https://go-review.googlesource.com/c/go/+/266677
Reviewed-by: Katie Hockman <katie@golang.org>
Trust: Filippo Valsorda <filippo@golang.org>
Currently, the benchmark output from the testing package prints small
values with three significant figures. This means it can only
distinguish 1 part in 100, or a 1% error, which can be enough to throw
off further analysis of the output. This CL increases it to four
significant figures. For time values, at least, anything beyond four
significant figures is almost certainly noise.
Fixes#34626.
Change-Id: I3bcf305427130026276e6a4c78167989319f280c
Reviewed-on: https://go-review.googlesource.com/c/go/+/267102
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Instead of parsing the PEM files and then storing the *Certificate
values forever, still parse them to see if they're valid and pick out
some fields, but then only store the decoded pem.Block.Bytes until
that cert is first needed.
Saves about 500K of memory on my (Debian stable) machine after doing a
tls.Dial or calling x509.SystemCertPool.
A more aggressive version of this is still possible: we can not keep
the pem.Block.Bytes in memory either, and re-read them from disk when
necessary. But dealing with files disappearing and even large
multi-cert PEM files changing (with offsets sliding around) made this
conservative version attractive. It doesn't change the
slurp-roots-on-startup semantics. It just does so with less memory
retained.
Change-Id: I3aea333f4749ae3b0026042ec3ff7ac015c72204
Reviewed-on: https://go-review.googlesource.com/c/go/+/230025
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
This will allow building CertPools that consume less memory. (Most
certs are never accessed. Different users/programs access different
ones, but not many.)
This CL only adds the new internal mechanism (and uses it for the
old AddCert) but does not modify any existing root pool behavior.
(That is, the default Unix roots are still all slurped into memory as
of this CL)
Change-Id: Ib3a42e4050627b5e34413c595d8ced839c7bfa14
Reviewed-on: https://go-review.googlesource.com/c/go/+/229917
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Trust: Roland Shoemaker <roland@golang.org>
Reviewed-by: Filippo Valsorda <filippo@golang.org>
Reviewed-by: Roland Shoemaker <roland@golang.org>
CL 244579 added guard clauses to prevent a faulty state that was
possible under the incorrect logic of the uniquePred loop in
addLocalInductiveFacts. That faulty state was still making the
intended optimization, but not for the correct reason.
Removing the faulty state also removed the overly permissive application
of the optimization, and therefore made these two tests fail.
We disabled the tests of this optimization in CL 244579 to allow us to
quickly apply the fix in the CL. This CL now corrects the logic of the
uniquePred loop in order to apply the optimization correctly.
The comment above the uniquePred loop says that it will follow unique
predecessors until it reaches a join point. Without updating the child
node on each iteration, it cannot follow the chain of unique
predecessors more than one step. Adding the update to the child node
on each iteration of the loop allows the logic to follow the chain of
unique predecessors until reaching a join point (because a non-unique
predecessor will signify a join point).
Updates #40502.
Change-Id: I23d8367046a2ab3ce4be969631f9ba15dc533e6c
Reviewed-on: https://go-review.googlesource.com/c/go/+/246157
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
This CL makes it so that instead of printing massive stack traces during
endless recursion, which spams users and aren't useful, it now prints out
the top and bottom 50 frames. If the number of frames <= 100
(_TracebackMaxFrames), we'll just print all the frames out.
Modified gentraceback to return counts of:
* ntotalframes
* nregularframes
which allows us to get accurate counts of the various kinds of frames.
While here, also fixed a bug that resulted from CL 37222, in which we
no longer accounted for decrementing requested frame skips, and assumed
that when printing, that skip would always be 0. The fix is instead to add
precondition that we'll only print if skip <= 0, but also decrement skip
as we iterate.
Fixes#7181.
Fixes#24628.
Change-Id: Ie31ec6413fdfbe43827b254fef7d99ea26a5277f
Reviewed-on: https://go-review.googlesource.com/c/go/+/37222
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
This CL adds support for inlining type switches, including exporting
and importing them.
Type switches are represented mostly the same as expression switches.
However, if the type switch guard includes a short variable
declaration, then there are two differences: (1) there's an ONONAME
(in the OTYPESW's Left) to represent the overall pseudo declaration;
and (2) there's an ONAME (in each OCASE's Rlist) to represent the
per-case variables.
For simplicity, this CL simply writes out each variable separately
using iimport/iiexport's normal Vargen mechanism for disambiguating
identically named variables within a function. This could be improved
somewhat, but inlinable type switches are probably too uncommon to
merit the complexity.
While here, remove "case OCASE" from typecheck1. We only type check
"case" clauses as part of a "select" or "switch" statement, never as
standalone statements.
Fixes#37837
Change-Id: I8f42f6c9afdd821d6202af4a6bf1dbcbba0ef424
Reviewed-on: https://go-review.googlesource.com/c/go/+/266203
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
This commit is a copy of filepath.WalkDir adapted to use fs.FS
instead of the native OS file system. It is the last implementation
piece of the io/fs proposal.
The original io/fs proposal was to adopt filepath.Walk, but we
have since introduced the more efficient filepath.WalkDir (#42027),
so this CL adopts that more efficient option instead.
(The changes in path/filepath bring the two copies more in line
with each other. The main change is unembedding the field
in statDirEntry, so that the fs.DirEntry passed to the WalkDirFunc
for the root of the tree does not have any extra methods.)
For #41190.
Change-Id: I9359dfcc110338c0ec64535f22cafb38d0b613a6
Reviewed-on: https://go-review.googlesource.com/c/go/+/243916
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
WalkDir is like Walk but can use ReadDir to read directories,
instead of Readdirnames + Lstat on every entry,
which is usually a significant performance improvement.
(The Lstat can still happen if the walk function calls d.Info.)
Fixes#42027.
[Replay of CL 266240 after it was reverted due to accidentally
enabling on Windows a test that does not work on Windows.
The original code only ran the test on os.Getuid() > 0.
The rolled-back CL skipped the test on os.Getuid() == 0.
But on Windows, os.Getuid(), it turns out, always returns -1.
So what looked like a test for root was also excluding Windows.
This CL revises the test to skip Windows explicitly.]
Change-Id: I9b3661013d6449b7486532445d934ae91e5393ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/267887
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Optimize combinations of left and right shifts by a constant value
into a 'rotate then insert selected bits [into zero]' instruction.
Use the same instruction for contiguous masks since it has some
benefits over 'and immediate' (not restricted to 32-bits, does not
overwrite source register).
To keep the complexity of this change under control I've only
implemented 64 bit operations for now.
There are a lot more optimizations that can be done with this
instruction family. However, since their function overlaps with other
instructions we need to be somewhat careful not to break existing
optimization rules by creating optimization dead ends. This is
particularly true of the load/store merging rules which contain lots
of zero extensions and shifts.
This CL does interfere with the store merging rules when an operand
is shifted left before it is stored:
binary.BigEndian.PutUint64(b, x << 1)
This is unfortunate but it's not critical and somewhat complex so
I plan to fix that in a follow up CL.
file before after Δ %
addr2line 4117446 4117282 -164 -0.004%
api 4945184 4942752 -2432 -0.049%
asm 4998079 4991891 -6188 -0.124%
buildid 2685158 2684074 -1084 -0.040%
cgo 4553732 4553394 -338 -0.007%
compile 19294446 19245070 -49376 -0.256%
cover 4897105 4891319 -5786 -0.118%
dist 3544389 3542785 -1604 -0.045%
doc 3926795 3927617 +822 +0.021%
fix 3302958 3293868 -9090 -0.275%
link 6546274 6543456 -2818 -0.043%
nm 4102021 4100825 -1196 -0.029%
objdump 4542431 4548483 +6052 +0.133%
pack 2482465 2416389 -66076 -2.662%
pprof 13366541 13363915 -2626 -0.020%
test2json 2829007 2761515 -67492 -2.386%
trace 10216164 10219684 +3520 +0.034%
vet 6773956 6773572 -384 -0.006%
total 107124151 106917891 -206260 -0.193%
Change-Id: I7591cce41e06867ba10a745daae9333513062746
Reviewed-on: https://go-review.googlesource.com/c/go/+/233317
Run-TryBot: Michael Munday <mike.munday@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Michael Munday <mike.munday@ibm.com>
Remove openbsd/mips64 from incomplete ports lists - all of the necessary code
has landed and we want to run tests so we can see/deal with remaining failures.
Update #40995
Change-Id: I5d4f89af82ff3abe57570a9a8abf889498093d32
Reviewed-on: https://go-review.googlesource.com/c/go/+/267606
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When the compiler refers to a runtime builtin, it emits an indexed
symbol reference in the object file via predetermined/preassigned ID
within the PkgIdxBuiltin pseudo-package. At link time when the loader
encounters these references, it redirects them to the corresponding
defined symbol in the runtime package. This redirection process
currently assumes that if a runtime builtin is referenced, we'll
always have a definition for it. This assumption holds in most cases,
however for the builtins "runtime.racefuncenter" and
"runtime.racefuncexit", we'll only see definitions if the runtime
package we're linking against was built with "-race".
In the bug in question, build passes "-gcflags=-race" during
compilation of the main package, but doesn't pass "-race" directly to
'go build', and as a result the final link combines a
race-instrumented main with a non-race runtime; this results in R_CALL
relocations with zero-valued target symbols, resulting in a panic
during stack checking.
This patch changes the loader's resolve method to detect situations
where we're asking for builtin "runtime.X", but the runtime package
read in doesn't contain a definition for X.
Fixes#42396.
Change-Id: Iafd38bd3b0f7f462868d120ccd4d7d1b88b27436
Reviewed-on: https://go-review.googlesource.com/c/go/+/267881
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Tools often need to associate errors not with a single position, but
with a span of source code. For example, gopls currently estimates
diagnostic spans using heuristics to expand the positions reported by
the type checker to surrounding source code. Unfortunately this is often
inaccurate.
This CL lays the groundwork to solve this within go/types by adding a
start and end position to type checker errors. This is an experimental
API, both because we are uncertain of the ideal representation for these
spans and because their initial positioning is naive. In most cases this
CL simply expands errors to the surrounding ast.Node being typechecked,
if available. This might not be the best error span to present to the
user. For these reasons the API is unexported -- gopls can read these
positions using reflection, allowing us to gain experience and improve
them during the next development cycle.
For golang/go#42290
Change-Id: I39a04d70ea2bb2134b4d4c937f32b2ddb4456430
Reviewed-on: https://go-review.googlesource.com/c/go/+/265250
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Test script expects the regexp argument for stdout, stderr, and cmp
to be the first argument after the command, but that might not be the
case if the -q or -count flags are provided. Treat the first argument
after a flag as a regexp instead.
For #39958
Change-Id: I369926109ec10cca8b2c3baca27e7a3f7baf364b
Reviewed-on: https://go-review.googlesource.com/c/go/+/267877
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
startm contains a critical section from when it takes ownership of a P
(either on function entry or call to pidleput) until it wakes the M
receiving the P. If preempted in this critical section, the owned P is
left in limbo. If preempted for a GC stop, there will be nothing to stop
the owned P and STW will wait forever.
golang.org/cl/232298 introduced the first call to startm that is not on
the system stack (via a wakep call), introducing the possibility of
preemption. Disable preemption in startm to ensure this remains
non-preemptible.
Since we're not always on the system stack anymore, we also need to be
careful in allocm.
Updates #42237
Change-Id: Icb95eef9eb262121856485316098331beea045da
Reviewed-on: https://go-review.googlesource.com/c/go/+/267257
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Michael Pratt <mpratt@google.com>
Previously, we resolved each argument to 'go get' to a package path or
module path based on what was in the build list at existing versions,
even if the argument specified a different version explicitly. That
resulted in bugs like #37438, in which we variously resolved the wrong
version or guessed the wrong argument type for what is unambiguously a
package argument at the requested version.
We were also using a two-step upgrade/downgrade algorithm, which could
not only upgrade more that is strictly necessary, but could also
unintentionally upgrade *above* the requested versions during the
downgrade step.
This change instead uses an iterative approach, with an explicit
disambiguation step for the (rare) cases where an argument could match
the same package path in multiple modules. We use a hook in the
package loader to halt package loading as soon as an incorrect version
is found — preventing over-resolving — and verify that the result
after applying downgrades successfully obtained the requested versions
of all modules.
Making 'go get' be correct and usable is especially important now that
we are defaulting to read-only mode (#40728), for which we are
recommending 'go get' more heavily.
While I'm in here refactoring, I'm also reworking the API boundary
between the modget and modload packages. Previously, the modget
package edited the build list directly, and the modload package
accepted the edited build list without validation. For lazy loading
(#36460), the modload package will need to maintain additional
metadata about the requirement graph, so it needs tighter control over
the changes to the build list.
As of this change, modget no longer invokes MVS directly, but instead
goes through the modload package. The resulting API gives clearer
reasons in case of updates, which we can use to emit more useful
errors.
Fixes#37438
Updates #36460
Updates #40728
Change-Id: I596f0020f3795870dec258147e6fc26a3292c93a
Reviewed-on: https://go-review.googlesource.com/c/go/+/263267
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
This allows a single QueryPattern call to resolve a path that could be
either a package or a module. It is important to be able to make a
single QueryPattern call — rather than a QueryPattern followed by a
Query for the specific module path — to provide appropriate fallback
behavior: if the proxy returns package results but does not contain a
module result, we don't want to fall back to the next proxy to look
for the (probably-nonexistent) module.
For #37438
Change-Id: I419b8bb3ab4565f443bb5cee9a8b206f453b9801
Reviewed-on: https://go-review.googlesource.com/c/go/+/266657
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
CL 242083 corrected an inaccurate error message related to the
assignability of untyped constant values. Previously the error message
was of the form "cannot convert ... to ...", which is misleading when
there is no explicit conversion in the syntax. The new error message
corrected this to "cannot use ... as ... in ...", but also appended an
inner error message that can be quite verbose. For example:
cannot use "123" (untyped string constant) as int value in assignment:
cannot convert "123" (untyped string constant) to int"
This might be more accurate, but is a regression in readability. Correct
this by only including the inner error message in the rare cases where
it is helpful: if the constant value overflows or is truncated.
For golang/go#22070
Change-Id: I8b8ee6ef713f64facc319894be09398b0b5ea500
Reviewed-on: https://go-review.googlesource.com/c/go/+/267717
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Remove all cpu features from the ARM64 struct that are not initialized
to reduce cache lines used and to avoid those features being
accidentially used without actual detection if they are present.
Add missing option to mask the CPUID feature.
Change-Id: I94bf90c0655de1af2218ac72117ac6c52adfc289
Reviewed-on: https://go-review.googlesource.com/c/go/+/267658
Run-TryBot: Martin Möhrmann <moehrmann@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Trust: Martin Möhrmann <moehrmann@google.com>
Fixes the check for RFC 5322 "obsolete time zone" to ensure
that we correctly extract the entire date from the "T" of the
implied time zone.
Obsolete Time zones come in the form:
* GMT
* PST
* MDT
etc, as per Section 4.3 of RFC 5322,
https://tools.ietf.org/html/rfc5322#section-4.3.
The prior check from CL 117596 erronenously used strings.Index
which selects the first "T", and that meant that dates containing
days "Tue" or "Thu" could not be parsed.
We also now deal with "T" in the CFWS "Comment Folding White Space".
Thus we'll now accept dates:
* Thu, 20 Nov 1997 09:55:06 MDT
* Thu, 20 Nov 1997 09:55:06 MDT (MDT)
* Fri, 21 Nov 1997 09:55:06 MDT (This comment)
* Fri, 21 Nov 1997 09:55:06 MDT (MDT
Fixes#39260
Change-Id: I6d59d99bc4f05a82582c826b5c5a080a25fd999b
Reviewed-on: https://go-review.googlesource.com/c/go/+/235200
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
The go command runs commands like git and hg to download modules.
In the past, we have had problems with security bugs in version
control systems becoming security bugs in “go get”.
The original modules draft design removed use of these commands
entirely, saying:
> We want to move away from invoking version control tools such as bzr,
> fossil, git, hg, and svn to download source code. These fragment the
> ecosystem: packages developed using Bazaar or Fossil, for example, are
> effectively unavailable to users who cannot or choose not to install
> these tools. The version control tools have also been a source of
> exciting security problems. It would be good to move them outside the
> security perimeter.
The removal of these commands was not possible in the end: being able
to fetch directly from Git repos is too important, especially for
closed source. But the security exposure has not gone away.
We remain vulnerable to problems in VCS systems, especially the less
scrutinized ones.
This change adds a GOVCS setting to let users control which version
control systems are allowed by default.
It also changes the default allowed version control systems to git and hg
for public code and any version control system for private code
(import path or module path matched by the GOPRIVATE setting).
See the changes in alldocs.go for detailed documentation.
See #41730 for proposal and discussion.
Fixes#41730.
Change-Id: I1999ddf7445b36a7572965be5897c7a1ff7f4265
Reviewed-on: https://go-review.googlesource.com/c/go/+/266420
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
WalkDir is like Walk but can use ReadDir to read directories,
instead of Readdirnames + Lstat on every entry,
which is usually a significant performance improvement.
(The Lstat can still happen if the walk function calls d.Info.)
Fixes#42027.
Change-Id: Ie11024b23be2656e320d41fd81ff0d8810aa729e
Reviewed-on: https://go-review.googlesource.com/c/go/+/266240
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
The wrong value for the first reg parameter was selected.
Likewise the wrong opcode was selected. This should match
rlwnm (rrr type), not rlwinm (irr type).
Similarly, fix the optab matching rules so clrlslwi does
not match reg,reg,const,reg arguments. This is not a valid
operand combination for clrlslwi.
Fixes#42368
Change-Id: I4eb16d45a760b9fd3f497ef9863f82465351d39f
Reviewed-on: https://go-review.googlesource.com/c/go/+/267421
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
The refactoring of this code while adding ReadDir stopped
pre-allocating a 100-entry slice for the results.
That seemed like a good idea in general, since many
directories have nowhere near 100 entries, but it had the
side effect of returning a nil slice for an empty directory.
Some “golden” tests that are too sensitive about nil vs not
inside Google broke because Readdirnames(-1) was now
returning nil instead of []string{} on an empty directory.
It seems likely there are other such tests in the wild, and
it doesn't seem worth breaking them.
This commit restores the non-nil-ness of the old result,
without restoring the excessive preallocation.
Fixes#42367.
Change-Id: I2be72030ac703346e859a97c2d4e456fadfce9b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/267637
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
A recent update of the Fossil SCM application changes
the line prefix when the fossil info command is used.
Instead of the revision hash starting with "uuid:", it has been
changed to "hash:".
Fossil check-in introducing this change:
https://fossil-scm.org/home/info/8ad5e4690854a81a
To support older and new versions, fossilParseStat will
now check for either version of the prefix when attempting
to find the line containing the hash of the desired revision.
Fixes#42323
Change-Id: I6eff49f9989b37b295322a8569e222a1fd02f6e3
GitHub-Last-Rev: f4e6652307
GitHub-Pull-Request: golang/go#42324
Reviewed-on: https://go-review.googlesource.com/c/go/+/267080
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
The LDANDx instructions were misleading because they correspond to the
mnemonic LDCLRx as defined in the Arm Architecture Reference Manual for
Armv8. This changes the assembler to use the same mnemonic as the GNU
assembler and the manual.
The instruction has the form:
LDCLRx Rs, (Rb), Rt: *Rb -> Rt, Rs AND NOT(*Rb) -> *Rb
Change-Id: I94ae003e99e817209bba1afe960e612bf3a0b410
Reviewed-on: https://go-review.googlesource.com/c/go/+/267138
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: fannie zhang <Fannie.Zhang@arm.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: fannie zhang <Fannie.Zhang@arm.com>
Add a physPageAlignedStack boolean which if set, results in over allocation
by a physical page, the allocation being rounded to physical page alignment
and the unused memory surrounding the allocation being freed again.
OpenBSD/octeon has 16KB physical pages and requires stacks to be physical page
aligned in order for them to be remapped as MAP_STACK. This change allows Go
to work on this platform.
Based on a suggestion from mknyszek in issue #41008.
Updates #40995Fixes#41008
Change-Id: Ia5d652292b515916db473043b41f6030094461d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/266919
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is a partial revert of https://go-review.googlesource.com/c/go/+/248219
because we found that a non-trivial amount of code erroneously calls
ParseFloat(s, 10) or even ParseFloat(s, 0) and expects it to work --
before that change was merged, ParseFloat accepted a bitSize of
anything other than 32 or 64 to mean 64 (and ParseComplex was similar).
So revert that behavior to avoid breaking people's code, and add tests
for this.
I may add a vet check to flag ParseFloat(s, not_32_or_64) in a later
change.
See #42297 for more details.
Change-Id: I4bc0156bd74f67a39d5561b6e5fde3f2d20bd622
Reviewed-on: https://go-review.googlesource.com/c/go/+/267319
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Previous fix in issue #20929 for adding comment marker does
not check whether string field have // prefix or not.
This commit ensures string field does not contain // before adding
prefix to the line. Test also included in this commit.
Fixes#40992
Change-Id: Ibc5e8ef147eeb2ed732fb9e19815c8b21fcfb2ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/251237
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
The code I wrote in ldmacho.go in CL 266373 was plainly wrong. It
didn't carry rAdd over correctly. Fixed. Also added sign extension
(as ld64 does).
Internal linking with -race mode now works. Enable it.
Updates #38485.
Change-Id: I78aa949687bf6a0987913059059160b018c7560e
Reviewed-on: https://go-review.googlesource.com/c/go/+/267097
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
This change modifies the consistent stats implementation to keep the
per-P sequence counter on each P instead of each mcache. A valid mcache
is not available everywhere that we want to call e.g. allocSpan, as per
issue #42339. By decoupling these two, we can add a mechanism to allow
contexts without a P to update stats consistently.
In this CL, we achieve that with a mutex. In practice, it will be very
rare for an M to update these stats without a P. Furthermore, the stats
reader also only needs to hold the mutex across the update to "gen"
since once that changes, writers are free to continue updating the new
stats generation. Contention could thus only arise between writers
without a P, and as mentioned earlier, those should be rare.
A nice side-effect of this change is that the consistent stats acquire
and release API becomes simpler.
Fixes#42339.
Change-Id: Ied74ab256f69abd54b550394c8ad7c4c40a5fe34
Reviewed-on: https://go-review.googlesource.com/c/go/+/267158
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
This change moves the responsibility of throwing if an mcache is not
available to the caller, because the inlining cost of throw is set very
high in the compiler. Even if it was reduced down to the cost of a usual
function call, it would still be too expensive, so just move it out.
This choice also makes sense in the context of #42339 since we're going
to have to handle the case where we don't have an mcache to update stats
in a few contexts anyhow.
Also, add getMCache to the list of functions that should be inlined to
prevent future regressions.
getMCache is called on the allocation fast path and because its not
inlined actually causes a significant regression (~10%) in some
microbenchmarks.
Fixes#42305.
Change-Id: I64ac5e4f26b730bd4435ea1069a4a50f55411ced
Reviewed-on: https://go-review.googlesource.com/c/go/+/267157
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is a roll-forward of golang.org/cl/262618, which was reverted in
golang.org/cl/267037. The only differences between this CL and the
original are the three calls to fflush from the C files in
build_overlay.txt, to guarantee that the string we're expecting is
actually written out.
This requires rewriting the paths of the files passed to the cgo tool
toolchain to use the overlaid paths instead of the disk paths of
files. Because the directories of the overlaid paths don't exist in
general, the cgo tool have been updated to run in base.Cwd instead of
the package directory.
For #39958
Change-Id: If7e5e057c62c0c22ddb724f9fe650902fc5f4832
Reviewed-on: https://go-review.googlesource.com/c/go/+/267197
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Trust: Michael Matloob <matloob@golang.org>
In Go 1.12, we changed the runtime to use MADV_FREE when available on
Linux (falling back to MADV_DONTNEED) in CL 135395 to address issue
#23687. While MADV_FREE is somewhat faster than MADV_DONTNEED, it
doesn't affect many of the statistics that MADV_DONTNEED does until
the memory is actually reclaimed under OS memory pressure. This
generally leads to poor user experience, like confusing stats in top
and other monitoring tools; and bad integration with management
systems that respond to memory usage.
We've seen numerous issues about this user experience, including
#41818, #39295, #37585, #33376, and #30904, many questions on Go
mailing lists, and requests for mechanisms to change this behavior at
run-time, such as #40870. There are also issues that may be a result
of this, but root-causing it can be difficult, such as #41444 and
#39174. And there's some evidence it may even be incompatible with
Android's process management in #37569.
This CL changes the default to prefer MADV_DONTNEED over MADV_FREE, to
favor user-friendliness and minimal surprise over performance. I think
it's become clear that Linux's implementation of MADV_FREE ultimately
doesn't meet our needs. We've also made many improvements to the
scavenger since Go 1.12. In particular, it is now far more prompt and
it is self-paced, so it will simply trickle memory back to the system
a little more slowly with this change. This can still be overridden by
setting GODEBUG=madvdontneed=0.
Fixes#42330 (meta-issue).
Fixes#41818, #39295, #37585, #33376, #30904 (many of which were
already closed as "working as intended").
Change-Id: Ib6aa7f2dc8419b32516cc5a5fc402faf576c92e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/267100
Trust: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Steps run:
$ cd $(go env GOROOT)/src
$ go get -d golang.org/x/sys
$ go mod tidy
$ go mod vendor
$ go generate syscall/... internal/syscall/...
$ cd cmd
$ go get -d golang.org/x/sys
$ go mod tidy
$ go mod vendor
$ cd ..
$ git add .
This change subsumes CL 260860.
For #36905
Change-Id: I7c677c6aa1ad61b9cbd8cf9ed208ed5a30f29c87
Reviewed-on: https://go-review.googlesource.com/c/go/+/267103
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>
Adjust mksyscall_windows.go to activate module mode and set
-mod=readonly, and to suppress its own deprecation warning when run
from within GOROOT/src.
We can't vendor the mkwinsyscall tool in to the std module directly,
because std-vendored dependencies (unlike the dependencies of all
other modules) turn into actual, distinct packages in 'std' when
viewed from outside the 'std' module. We don't want to introduce a
binary in the 'std' meta-pattern, but we also don't particularly want
to add more special-cases to the 'go' command right now when we have
an existing wrapper program that can do the job.
I also regenerated the affected packages to ensure that they are
consistent with the current version of mksyscall, which produced some
declaration-order changes in
internal/syscall/windows/zsyscall_windows.go.
Fixes#41916
Updates #25922
Change-Id: If6e6f8ba3dd372a7ecd6820ee6c0ca38d55f0f35
Reviewed-on: https://go-review.googlesource.com/c/go/+/261499
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
We already remove racefuncenter and racefuncexit if they are not
needed (i.e. the function doesn't have any other race calls).
racefuncenterfp is like racefuncenter but used on LR machines.
Remove unnecessary racefuncenterfp as well.
Change-Id: I65edb00e19c6d9ab55a204cbbb93e9fb710559f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/267099
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Optimize small (s <= 32) zeroing/moving operations on riscv64.
Avoid generating unaligned memory accesses.
The code is almost one to one translation of the corresponding
mips64 rules with additional rule for s=32.
Change-Id: I753b0b8e53cb9efcf43c8080cab90f3d03539fb8
Reviewed-on: https://go-review.googlesource.com/c/go/+/266217
Reviewed-by: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Add "go/analysis/passes/testinggoroutine" from x/tools and vendor its source in.
This pass will catch misuses of:
* testing.T.Fail*
* testing.T.Fatal*
* testing.T.Skip*
inside goroutines explicitly started by the go keyword.
The pass was implemented in CL 212920.
While here, found 2 misuses in:
* database/sql/sql_test.go
* runtime/syscall_windows_test.go
and fixed them in CL 235527.
Fixes#5746
Change-Id: I1740ad3f1d677bb5d78dc5d8d66bac6ec287a2b1
Reviewed-on: https://go-review.googlesource.com/c/go/+/235677
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
In golang.org/cl/266199, I reused the existing code in inlining that
recognizes anonymous variables. However, it turns out that code
mistakenly recognizes anonymous return parameters as named when
inlining a function from the same package.
The issue is funcargs (which is only used for functions parsed from
source) synthesizes ~r names for anonymous return parameters, but
funcargs2 (which is only used for functions imported from export data)
does not.
This CL fixes the behavior so that anonymous return parameters are
handled identically whether a function is inlined within the same
package or across packages. It also adds a proper cross-package test
case demonstrating #33160 is fixed in both cases.
Change-Id: Iaa39a23f5666979a1f5ca6d09fc8c398e55b784c
Reviewed-on: https://go-review.googlesource.com/c/go/+/266719
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Trust: Matthew Dempsky <mdempsky@google.com>
(*Process).Signal returns an error sentinel, previously errFinished,
when (*Process).done or syscall.ESRCH. Callers would like the ability to
test for this state, so the value has been exported as ErrProcessDone.
Fixes#39444
Change-Id: I510e7647cc032af290180de5149f35ab7b09a526
Reviewed-on: https://go-review.googlesource.com/c/go/+/242998
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Sign extension for consts is unnecessary and zero extension for consts can be avoided
via casts. This removes over 16,000 instructions from the Go binary, in part because it
allows for better zero const absorbtion in blocks - for example,
`(BEQ (MOVBU (MOVBconst [0])) cond yes no)` now becomes `(BEQZ cond yes no)` when
this change is combined with existing rules.
Change-Id: I27e791bfa84869639db653af6119f6e10369ba3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/265041
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This requires rewriting the paths of the files passed to the cgo tool
toolchain to use the overlaid paths instead of the disk paths of
files. Because the directories of the overlaid paths don't exist in
general, the cgo tool have been updated to run in base.Cwd instead of
the package directory.
For #39958
Change-Id: I8986de889f56ecc2e64fa69f5f6f29fa907408f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/262618
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
cmd/cgo now has a -trimpath flag that behaves the same as the
-trimpath flag to cmd/compile. This will be used to correct paths
to cgo files that are overlaid.
The code that processes trimpath in internal/objapi has been slightly
refactored because it's currently only accessible via AbsFile, which
does some additional processing to the path names. Now an
ApplyRewrites function is exported that just applies the trimpath
rewrites.
Also remove unused srcfile argument to cmd/cgo.(*Package).godefs.
For #39958
Change-Id: I497d48d0bc2fe1f6ab2b5835cbe79f15b839ee59
Reviewed-on: https://go-review.googlesource.com/c/go/+/266358
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Changed fmt.go to print out some extra information for various kinds of
Nodes. This includes some extra (small) info in the %j (jconv) output,
and some missing sections (such as Dcls and the body of a closure) in
nodedump().
Also, added some extra doc comments for a few Node types in syntax.go
Change-Id: I2ec7184e2abe0d5fbe3fb5a2506da7c7b06f2fb1
Reviewed-on: https://go-review.googlesource.com/c/go/+/266437
Run-TryBot: Dan Scales <danscales@google.com>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently worldsema is not released with direct handoff, so the
semaphore is an unfair synchronization mechanism. If, for example,
ReadMemStats is called in a loop, it can continuously stomp on attempts
by the GC to stop the world.
Note that it's specifically possible for ReadMemStats to delay a STW to
end GC since ReadMemStats is able to STW during a GC since #19112 was
fixed.
While this particular case is unlikely and the right answer in most
applications is to simply not call such an expensive operation in a
loop, this pattern is used often in tests.
Fixes#40459.
Change-Id: Ia4a54f0fd956ea145a319f9f06c4cd37dd52fd8a
Reviewed-on: https://go-review.googlesource.com/c/go/+/243977
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: David Chase <drchase@google.com>
We use systemstack on the locking path to avoid stack splits which could
cause locks to be recorded out of order (see comment on lockWithRank).
This concern is irrelevant on lock assertions, where we simply need to
see if a lock is held and don't care if another is taken in the
meantime. Thus we can simply drop these unless we actually need to
crash.
Updates #40677
Change-Id: I85d730913a59867753ee1ed0386f8c5efda5c432
Reviewed-on: https://go-review.googlesource.com/c/go/+/266718
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Michael Pratt <mpratt@google.com>
Some functions that required holding the heap lock _or_ world stop have
been simplified to simply requiring the heap lock. This is conceptually
simpler and taking the heap lock during world stop is guaranteed to not
contend. This was only done on functions already called on the
systemstack to avoid too many extra systemstack calls in GC.
Updates #40677
Change-Id: I15aa1dadcdd1a81aac3d2a9ecad6e7d0377befdc
Reviewed-on: https://go-review.googlesource.com/c/go/+/250262
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Michael Pratt <mpratt@google.com>
Stopping the world is an implicit lock for many operations, so we should
assert the world is stopped in functions that require it.
This is enabled along with the rest of lock ranking, though it is a bit
orthogonal and likely cheap enough to enable all the time should we
choose.
Requiring a lock _or_ world stop is common, so that can be expressed as
well.
Updates #40677
Change-Id: If0a58544f4251d367f73c4120c9d39974c6cd091
Reviewed-on: https://go-review.googlesource.com/c/go/+/248577
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Michael Pratt <mpratt@google.com>
https://reviews.llvm.org/D90435 is the counterpart in LLVM TSAN.
race_linux_arm64.syso is built with LLVM commit
00da38ce2d36c07f12c287dc515d37bb7bc410e9 on a macOS/ARM64 machine.
(It is not built on a builder with golang.org/x/build/cmd/racebuild
as we don't have darwin/arm64 builder for now.)
Updates #38485.
Change-Id: I391efdacd9480197e308370bfccd05777deb4aee
Reviewed-on: https://go-review.googlesource.com/c/go/+/266373
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
I find it pretty difficult to reason about test-dependency modules
when they aren't in the same file as the rest of the test.
Now that 'go get' supports replacements (CL 258220 and CL 266018),
we can localize tests that need 'go get' but don't specifically depend
on module proxy semantics.
For #36460
For #37438
Change-Id: Ib37a6c170f251435399dfc23e60d96681a81eadc
Reviewed-on: https://go-review.googlesource.com/c/go/+/266369
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
This patch changes the way the linker emits the DWARF line table
prologue, specifically the file table. Previously files were left
unmodified, and the directory table was empty. For each compilation
unit we now scan the unit file table and build up a common set of
directories, emit them into the directory table, and then emit file
entries that refer to the dirs. This provides a modest binary size
savings.
For kubernetes kubelet:
$ objdump -h /tmp/kubelet.old | fgrep debug_line
36 .zdebug_line 019a55f5 0000000000000000 0000000000000000 084a5123 2**0
$ objdump -h /tmp/kubelet.new | fgrep debug_line
36 .zdebug_line 01146fd2 0000000000000000 0000000000000000 084a510a 2**0
[where the value following the section name above is the section size
in hex, so roughly a 30% decrease in this case.]
The actual savings will depend on the length of the pathnames
involved, so it's hard to really pin down how much savings we'll see
here. In addition, emitting the files this way reduces the
"compressibility" of the line table, so there could even be cases
where we don't win at all.
Updates #6853, #19784, #36495.
Change-Id: I298d8561da5ed3ebc9d38aa772874851baa2f4f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/263017
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Trust: Than McIntosh <thanm@google.com>
[This is a roll-forward of CL 262319, with a fix for some Darwin test
failures].
Change the definitions of selected runtime assembly routines
from ABI0 (the default) to ABIInternal. The ABIInternal def is
intended to indicate that these functions don't follow the existing Go
runtime ABI. In addition, convert the assembly reference to
runtime.main (from runtime.mainPC) to ABIInternal. Finally, for
functions such as "runtime.duffzero" that are called directly from
generated code, make sure that the compiler looks up the correct
ABI version.
This is intended to support the register abi work, however these
changes should not have any issues even when GOEXPERIMENT=regabi is
not in effect.
Updates #27539, #40724.
Change-Id: Idf507f1c06176073563845239e1a54dad51a9ea9
Reviewed-on: https://go-review.googlesource.com/c/go/+/266638
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
In CL 264179, some reorganization of error codes was deferred in order
to minimize diffs between patch-sets.
This CL reorganizes the error codes as discussed. It is a pure
reordering, with no material changes other than the changing of internal
const values.
For #42290
Change-Id: I0e9b421a92e96b19e53039652f8de898c5255290
Reviewed-on: https://go-review.googlesource.com/c/go/+/266637
Run-TryBot: Robert Findley <rfindley@google.com>
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
In the current (pre-CL) version of the spec, the 2nd last shift
example appears to be using the array declared in the last example.
On a 32-bit platform, that array would have length 0, which would
lead to a panic in the 2nd last example. Also, if this code were
inside a function, it wouldn't compile (array declared after use).
Use an explicitly declared array for that specific shift example.
Also, split out all cases that produce different results for 32-
vs 64-bit ints.
Fixes#41835.
Change-Id: Ie45114224509e4999197226f91f7f6f934449abb
Reviewed-on: https://go-review.googlesource.com/c/go/+/260398
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
gcBgMarkWorker G's are primarily scheduled by findRunnableGCWorker, but
that no longer needs to be strictly enforced. Temporary preemption to a
runq is fine when the P is not in use.
We still releasem in gopark in the normal case for efficiency: if
gcDrain stops because gp.preempt is set, then gopark would always
preempt. That is fine, but inefficient, since it will reschedule simply
to park again. Thus, we keep releasem in unlockf to skip this extra
cycle.
Change-Id: I6d1a42e3ca41b76227142a6b5bfb376c9213e3c9
Reviewed-on: https://go-review.googlesource.com/c/go/+/262349
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Michael Pratt <mpratt@google.com>
Background mark workers perform per-P marking work. Currently each
worker is assigned a P at creation time. The worker "attaches" to the P
via p.gcBgMarkWorker, making itself (usually) available to
findRunnableGCWorker for scheduling GC work.
While running gcMarkDone, the worker "detaches" from the P (by clearing
p.gcBgMarkWorker), since it may park for other reasons and should not be
scheduled by findRunnableGCWorker.
Unfortunately, this design is complex and difficult to reason about. We
simplify things by changing the design to eliminate the hard P
attachment. Rather than workers always performing work from the same P,
workers perform work for whichever P they find themselves on. On park,
the workers are placed in a pool of free workers, which each P's
findRunnableGCWorker can use to run a worker for its P.
Now if a worker parks in gcMarkDone, a P may simply use another worker
from the pool to complete its own work.
The P's GC worker mode is used to communicate the mode to run to the
selected worker. It is also used to emit the appropriate worker
EvGoStart tracepoint. This is a slight change, as this G may be
preempted (e.g., in gcMarkDone). When it is rescheduled, the trace
viewer will show it as a normal goroutine again. It is currently a bit
difficult to connect to the original worker tracepoint, as the viewer
does not display the goid for the original worker (though the data is in
the trace file).
Change-Id: Id7bd3a364dc18a4d2b1c99c4dc4810fae1293c1b
Reviewed-on: https://go-review.googlesource.com/c/go/+/262348
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Michael Pratt <mpratt@google.com>
Tools using go/types sometimes need to implement special handling for
certain errors produced by the type-checker. They can offer suggested
fixes, expand the error position to surrounding syntax, highlight
related syntax (for example in the case of a declaration cycle), link to
additional documentation, group errors by category, or correlate errors
with signals produced by other static analysis tools.
All these require a notion of error identity. Tools need to be able to
reliably determine the nature of an error without re-implementing type
checking logic or parsing error messages. This CL is a first-pass at
adding such an identifier to types.Error: a (for the moment unexported)
field containing one of many declared errorCode constants.
A wide variety of error code constants are defined, and assigned to type
checker errors according to their 'functional equivalence', meaning that
they should be ideally be stable under refactoring.
With few exceptions, each error code is documented with an example that
produces it. This is enforced by tests.
When error codes are exported they will represent quite a large API
surface. For this reason, as well as the likelihood that error codes
will change at the start, both the code field and the codes themselves
are initially unexported. gopls will read these fields using reflection
during this experimental phase. Others can obviously do the same,
provided they accept the lack of forward compatibility.
For #42290
Change-Id: I15e3c2bffd2046c20297b1857057d421f633098a
Reviewed-on: https://go-review.googlesource.com/c/go/+/264179
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
Currently, on all supported platforms, the race detector (LLVM
TSAN) expects the Go heap is at 0xc000000000 - 0xe000000000.
Move the raceenabled condition first, so we always allocate
there.
This means on Linux/ARM64 when race detector is on we will
allocate to 0xc000000000 - 0xe000000000, instead of 0x4000000000.
The old address is meant for 39-bit VMA. But the race detector
only supports 48-bit VMA anyway. So this is fine.
Change-Id: I51ac8eff68297b37c8c651a93145cc94f83a939d
Reviewed-on: https://go-review.googlesource.com/c/go/+/266372
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
A method selector expression can pick out a method or promoted method
(represented by ODOTMETH), but it can also pick out an interface
method from an embedded interface-typed field (represented by
ODOTINTER).
In the case that we're picking out an interface method, we're not able
to fully devirtualize the method call. However, we're still able to
improve escape analysis somewhat. E.g., the included test case
demonstrates that we can optimize "i.M()" to "i.(T).I.M()", which
means the T literal can be stack allocated instead of heap allocated.
Fixes#42279.
Change-Id: Ifa21d19011e2f008d84f9624b7055b4676b6d188
Reviewed-on: https://go-review.googlesource.com/c/go/+/266300
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
In ParseComplex, the "size" passed to parseFloatPrefix should be 64 for
complex128, not 128. It still works because of how parseFloatPrefix
is forgiving about the size if it's not 32, but worth fixing anyway.
Make ParseComplex and ParseFloat return a bit size error for anything
other than 128 or 64 (for ParseComplex), or 64 or 32 (for ParseFloat).
Add "InvalidBitSize" tests for these cases.
Add tests for ParseComplex with bitSize==64: this is done in a similar
way to how the ParseFloat 32-bit tests work, re-using the tests for the
larger bit size.
Add tests for FormatComplex -- there were none before.
Fixes#40706
Change-Id: I16ddd546e5237207cc3b8c2181dd708eca42b04f
Reviewed-on: https://go-review.googlesource.com/c/go/+/248219
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Minux Ma <minux@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
There is no documentation on a number of methods of the strings.Reader
struct, so this change adds documentation referring to the relevant
io.* interfaces implemented. This is consistent with pre-existing
documentation in this struct.
Fixes#40381
Change-Id: I3dec65ecafca5b79d85d30a676d297e5ee9ab47e
GitHub-Last-Rev: f42429946a
GitHub-Pull-Request: golang/go#40654
Reviewed-on: https://go-review.googlesource.com/c/go/+/247523
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
Append operations in the decimal String function may cause several allocations.
Use make to pre allocate slices in String that have enough capacity to avoid additional allocations in append operations.
name old time/op new time/op delta
DecimalConversion-8 139µs ± 7% 109µs ± 2% -21.06% (p=0.000 n=10+10)
Change-Id: Id0284d204918a179a0421c51c35d86a3408e1bd9
Reviewed-on: https://go-review.googlesource.com/c/go/+/233980
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
Run-TryBot: Giovanni Bajo <rasky@develer.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Giovanni Bajo <rasky@develer.com>
Reviewed-by: Martin Möhrmann <moehrmann@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Giovanni Bajo <rasky@develer.com>
Trust: Martin Möhrmann <moehrmann@google.com>
In many cases, it is not necessary to parse long
decimal mantissas entirely to produce the correctly
rounded floating-point number. It is enough to parse
the short, rounded lower and upper bounds and in most cases
they round to the same floating point number because uint64
can hold 19 digits.
Previously this case was handled by the extFloat code path
(Grisu3 algorithm).
name old time/op new time/op delta
Atof64Big-4 1.07µs ± 2% 0.11µs ± 2% -89.61% (p=0.000 n=10+9)
Atof64RandomLongFloats-4 8.03µs ± 2% 0.14µs ± 7% -98.24% (p=0.000 n=10+10)
Atof32RandomLong-4 760ns ± 1% 156ns ± 0% -79.46% (p=0.000 n=10+8)
Benchmarks versus extFloat:
name old time/op new time/op delta
Atof64Big-4 121ns ± 3% 111ns ± 2% -7.93% (p=0.000 n=10+9)
Atof64RandomLongFloats-4 144ns ± 1% 142ns ± 7% ~ (p=0.167 n=10+10)
Atof32RandomLong-4 129ns ± 1% 156ns ± 0% +21.12% (p=0.000 n=10+8)
Change-Id: Id734b8c11e74b49a444fda67ee72870ae9422e60
Reviewed-on: https://go-review.googlesource.com/c/go/+/264677
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Nigel Tao <nigeltao@golang.org>
We don't put Go static symbols in the symbol table, as they are
always compiler-generated (there is no way to define a static
symbol in user code in Go). We retain static symbols in assembly
code, as it may be user-defined. Also retain static symbols in C.
This is the second attempt of CL 263259, which was reverted
because it broke AIX tests in that it brought TOC.stmp symbols
in the symbol table. This time we use SymPkg(s) == "" to identify
non-Go symbols, instead of IsExternal(s), as the latter also
includes linker-modified Go symbols.
Change-Id: I5c752c54f0fc6ac4cde6a0e8161dac5b72a47d56
Reviewed-on: https://go-review.googlesource.com/c/go/+/266237
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
These messages can happen if there are
duplicate body-less function declarations.
Using panic gives the panic handler
a chance to handle the panic by printing the
queued error messages instead of an internal error.
And if there are no queued error messages,
using panic pinpoints the stack trace leading
to the incorrect use of NewFuncInfo/NewFileInfo.
Change-Id: I7e7ea9822ff9a1e7140f5e5b7cfd6437ff9318a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/266338
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
We should still be able to devirtualize here, but I need to understand
the AST better. While I'm doing that, at least switch to a graceful
failure case (i.e., skip the optimization and print a warning message)
to fix the x/text builders.
Updates #42279.
Change-Id: Ie2b0b701fccf590d0cabfead703fc2fa999072cf
Reviewed-on: https://go-review.googlesource.com/c/go/+/266359
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
After inlining, add a pass that looks for interface calls where we can
statically determine the interface value's concrete type. If such a
case is found, insert an explicit type assertion to the concrete type
so that escape analysis can see it.
Fixes#33160.
Change-Id: I36932c691693f0069e34384086d63133e249b06b
Reviewed-on: https://go-review.googlesource.com/c/go/+/264837
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
When inlining a function call "f()", if "f" contains exactly 1
"return" statement and doesn't name its result parameters, it's
inlined to declare+initialize the result value using the AST
representation that's compatible with staticValue.
Also, extend staticValue to skip over OCONVNOP nodes (often introduced
by inlining), and fix various bits of code related to handling method
expressions.
Updates #33160.
Change-Id: If8652e319f0a5700cf9d40a7a62e369a2a359229
Reviewed-on: https://go-review.googlesource.com/c/go/+/266199
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
This reverts CL 263457.
It turns out that this still missed changes to cmd/link/internal/ld/config.go
and some of these build modes also fail once cgo is enabled. Disable again for
now.
Change-Id: Iaf40d44e1551afd5b040d357f04af134f55a64a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/266317
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Joel Sing <joel@sing.id.au>
This change fixes two failng tests on linux-ppc64x:
- TestAllThreadsSyscall() exposed a real bug in the ppc64x support:
- It turns out that the r2 syscall return value is not defined
on all architectures. Notably linux-ppc64x so address that by
introducing a private architectural constant in the syscall
package, archHonorsR2: true if r2 has a determanistic value.
- TestSetuidEtc() was sensitive to /proc/<PID>/status content:
- The amount of padding space has changed with kernel vintage.
- Stress testing revealed a race with /proc files disappearing.
Fixes#42178
Change-Id: Ie6fc0b8f2f94a409ac0e5756e73bfce113274709
Reviewed-on: https://go-review.googlesource.com/c/go/+/266202
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
The inlining pass previously bailed upon encountering a go or defer statement, so it would not inline functions e.g. used to provide arguments to the deferred function. This change preserves the behavior of not inlining the
deferred function itself, but it allows the inlining walk to proceed into its arguments.
Fixes#42194
Change-Id: I4e82029d8dcbe69019cc83ae63a4b29af45ec777
Reviewed-on: https://go-review.googlesource.com/c/go/+/264997
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The final piece of //go:embed support: have the go command stitch
together parsing in go/build, low-level data initialization in cmd/compile,
and the new data structures in package embed, to make the //go:embed
feature actually function.
And test, now that all the pieces are available to work together.
For #41191.
(Issue not fixed: still need to add a tool for use by Bazel.)
Change-Id: Ib1d198345c3b4d557d340f292eda13b984b65d65
Reviewed-on: https://go-review.googlesource.com/c/go/+/243945
Trust: Russ Cox <rsc@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Trust: Johan Brandhorst <johan.brandhorst@gmail.com>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Johan Brandhorst <johan.brandhorst@gmail.com>
This reverts CL 250497. It also moves all blank identifier imports below the rest of the imports for clarity.
Reason for revert: The blank identifier import was intentional to show that it's needed for its registration side effect. The duplicate import should stay since it communicates that the side-effect is important to tools and to future developers updating this file.
Change-Id: I626e6329db50f47453aa71085a05d21bf6efe0ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/265078
Run-TryBot: Katie Hockman <katie@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Change the definitions of selected runtime assembly routines
from ABI0 (the default) to ABIInternal. The ABIInternal def is
intended to indicate that these functions don't follow the existing Go
runtime ABI. In addition, convert the assembly reference to
runtime.main (from runtime.mainPC) to ABIInternal. Finally, for
functions such as "runtime.duffzero" that are called directly from
generated code, make sure that the compiler looks up the correct
ABI version.
This is intended to support the register abi work, however these
changes should not have any issues even when GOEXPERIMENT=regabi is
not in effect.
Updates #27539, #40724.
Change-Id: I9846f8dcaccc95718cf2e61a18b7e924a0677e4c
Reviewed-on: https://go-review.googlesource.com/c/go/+/262319
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This patch adds support for CASx and CASPx atomic instructions.
go syntax gnu syntax
CASD Rs, (Rn|RSP), Rt => cas Xs, Xt, (Xn|SP)
CASALW Rs, (Rn|RSP), Rt => casal Ws, Wt, (Xn|SP)
CASPD (Rs, Rs+1), (Rn|RSP), (Rt, Rt+1) => casp Xs, Xs+1, Xt, Xt+1, (Xn|SP)
CASPW (Rs, Rs+1), (Rn|RSP), (Rt, Rt+1) => casp Ws, Ws+1, Wt, Wt+1, (Xn|SP)
This patch changes the type of prog.RestArgs from "[]Addr" to
"[]struct{Addr, Pos}", Pos is a enum, indicating the position of
the operand.
This patch also adds test cases.
Change-Id: Ib971cfda7890b7aa895d17bab22dea326c7fcaa4
Reviewed-on: https://go-review.googlesource.com/c/go/+/233277
Trust: fannie zhang <Fannie.Zhang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This patch enables VSLI, VUADDW(2), VUSRA and FMOVQ SIMD instructions
required by the issue #40725. And the GNU syntax of 'FMOVQ' is 128-bit
ldr/str(immediate, simd&fp).
Add test cases.
Fixes#40725
Change-Id: Ide968ef4a9385ce4cd8f69bce854289014d30456
Reviewed-on: https://go-review.googlesource.com/c/go/+/258397
Trust: fannie zhang <Fannie.Zhang@arm.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
As it says, delay expanpsion of OpArg to the expand_calls phase,
to enable (eventually) interprocedural SSA optimizations, and
(sooner) change to a register ABI.
Includes a round of cleanup to function names and comments,
largely to match the expanded scope of the functions.
This CL removes the per-function dependence on GOSSAHASH,
but the go116lateCallExpansion kill switch remains (and was
tested locally to ensure it worked).
Two functions in expand_calls.go that performed overlapping
things were combined into a single function that is called
twice.
Fixes#42236.
For #40724.
Change-Id: Icbb78947eaa39f17f2c1210d5c2caef20abd6571
Reviewed-on: https://go-review.googlesource.com/c/go/+/262117
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Some of the current functions for encoding load/store with
immediate offset instructions, like opstr12(), opstr9(),
opldr12(), opldr9() and opldrpp(), etc., they have the same
code, so this patch refactors them and merges them into two
functions opstr() and opldr().
Change-Id: I60367f8b720b77c7ebe6d66905a950dcf7701836
Reviewed-on: https://go-review.googlesource.com/c/go/+/263479
Run-TryBot: fannie zhang <Fannie.Zhang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: fannie zhang <Fannie.Zhang@arm.com>
This is done by decomposing the number to be divided in 32-bit
components and using the 32-bit magic multiply. For the lowering to be
effective the constant must fit in 16 bits.
On ARM the expression n / 5 compiles to 25 instructions.
Benchmark for GOARCH=arm (Cortex-A53)
name old time/op new time/op delta
DivconstU64/3-6 1.19µs ± 0% 0.03µs ± 1% -97.40% (p=0.000 n=9+9)
DivconstU64/5-6 1.18µs ± 1% 0.03µs ± 1% -97.38% (p=0.000 n=10+8)
DivconstU64/37-6 1.13µs ± 1% 0.04µs ± 1% -96.51% (p=0.000 n=10+8)
DivconstU64/1234567-6 852ns ± 0% 901ns ± 1% +5.73% (p=0.000 n=8+9)
Benchmark for GOARCH=386 (Haswell)
name old time/op new time/op delta
DivconstU64/3-4 18.0ns ± 2% 5.6ns ± 1% -69.06% (p=0.000 n=10+10)
DivconstU64/5-4 17.8ns ± 1% 5.5ns ± 1% -68.87% (p=0.000 n=9+10)
DivconstU64/37-4 17.8ns ± 1% 7.3ns ± 0% -58.90% (p=0.000 n=10+10)
DivconstU64/1234567-4 17.5ns ± 1% 16.0ns ± 0% -8.55% (p=0.000 n=10+9)
Change-Id: I38a19b4d59093ec021ef2e5241364a3dad4eae73
Reviewed-on: https://go-review.googlesource.com/c/go/+/264683
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
rewrite.go has two identical functions log2 and log64; the former has
been there for a while, while the latter was added together with
log{8,16,32} for use in typed rules.
This change deletes log2 and switches to using log64 everywhere.
Change-Id: I759b878814e4c115a5fa470274f22477738d69ef
Reviewed-on: https://go-review.googlesource.com/c/go/+/265457
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Following golang.org/cl/259578, findrunnable still must touch every
other P in checkTimers in order to look for timers to steal. This scales
poorly with GOMAXPROCS and potentially performs poorly by pulling remote
Ps into cache.
Add timerpMask, a bitmask that tracks whether each P may have any timers
on its timer heap.
Ideally we would update this field on any timer add / remove to always
keep it up to date. Unfortunately, updating a shared global structure is
antithetical to sharding timers by P, and doing so approximately doubles
the cost of addtimer / deltimer in microbenchmarks.
Instead we only (potentially) clear the mask when the P goes idle. This
covers the best case of avoiding looking at a P _at all_ when it is idle
and has no timers. See the comment on updateTimerPMask for more details
on the trade-off. Future CLs may be able to expand cases we can avoid
looking at the timers.
Note that the addition of idlepMask to p.init is a no-op. The zero value
of the mask is the correct init value so it is not necessary, but it is
included for clarity.
Benchmark results from WakeupParallel/syscall/pair/race/1ms (see
golang.org/cl/228577). Note that these are on top of golang.org/cl/259578:
name old msec new msec delta
Perf-task-clock-8 244 ± 4% 246 ± 4% ~ (p=0.841 n=5+5)
Perf-task-clock-16 247 ±11% 252 ± 4% ~ (p=1.000 n=5+5)
Perf-task-clock-32 270 ± 1% 268 ± 2% ~ (p=0.548 n=5+5)
Perf-task-clock-64 302 ± 3% 296 ± 1% ~ (p=0.222 n=5+5)
Perf-task-clock-128 358 ± 3% 352 ± 2% ~ (p=0.310 n=5+5)
Perf-task-clock-256 483 ± 3% 458 ± 1% -5.16% (p=0.008 n=5+5)
Perf-task-clock-512 663 ± 1% 612 ± 4% -7.61% (p=0.008 n=5+5)
Perf-task-clock-1024 1.06k ± 1% 0.95k ± 2% -10.24% (p=0.008 n=5+5)
Updates #28808
Updates #18237
Change-Id: I4239cd89f21ad16dfbbef58d81981da48acd0605
Reviewed-on: https://go-review.googlesource.com/c/go/+/264477
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Michael Pratt <mpratt@google.com>
procfs(5) is not always mounted in DragonFly BSD, for example during
the binary package build with synth. os.Executable() consumers
will then fail, we've spotted this when trying to build tinygo:
[...]
copying source files
./build/tinygo build-builtins -target=armv6m-none-eabi [...]
panic: could not get executable path: readlink /proc/curproc/file:
no such file or directory
[...]
Use KERN_PROC_PATHNAME as FreeBSD does.
Change-Id: Ic65bea02cd0309fb24dec8ba8d2b151d1acde67b
GitHub-Last-Rev: 083120a43b
GitHub-Pull-Request: golang/go#36826
Reviewed-on: https://go-review.googlesource.com/c/go/+/216622
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Tx acquires tx.closemu W-lock and then acquires stmt.closemu.W-lock
to fully close the transaction and associated prepared statement.
Stmt query and execution run in reverse ways - acquires
stmt.closemu.R-lock and then acquires tx.closemu.R-lock to grab tx
connection, which may cause deadlock.
Prevent the lock is held around tx.closePrepared to ensure no
deadlock happens.
Fixes#40985
Change-Id: If53909822b87bce11861a6e3035ecb9476d2cd17
Reviewed-on: https://go-review.googlesource.com/c/go/+/250178
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Daniel Theophanes <kardianos@gmail.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
Follow-up for CL 265819.
Given the -pre tag added recently, a new stable version is likely
tagged soon. This would break TestCodeRepoVersions on the longtest
builders again. Since the other test cases in codeRepoVersionsTests
already provide enough coverage, drop gopkg.in/russross/blackfriday.v2
to avoid breaking TestCodeRepoVersions once the release happens.
Updates #28856
Change-Id: If86a637b5e47f59faf9048fc1cbbae6e8f1dcc53
Reviewed-on: https://go-review.googlesource.com/c/go/+/265917
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Sysmon can actually get the RW lock execLock while holding the sysmon
lock (if no M is available), so there is an edge from lockRankSysmon to
lockRankRwmutexR. The stack trace is sysmon() [gets sched.sysmonlock] ->
startm() -> newm() -> newm1() -> execLock.runlock() [gets
execLock.rLock]
Change-Id: I9658659ba3899afb5219114d66b989abd50540db
Reviewed-on: https://go-review.googlesource.com/c/go/+/265721
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
With previous CLs, internal linking without cgo should work well.
Enable it by default. And stop always requiring cgo.
Enable tests that were previously disabled due to the lack of
internal linking.
Updates #38485.
Change-Id: I45125b9c263fd21d6847aa6b14ecaea3a2989b29
Reviewed-on: https://go-review.googlesource.com/c/go/+/265121
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Currently, on darwin/arm64 we set up TLS using cgo. TLS is not
set for pure Go programs. As we use libc for syscalls on darwin,
we need to save the G register before the libc call. Otherwise it
is not signal-safe, as a signal may land during the execution of
a libc function, where the G register may be clobbered.
This CL initializes TLS in Go, by calling the pthread functions
directly without cgo. This makes it possible to save the G
register to TLS in pure Go programs (done in a later CL).
Inspired by Elias's CL 209197. Write the logic in Go instead of
assembly.
Updates #38485, #35853.
Change-Id: I257ba2a411ad387b2f4d50d10129d37fec7a226e
Reviewed-on: https://go-review.googlesource.com/c/go/+/265118
Trust: Cherry Zhang <cherryyz@google.com>
Trust: Elias Naur <mail@eliasnaur.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This file has a few changes compared to the go/types version:
1) syntax.Pos is used instead of token.Pos.
2) The cmpPos helper function (defined elsewhere) is used to
compare positions (syntax.Pos positions cannot be compared
directly with <=).
3) A new method Scope.Squash was added (primary difference).
f=scope.go; diff $f ../../../../go/types/$f
7c7
< package types2
---
> package types
11d10
< "cmd/compile/internal/syntax"
12a12
> "go/token"
26c26
< pos, end syntax.Pos // scope extent; may be invalid
---
> pos, end token.Pos // scope extent; may be invalid
33c33
< func NewScope(parent *Scope, pos, end syntax.Pos, comment string) *Scope {
---
> func NewScope(parent *Scope, pos, end token.Pos, comment string) *Scope {
82c82
< func (s *Scope) LookupParent(name string, pos syntax.Pos) (*Scope, Object) {
---
> func (s *Scope) LookupParent(name string, pos token.Pos) (*Scope, Object) {
84c84
< if obj := s.elems[name]; obj != nil && (!pos.IsKnown() || cmpPos(obj.scopePos(), pos) <= 0) {
---
> if obj := s.elems[name]; obj != nil && (!pos.IsValid() || obj.scopePos() <= pos) {
111,144d110
< // Squash merges s with its parent scope p by adding all
< // objects of s to p, adding all children of s to the
< // children of p, and removing s from p's children.
< // The function f is called for each object obj in s which
< // has an object alt in p. s should be discarded after
< // having been squashed.
< func (s *Scope) Squash(err func(obj, alt Object)) {
< p := s.parent
< assert(p != nil)
< for _, obj := range s.elems {
< obj.setParent(nil)
< if alt := p.Insert(obj); alt != nil {
< err(obj, alt)
< }
< }
<
< j := -1 // index of s in p.children
< for i, ch := range p.children {
< if ch == s {
< j = i
< break
< }
< }
< assert(j >= 0)
< k := len(p.children) - 1
< p.children[j] = p.children[k]
< p.children = p.children[:k]
<
< p.children = append(p.children, s.children...)
<
< s.children = nil
< s.elems = nil
< }
<
149,150c115,116
< func (s *Scope) Pos() syntax.Pos { return s.pos }
< func (s *Scope) End() syntax.Pos { return s.end }
---
> func (s *Scope) Pos() token.Pos { return s.pos }
> func (s *Scope) End() token.Pos { return s.end }
155,156c121,122
< func (s *Scope) Contains(pos syntax.Pos) bool {
< return cmpPos(s.pos, pos) <= 0 && cmpPos(pos, s.end) < 0
---
> func (s *Scope) Contains(pos token.Pos) bool {
> return s.pos <= pos && pos < s.end
164c130
< func (s *Scope) Innermost(pos syntax.Pos) *Scope {
---
> func (s *Scope) Innermost(pos token.Pos) *Scope {
Change-Id: If6c459f45dae8980ffb3a902a46b1700e9b55dc7
Reviewed-on: https://go-review.googlesource.com/c/go/+/265700
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Except for the package name, this file is unchanged from the go/types version.
f=objset.go; diff $f ../../../../go/types/$f
11c11
< package types2
---
> package types
Change-Id: I5a03b08ec006d87cb31139f708d844fcfddbbb56
Reviewed-on: https://go-review.googlesource.com/c/go/+/265699
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Except for the package name, this file is unchanged from the go/types version.
f=selection.go; diff $f ../../../../go/types/$f
7c7
< package types2
---
> package types
Change-Id: I09c26a744f445ec992c554d293e3ca9896b5c849
Reviewed-on: https://go-review.googlesource.com/c/go/+/265698
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Except for the package name, this file is unchanged from the go/types version.
f=gccgosizes.go; diff $f ../../../../go/types/$f
8c8
< package types2
---
> package types
Change-Id: I23a8432f3e6f21eec8220f89a24df26e91ad41ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/265697
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This change makes a first connection between the compiler and types2.
When the -G flag is provided, the compiler accepts code using type
parameters; with this change generic code is also type-checked (but
then compilation ends).
Change-Id: I0fa6f6213267a458a6b33afe8ff26869fd838a63
Reviewed-on: https://go-review.googlesource.com/c/go/+/264303
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
On top of the merge, the following fixes were applied:
+ Debug["G"] changed to Debug.G, following golang.org/cl/263539.
+ issue42058a.go and issue42058b.go were skipped in
types2/stdlib_test.go. go/types does not produce errors related to
channel element size.
Change-Id: I59fc84e12a2d728ef789fdc616f7afe80e451283
Minimal changes are made to existing types in go/ast to support type
parameters. Namely:
+ FieldList is overloaded to hold type parameter lists. In this case,
the field name becomes the type identifier, and the field type
becomes the constraint.
+ FuncType and TypeSpec gain a TParams FieldList.
+ CallExpr gains a 'Brackets' flag, signaling that it uses '[]' rather
than '()', representing a generic type expression with type
parameters.
Modifications from dev.go2go: the 'UseBrackets' field was removed from
ast.File, as this support is no longer necessary.
Change-Id: I21fd7390f1800dece3c14e6ec015fb2419e9fc52
Reviewed-on: https://go-review.googlesource.com/c/go/+/264181
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
Trust: Robert Findley <rfindley@google.com>
This is a copy of the importer and types2 (unreviewed) prototype version
excluding the testdata directory containing tests (see below). Each file
is marked with the comment
// UNREVIEWED
on the first line. The plan is to check in this code wholesale (it runs and
passes all tests) and then review the code file-by-file via subsequent CLs
and remove the "// UNREVIEWED" comments as we review the files.
Since most tests are unchanged from the original go/types, the next CL will
commit those tests as they don't need to be reviewed again. (Eventually we
may want to factor them out and share them from a single place, e.g. the
test directory.)
The existing file fmtmap_test.go was updated.
Change-Id: I9bd0ad1a7e7188b501423483a44d18e623c0fe71
Reviewed-on: https://go-review.googlesource.com/c/go/+/263624
Trust: Robert Griesemer <gri@golang.org>
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Per @mdempsky's suggestion: Instead of representing a type instantiation T[P]
by an IndexExpr node, and a type instantiation with multiple type arguments
T[P1, P2] by a CallExpr node with special Brackets flag, always use an IndexExpr.
Use a ListExpr as index in the (less common) case of multiple type arguments.
This removes the need for the CallExpr.Brackets field and cleans up the parser
code around type instantiations.
Backport of syntax package changes from https://golang.org/cl/262020.
Change-Id: I32e8bc4eafac5b3ef2e7eb40fa8c790a5a905b69
Reviewed-on: https://go-review.googlesource.com/c/go/+/262137
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Providing the -G flag instructs the compiler to accept type parameters.
For now, the compiler only parses such files and then exits.
Added a new test directory (test/typeparam) and initial test case.
Port from dev.go2go branch.
Change-Id: Ic11e33a9d5f012f8def0bdae205043659562ac73
Reviewed-on: https://go-review.googlesource.com/c/go/+/261660
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Port from dev.go2go prototype branch. The compiler doesn't yet set the
syntax.AllowGenerics mode, so parsing of generic code remains disabled.
Known issue: The doc strings documenting the specific syntax accepted
by parser methods are not all up-to-date.
Change-Id: I13d134289fd9330fd0ed7f97c997cca6f23466fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/261658
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Since slices, arrays and strings are not C pointers, GDB can't interpret the subscripting operation for you, but
you can look inside the runtime representation to do that (tab completion helps here):
</p>
<pre>
(gdb) <b>p slc</b>
$11 = []int = {0, 0}
(gdb) <b>p slc-></b><i><TAB></i>
array slc len
(gdb) <b>p slc->array</b>
$12 = (int *) 0xf84057af00
(gdb) <b>p slc->array[1]</b>
$13 = 0</pre>
<p>
The extension functions $len and $cap work on strings, arrays and slices:
</p>
<pre>
(gdb) <b>p $len(utf)</b>
$23 = 4
(gdb) <b>p $cap(utf)</b>
$24 = 4
</pre>
<p>
Channels and maps are 'reference' types, which gdb shows as pointers to C++-like types <code>hash<int,string>*</code>. Dereferencing will trigger prettyprinting
</p>
<p>
Interfaces are represented in the runtime as a pointer to a type descriptor and a pointer to a value. The Go GDB runtime extension decodes this and automatically triggers pretty printing for the runtime type. The extension function <code>$dtype</code> decodes the dynamic type for you (examples are taken from a breakpoint at <code>regexp.go</code> line 293.)
One minor detail of the default formatting of Go source code has changed.
When formatting expression lists with inline comments, the comments were
aligned according to a heuristic.
However, in some cases the alignment would be split up too easily, or
introduce too much whitespace.
The heuristic has been changed to behave better for human-written code.
</p>
<p>
Note that these kinds of minor updates to gofmt are expected from time to
time.
In general, systems that need consistent formatting of Go source code should
use a specific version of the <code>gofmt</code> binary.
See the <ahref="/pkg/go/format/">go/format</a> package documentation for more
information.
</p>
<h3id="run">Run</h3>
<p>
<!-- CL 109341 -->
The <ahref="/cmd/go/"><code>go</code> <code>run</code></a>
command now allows a single import path, a directory name or a
pattern matching a single package.
This allows <code>go</code> <code>run</code> <code>pkg</code> or <code>go</code> <code>run</code> <code>dir</code>, most importantly <code>go</code> <code>run</code> <code>.</code>
</p>
<h2id="runtime">Runtime</h2>
<p><!-- CL 85887 -->
The runtime now uses a sparse heap layout so there is no longer a
limit to the size of the Go heap (previously, the limit was 512GiB).
This also fixes rare "address space conflict" failures in mixed Go/C
binaries or binaries compiled with <code>-race</code>.
</p>
<p><!-- CL 108679, CL 106156 -->
On macOS and iOS, the runtime now uses <code>libSystem.dylib</code> instead of
calling the kernel directly. This should make Go binaries more
compatible with future versions of macOS and iOS.
The <ahref="/pkg/syscall">syscall</a> package still makes direct
system calls; fixing this is planned for a future release.
</p>
<h2id="performance">Performance</h2>
<p>
As always, the changes are so general and varied that precise
statements about performance are difficult to make. Most programs
should run a bit faster, due to better generated code and
optimizations in the core library.
</p>
<p><!-- CL 74851 -->
There were multiple performance changes to the <code>math/big</code>
package as well as many changes across the tree specific to <code>GOARCH=arm64</code>.
The compiler now performs significantly more aggressive bounds-check
and branch elimination. Notably, it now recognizes transitive
relations, so if <code>i<j</code> and <code>j<len(s)</code>,
it can use these facts to eliminate the bounds check
for <code>s[i]</code>. It also understands simple arithmetic such
as <code>s[i-10]</code> and can recognize more inductive cases in
loops. Furthermore, the compiler now uses bounds information to more
aggressively optimize shift operations.
</p>
<h2id="library">Core library</h2>
<p>
All of the changes to the standard library are minor.
</p>
<h3id="minor_library_changes">Minor changes to the library</h3>
<p>
As always, there are various minor changes and updates to the library,
made with the Go 1 <ahref="/doc/go1compat">promise of compatibility</a>
in mind.
</p>
<!-- CL 115095: https://golang.org/cl/115095: yes (`go test pkg` now always builds pkg even if there are no test files): cmd/go: output coverage report even if there are no test files -->
<!-- CL 110395: https://golang.org/cl/110395: cmd/go, cmd/compile: use Windows response files to avoid arg length limits -->
<!-- CL 112436: https://golang.org/cl/112436: cmd/pprof: add readline support similar to upstream -->
<ahref="/pkg/math/big/#Int.ModInverse"><code>ModInverse</code></a> now returns nil when g and n are not relatively prime. The result was previously undefined.
NOTE: In this document and others in this directory, the convention is to
set fixed-width phrases with non-fixed-width spaces, as in
<code>hello</code> <code>world</code>.
Do not send CLs removing the interior tags from such phrases.
-->
<style>
mainulli{margin:0.5em0;}
</style>
<h2id="introduction">Introduction to Go 1.12</h2>
<p>
The latest Go release, version 1.12, arrives six months after <ahref="go1.11">Go 1.11</a>.
Most of its changes are in the implementation of the toolchain, runtime, and libraries.
As always, the release maintains the Go 1 <ahref="/doc/go1compat">promise of compatibility</a>.
We expect almost all Go programs to continue to compile and run as before.
</p>
<h2id="language">Changes to the language</h2>
<p>
There are no changes to the language specification.
</p>
<h2id="ports">Ports</h2>
<p><!-- CL 138675 -->
The race detector is now supported on <code>linux/arm64</code>.
</p>
<pid="freebsd">
Go 1.12 is the last release that is supported on FreeBSD 10.x, which has
already reached end-of-life. Go 1.13 will require FreeBSD 11.2+ or FreeBSD
12.0+.
FreeBSD 12.0+ requires a kernel with the COMPAT_FREEBSD11 option set (this is the default).
</p>
<p><!-- CL 146898 -->
cgo is now supported on <code>linux/ppc64</code>.
</p>
<pid="hurd"><!-- CL 146023 -->
<code>hurd</code> is now a recognized value for <code>GOOS</code>, reserved
for the GNU/Hurd system for use with <code>gccgo</code>.
</p>
<h3id="windows">Windows</h3>
<p>
Go's new <code>windows/arm</code> port supports running Go on Windows 10
IoT Core on 32-bit ARM chips such as the Raspberry Pi 3.
</p>
<h3id="aix">AIX</h3>
<p>
Go now supports AIX 7.2 and later on POWER8 architectures (<code>aix/ppc64</code>). External linking, cgo, pprof and the race detector aren't yet supported.
</p>
<h3id="darwin">Darwin</h3>
<p>
Go 1.12 is the last release that will run on macOS 10.10 Yosemite.
Go 1.13 will require macOS 10.11 El Capitan or later.
</p>
<p><!-- CL 141639 -->
<code>libSystem</code> is now used when making syscalls on Darwin,
ensuring forward-compatibility with future versions of macOS and iOS.
<!-- CL 153338 -->
The switch to <code>libSystem</code> triggered additional App Store
checks for private API usage. Since it is considered private,
<code>syscall.Getdirentries</code> now always fails with
New extended precision operations <ahref="/pkg/math/bits/#Add"><code>Add</code></a>, <ahref="/pkg/math/bits/#Sub"><code>Sub</code></a>, <ahref="/pkg/math/bits/#Mul"><code>Mul</code></a>, and <ahref="/pkg/math/bits/#Div"><code>Div</code></a> are available in <code>uint</code>, <code>uint32</code>, and <code>uint64</code> versions.
</p>
</dl><!-- math/bits -->
<dlid="net"><dt><ahref="/pkg/net/">net</a></dt>
<dd>
<p><!-- CL 146659 -->
The
<ahref="/pkg/net/#Dialer.DualStack"><code>Dialer.DualStack</code></a> setting is now ignored and deprecated;
RFC 6555 Fast Fallback ("Happy Eyeballs") is now enabled by default. To disable, set
<ahref="/pkg/net/#Dialer.FallbackDelay"><code>Dialer.FallbackDelay</code></a> to a negative value.
</p>
<p><!-- CL 107196 -->
Similarly, TCP keep-alives are now enabled by default if
<ahref="/pkg/net/#Dialer.KeepAlive"><code>Dialer.KeepAlive</code></a> is zero.
To disable, set it to a negative value.
</p>
<p><!-- CL 113997 -->
On Linux, the <ahref="http://man7.org/linux/man-pages/man2/splice.2.html"><code>splice</code> system call</a> is now used when copying from a
<ahref="/pkg/net/#UnixConn"><code>UnixConn</code></a> to a
The <ahref="/cmd/go/#hdr-Testing_flags"><code>-benchtime</code></a> flag now supports setting an explicit iteration count instead of a time when the value ends with an "<code>x</code>". For example, <code>-benchtime=100x</code> runs the benchmark 100 times.
The new methods <ahref="/pkg/archive/zip#File.OpenRaw"><code>File.OpenRaw</code></a>, <ahref="/pkg/archive/zip#Writer.CreateRaw"><code>Writer.CreateRaw</code></a>, <ahref="/pkg/archive/zip#Writer.Copy"><code>Writer.Copy</code></a> provide support for cases where performance is a primary concern.
The new <ahref="/pkg/io/fs/#FileInfoToDirEntry"><code>FileInfoToDirEntry</code></a> function converts a <code>FileInfo</code> to a <code>DirEntry</code>.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
