Roland Shoemaker [Tue, 9 May 2023 18:47:57 +0000 (11:47 -0700)]
runtime: implement SUID/SGID protections
On Unix platforms, the runtime previously did nothing special when a
program was run with either the SUID or SGID bits set. This can be
dangerous in certain cases, such as when dumping memory state, or
assuming the status of standard i/o file descriptors.
Taking cues from glibc, this change implements a set of protections when
a binary is run with SUID or SGID bits set (or is SUID/SGID-like). On
Linux, whether to enable these protections is determined by whether the
AT_SECURE flag is passed in the auxiliary vector. On platforms which
have the issetugid syscall (the BSDs, darwin, and Solaris/Illumos), that
is used. On the remaining platforms (currently only AIX) we check
!(getuid() == geteuid() && getgid == getegid()).
Currently when we determine a binary is "tainted" (using the glibc
terminology), we implement two specific protections:
1. we check if the file descriptors 0, 1, and 2 are open, and if they
are not, we open them, pointing at /dev/null (or fail).
2. we force GOTRACKBACK=none, and generally prevent dumping of
trackbacks and registers when a program panics/aborts.
In the future we may add additional protections.
This change requires implementing issetugid on the platforms which
support it, and implementing getuid, geteuid, getgid, and getegid on
AIX.
Thanks to Vincent Dehors from Synacktiv for reporting this issue.
Fixes #60272
Fixes CVE-2023-29403
Change-Id: I73fc93f2b7a8933c192ce3eabbf1db359db7d5fa
Reviewed-on: https://team-review.git.corp.google.com/c/golang/go-private/+/1878434 Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Roland Shoemaker <bracewell@google.com> Reviewed-by: Russ Cox <rsc@google.com>
Reviewed-on: https://go-review.googlesource.com/c/go/+/501223
Run-TryBot: David Chase <drchase@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Austin Clements [Tue, 6 Jun 2023 17:07:37 +0000 (13:07 -0400)]
runtime: skip TestCrashDumpsAllThreads with mayMoreStackPreempt
This test is flaky with in mayMoreStackPreempt mode. This is probably
revealing a real bug in the scheduler, but since it seems to only
affect TestCrashDumpsAllThreads, which is itself testing a debug mode,
I don't think this is high priority.
Austin Clements [Tue, 6 Jun 2023 01:48:59 +0000 (21:48 -0400)]
cmd/dist: remove deptab and cleanlist in favor of gentab
dist's deptab is a list of changes to the automatically derived set of
package dependencies. It's as old as dist itself, and the first
version of deptab in CL 5620045 was quite complex. From the beginning,
some of the entries in deptab have been for generated files that need
to be added to the dependency set because they can't be discovered if
they don't exist. gentab is also as old as dist itself, and lists the
generated dependency files.
The interaction between deptab and gentab is rather odd. gentab
contains only base file names, not whole paths. To figure out what
files to generate, dist takes a Cartesian product of deptab and gentab
and calls the generator wherever the basename of a path in deptab
matches an entry in gentab. This perhaps made sense at the time
because some of the generated files appeared in more than one package
in deptab.
These days, deptab consists exclusively of generated files because
dist can correctly derive all other dependencies, and all of the
generated files have unique paths. This makes the Cartesian product
approach needlessly complex (and so confusing!), and means that the
only purpose served by deptab is to provide full paths for generated
files.
Furthermore, in the dist clean command, it also needed to expand the
file names in gentab to complete paths, but it did so using a
different list, cleanlist, and the same Cartesian product algorithm.
This CL drops all of this complexity by putting full paths into
gentab, which lets us delete deptab and cleanlist.
Austin Clements [Tue, 6 Jun 2023 01:30:18 +0000 (21:30 -0400)]
cmd/dist: remove stale cleanup code
dist clean has logic to delete command binaries from the cmd
directories in cleanlist. However, these days the only binary it could
possibly remove is "$GOROOT/src/cmd/cgo/cgo". This is clearly no
longer necessary, so remove this stale code.
When this logic was originally introduced in CL 5622058, it was driven
by cleantab (not cleanlist), which contained all of the cmd
directories, which were legion at the time because this was the era of
the [568][acgl] toolchain. CL 9154 deleted cleantab, and did the same
clean walk over the "cmd/" directories listed in buildorder. However,
buildorder was a list of packages necessary to build cmd/go, so the
only "cmd/" directory in buildorder at the time was "cmd/go". Hence,
at that CL, dist started deleting only a "$GOROOT/src/cmd/go/go"
binary. The modern cleanlist was introduced in CL 76021, as a list of
packages containing "generated files and commands". The only "cmd/"
directory in cleanlist the whole time has been "cmd/cgo" (and I'm
honestly not sure why cmd/cgo is in there), so since that CL dist has
only deleted "$GOROOT/src/cmd/cgo/cgo".
Austin Clements [Tue, 6 Jun 2023 00:04:31 +0000 (20:04 -0400)]
cmd/dist: remove stale files from gentab
There are several files in gentab that have a nil generator, which
means they used to be generated, but aren't any more, so dist should
delete them if it encounters them. However, cleaning only look for
these file names in the small number of directories listed in
cleanlist, and none of these files were originally generated into any
of the directories in cleanlist. Specifically, enam.c was generated
into $GOROOT/src/cmd/[568]l starting with CL 5620045 until CL 35740044
and the anames[5689].c files were generated into $GOROOT/src/liblink
starting with CL 35740044 and CL 120690043 until CL 6110. None of
these directories even exist any more, and if these files did somehow
exist, dist wouldn't delete them anyway.
Hence, we can safely remove these files from gentab.
Robert Griesemer [Fri, 2 Jun 2023 00:20:02 +0000 (17:20 -0700)]
go/types, types2: handle named and literal interfaces in interface unification
If we don't have exact unification, we must consider interface
unification whether one of the types is a defined (named) interface
or not. Otherwise, if one of them is named, and the other one isn't,
the code selects interface-vs-non-interface unification and possibly
uses the wrong method set as the "required" method set, leading to
(incorrect) unification failure as was the case in #60564.
We can also not simply rely on getting this right in the subsequent
switch, through the handling of *Named types.
This CL fixes this simple logic error. If there's inexact unification,
now all (non-type parameter) interface cases are handled in one place,
before the switch. After handling interfaces, we are guaranteed that
we have either no interfaces, or we have exact unification where both
types must be of the same structure.
As a consequence, we don't need special handling for named interfaces
in the *Named case of the switch anymore.
Also, move the (unbound) type parameter swap from before interface
handling to after interface handling, just before the switch which
is the code that relies on a type parameter being in x, if any.
Fixes #60564.
Change-Id: Ibf7328bece25808b8dbdb714867048b93689f219
Reviewed-on: https://go-review.googlesource.com/c/go/+/500195 Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com>
Cherry Mui [Tue, 6 Jun 2023 02:28:48 +0000 (22:28 -0400)]
cmd/compile: check method name in PGO devirtualization
Currently, we devirtualize an interface call if the profile
indicates a concrete callee is hot on the same line, and the
concrete receiver implements the interface. But it is possible
that (likely due to another call on the same line, or possibly a
stale profile) the concrete call is to a different method.
With the current AST construction we generate correct code, as we
extract the method name from the interface call and use that to
create the concrete call. But the devirtualization decision is
based on an unrelated call in the profile.
Check the method name when finding the hottest callee, so we won't
use unrelated calls to different methods.
Change-Id: I75c026997926f21bd6cc5266d3ffe99649a9b2d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/500961
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
Robert Griesemer [Mon, 5 Jun 2023 16:30:58 +0000 (09:30 -0700)]
cmd/compile/internal/syntax: better error message when using = instead of ==
When = is used instead of == as part of a conditional expression,
the parser message emphasizes the LHS and RHS of = by always
parenthesizing the two sides. For example, for:
if x = y {}
the error is:
cannot use assignment (x) = (y) as value
This is done to highlight the LHS and RHS in case of more complex
cases such as
if x || y = z {}
which one may incorrectly read as (x) || (y == z) rather than the
correct (x || y) = z.
This CL fine-tunes the error message a bit by only adding the
parentheses if the LHS and RHS are binary expressions.
Fixes #60599.
For #23385.
Change-Id: Ida4c8d12464cc2ac15c934f24858eb6f43cf9950
Reviewed-on: https://go-review.googlesource.com/c/go/+/500975 Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Russ Cox [Mon, 5 Jun 2023 16:42:58 +0000 (12:42 -0400)]
doc/go1.21: move Ports to end
The most important parts of almost any release notes are the
language and tool changes. Those should be the first two sections.
Instead Ports interrupts the flow with information that usually
matters only to very few users.
Move Ports to the end of the release notes.
Change-Id: I78492e91e368184fb5f8e8d44d63f35b8f14eeae
Reviewed-on: https://go-review.googlesource.com/c/go/+/500957
TryBot-Bypass: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
Alessandro Arzilli [Wed, 17 May 2023 13:33:07 +0000 (15:33 +0200)]
runtime: add debugger hook for fatal signals
On Go <= 1.20 signals that caused the program to exit would eventually
call runtime.fatal. After the changes made in go.dev/cl/462437 but it
would still be nice if debuggers (eg. Delve) had a function they could
hook to intercept fatal signals.
Change-Id: Icf2b65187f95d52e60825c84f386806a75b38f6e
Reviewed-on: https://go-review.googlesource.com/c/go/+/495736 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Hyang-Ah Hana Kim <hyangah@gmail.com>
Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Cherry Mui [Fri, 2 Jun 2023 21:54:57 +0000 (17:54 -0400)]
runtime: move Segv and TgkillSegv to testprog
The non-cgo test points Segv and TgkillSegv are currently in
testprogcgo. Although the test points don't explicitly use cgo,
being a cgo program, there is still some C code that runs when
the test point is invoked, such as thread creation code.
For the cgo test points, sometimes we fail to unwind the stack if
C code is involved. For the non-cgo ones, we want to always be
able to unwind the stack, so we check for stack unwinding failures.
But if a signal is landed in the small piece of C code mentioned
above, we may still fail to unwind. Move the non-cgo test points
to a pure-Go program to avoid this problem.
May fix #52963.
Updates #59029, #59443, #59492.
Change-Id: I35d99a0dd4c7cdb627e2083d2414887a24a2822d
Reviewed-on: https://go-review.googlesource.com/c/go/+/500535 Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Cuong Manh Le [Sat, 3 Jun 2023 01:33:51 +0000 (08:33 +0700)]
cmd/compile: allow ir.OMIN/ir.OMAX in mayCall
CL 496257 adds min/max builtins, which may appear as argument to a
function call, so it will be tested by mayCall. But those ops are not
handled by mayCall, causes the compiler crashes.
Fixes #60582
Change-Id: I729f10bf62b4aad39ffcb1433f576e74d09fdd9a
Reviewed-on: https://go-review.googlesource.com/c/go/+/500575 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Russ Cox [Thu, 1 Jun 2023 18:16:58 +0000 (14:16 -0400)]
cmd/go: maintain go and toolchain lines in go.work
go work init / sync / use need to maintain the invariant that the
go version and toolchain in go.work are up-to-date with respect
to the modules in the workspace.
go get also preserves the invariant when running in a module.
go work use (including with no arguments) reestablishes the invariant.
Replaces the ToolchainTrySwitch func in PackageOpts with a new
gover.Switcher interface implemented by toolchain.Switcher.
Until now, the basic sketch of a particular phase of the go command
has been to call base.Error repeatedly, to report as many problems
as possible, and then call base.ExitIfErrors at strategic places where
continuing in the presence of errors is no longer possible.
A Switcher is similar: you call sw.Error repeatedly and then, when
all the errors from a given phase have been identified, call sw.Switch
to potentially switch toolchains, typically before calling base.ExitIfErrors.
One effect of the regularization of errors reported by the modload.loader
is to add a "go: " prefix to errors showing import stacks. That seems fine.
thepudds [Sat, 3 Jun 2023 00:56:31 +0000 (00:56 +0000)]
cmd/compile/internal/devirtualize: devirtualize methods in other packages if current package has a concrete reference
The new PGO-driven indirect call specialization from CL 492436
in theory should allow for devirtualization on methods
in another package when those methods are directly referenced
in the current package.
However, inline.InlineImpossible was checking for a zero-length
fn.Body and would cause devirtualization to fail
with a debug log message like:
"should not PGO devirtualize (*Speaker1).Speak: no function body"
Previously, the logic in inline.InlineImpossible was only
called on local functions, but with PGO-based devirtualization,
it can now be called on imported functions, where inlinable
imported functions will have a zero-length fn.Body but a
non-nil fn.Inl.
We update inline.InlineImpossible to handle imported functions
by adding a call to typecheck.HaveInlineBody in the check
that was previously failing.
For the test, we need to have a hopefully temporary workaround
of adding explicit references to the callees in another package
for devirtualization to work. CL 497175 or similar should
enable removing this workaround.
Bryan C. Mills [Tue, 30 May 2023 20:43:50 +0000 (16:43 -0400)]
cmd/go: adjust pruning and switch toolchain when needed in 'go mod tidy'
'go mod tidy' may resolve an imported package by added a dependency
that requires a higher 'go' version, which may activate graph pruning
(if the version goes from below go 1.16 to above it), and may even
require switching to a newer toolchain (if the version is not
supported by the current one).
Bryan C. Mills [Thu, 25 May 2023 21:07:26 +0000 (17:07 -0400)]
cmd/go: adjust pruning and switch toolchains if needed when go get changes go version
When we do 'go get', the Go version can change now.
That means we need to do the pruning conversions that
until now have only been necessary in go mod tidy -go=version.
We may also need to upgrade the toolchain in order to load enough o
the module graph to finish the edit, so we should let a TooNewError
bubble up to the caller instead of trying to downgrade the affected
module to avoid the error.
Bryan C. Mills [Fri, 2 Jun 2023 03:42:48 +0000 (23:42 -0400)]
cmd/go: adjust conditions in which toolchain lines are written
'go mod tidy -go=1.20' should tidy as Go 1.20 did, without writing a
toolchain line implicitly. (We don't need it to stabilize toolchain
version switching anyway: because Go 1.20 predates toolchain
switching, any toolchain that supports switching toolchains also
supports Go 1.20 modules directly.)
Dmitri Shuralyov [Fri, 2 Jun 2023 18:33:23 +0000 (14:33 -0400)]
doc/go1.21: document macOS and Windows requirements
For #58645.
Fixes #57125.
Fixes #57003.
Fixes #57004.
Change-Id: I365929ca36aeb32e9ecd19f870e70869933ba6a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/500239 Reviewed-by: Eli Bendersky <eliben@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Bypass: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Zhiyuan Zheng [Thu, 13 Oct 2022 03:28:10 +0000 (03:28 +0000)]
net: filter disabled interfaces in Windows DNS client
The Go DNS resolver on Windows should filter disabled
interfaces. Otherwise disabled TUN devices, VPNs will be also
considered as valid nameservers and finally timedout.
Fixes #56160
(Originally from Zhiyuan Zheng <zhzy0077@hotmail.com>
in https://go.dev/cl/442375)
Robert Griesemer [Thu, 1 Jun 2023 22:02:54 +0000 (15:02 -0700)]
go/types, types2: report inference instead of assignment failure when types can't match
Interface inference must only be used if we don't require exact
unification, otherwise we may infer types (that are reasonable)
but then fail with an assignment error.
Only checking if exact is set for defined (named) types is not
sufficient, we must also check outside. Oversight.
Fixes #60562.
Change-Id: I208a74bf7ed80bcb976ba9cc172715c83f9e3d0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/499996
Auto-Submit: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
Dmitri Shuralyov [Thu, 1 Jun 2023 21:55:06 +0000 (17:55 -0400)]
cmd/api: make check even pickier about api/next/*.txt
As spotted in CL 499981, 3 out of 51 of the api/next/*.txt files
ended up with a blank line at the end. It's possible it would've
been more if human reviewers didn't catch them.
Since there's no formatter for these files, the only way to help
catch things is to make the check pickier (as done in CL 431335).
It can be loosened to let in useful blank lines if needed in the
future.
Change-Id: Iae7ee8e782b32707c576150914539ac4cc0faec4
Reviewed-on: https://go-review.googlesource.com/c/go/+/500115 Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Alan Donovan [Thu, 1 Jun 2023 22:29:57 +0000 (18:29 -0400)]
math/big: rename Int.ToFloat64 to Float64
The "To" prefix was a relic of the first draft
that I failed to make consistent with the unprefixed
name used in the proposal. Fortunately iant spotted
it during the API audit.
Updates #56984
Updates #60560
Change-Id: Ifa6eeddf6dd5f0637c0568e383f9a4bef88b10f9
Reviewed-on: https://go-review.googlesource.com/c/go/+/500116 Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Alan Donovan <adonovan@google.com>
Russ Cox [Thu, 1 Jun 2023 17:25:56 +0000 (13:25 -0400)]
cmd/go: add base.Error and base.Fatal
Many many places in the go command use
base.Errorf("go: %v", err)
or
base.Fatalf("go: %v", err)
Introduce Error(error) and Fatal(error) to do this
and update all call sites (global search and replace).
The new Error gives us the opportunity to unwrap
a multierror and add the go prefix to each line,
which is the motivation for this change.
(We want to start returning a multierror from LoadModFile
and LoadModGraph.)
Austin Clements [Wed, 31 May 2023 16:32:29 +0000 (12:32 -0400)]
cmd/cgo/internal/testerrors: pass if GOEXPERIMENT=cgocheck2 is set
The tests in this package are meant to check cgocheck and cgocheck2
mode, so they're of course sensitive to whether they're set.
Currently, the test will set GOEXPERIMENT=cgocheck2 for tests of
cgocheck2 mode, but won't *unset* cgocheck2 mode if it's already in
the environment for tests that expect it to be off. This means
GOEXPERIMENT=cgocheck2 go test cmd/cgo/internal/testerrors
fails.
Fix this by removing cgocheck2 from GOEXPERIMENT if it's set and the
test case expects it to be unset.
Change-Id: If663e41b791fb89df9940bc5356a566e2a54a77a
Reviewed-on: https://go-review.googlesource.com/c/go/+/499557
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
Christian Banse [Fri, 21 Apr 2023 15:13:17 +0000 (15:13 +0000)]
cmd/link/internal/ld: pass correct offset to codesign.Sign
Previously, codesign.Sign was called with Segtext.Fileoff and
Segtext.Filelen. However, both variables do not contain the
complete __TEXT segment, as it excludes padding and header.
Therefore, we now store a reference to the complete segment
in mstext when it is created and pass its offset (which should
always be 0) and filesize to codesign.Sign.
Ian Lance Taylor [Thu, 1 Jun 2023 16:03:50 +0000 (09:03 -0700)]
doc/go1.21: correct links in go/build note
Change-Id: Ie84cad994c1ffb2c91ce45b2dfb9257e6a7f309b
Reviewed-on: https://go-review.googlesource.com/c/go/+/499957 Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com> Reviewed-by: Eli Bendersky <eliben@google.com>
Eli Bendersky [Thu, 1 Jun 2023 13:13:46 +0000 (06:13 -0700)]
doc: remove relnote TODO by merging with another section
This change was already described in the linker section.
Change-Id: I3e36dbd66b3b53c5f0063b0d67d8773383f1f77f
Reviewed-on: https://go-review.googlesource.com/c/go/+/499817
Auto-Submit: Eli Bendersky <eliben@google.com> Reviewed-by: Eli Bendersky <eliben@google.com>
TryBot-Bypass: Eli Bendersky <eliben@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
Ian Lance Taylor [Thu, 1 Jun 2023 16:00:46 +0000 (09:00 -0700)]
doc/go1.21: reformat flag init change note
It reads better as a single paragraph. Also added links.
Change-Id: Id6ba54111b63fbd536423272f674e0eb64b087a7
Reviewed-on: https://go-review.googlesource.com/c/go/+/499956
TryBot-Bypass: Ian Lance Taylor <iant@google.com> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
Ian Lance Taylor [Thu, 1 Jun 2023 15:53:54 +0000 (08:53 -0700)]
doc/go1.21: remove some references to reverted CLs
Change-Id: Id9a8871af9cc3ac26be539877f2eea3462db6f3d
Reviewed-on: https://go-review.googlesource.com/c/go/+/499955
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Eli Bendersky <eliben@google.com>
Ian Lance Taylor [Thu, 1 Jun 2023 15:49:47 +0000 (08:49 -0700)]
doc/go1.21: fix type in closing tag
Change-Id: Ibcdedb8222a80c0478f783f4a1800e472dbe062c
Reviewed-on: https://go-review.googlesource.com/c/go/+/499935 Reviewed-by: Eli Bendersky <eliben@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
Eli Bendersky [Thu, 1 Jun 2023 12:57:58 +0000 (05:57 -0700)]
doc: add release note for go:wasmimport
Change-Id: I9c6fc4c7e24d0e78086d95dccd61e80bd5ddd856
Reviewed-on: https://go-review.googlesource.com/c/go/+/499815
Auto-Submit: Eli Bendersky <eliben@golang.org> Reviewed-by: Eli Bendersky <eliben@google.com> Reviewed-by: Johan Brandhorst-Satzkorn <johan.brandhorst@gmail.com>
TryBot-Bypass: Eli Bendersky <eliben@golang.org> Reviewed-by: Cherry Mui <cherryyz@google.com>
Bryan C. Mills [Fri, 26 May 2023 18:48:22 +0000 (14:48 -0400)]
cmd/go/internal/toolchain: avoid importing modcmd
modcmd is a high-level command, but toolchain is a low-level building
block. A dependency from toolchain on modcmd makes it very difficult
to call from other lower-level packages without creating an import
cycle.
Instead, use modfetch.Download in place of modcmd.DownloadModule.
Eli Bendersky [Thu, 1 Jun 2023 13:11:51 +0000 (06:11 -0700)]
doc: add release note for cgo error on methods on C types
Change-Id: Ibc5f23f37e5bd45034771a0205eadac3072d6870
Reviewed-on: https://go-review.googlesource.com/c/go/+/499816
TryBot-Bypass: Eli Bendersky <eliben@google.com> Reviewed-by: Eli Bendersky <eliben@google.com> Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Eli Bendersky <eliben@google.com>
Michael Pratt [Wed, 31 May 2023 18:45:30 +0000 (14:45 -0400)]
runtime: only increment extraMInUse when actually in use
Currently lockextra always increments extraMInUse, even if the M won't
be used (or doesn't even exist), such as in addExtraM. addExtraM fails
to decrement extraMInUse, so it stays elevated forever.
Fix this bug and simplify the model by moving extraMInUse out of
lockextra to getExtraM, where we know the M will actually be used.
While we're here, remove the nilokay argument from getExtraM, which is
always false.
Fixes #60540.
Change-Id: I7a5d97456b3bc6ea1baeb06b5b2975e3b8dd96a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/499677 Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Russ Cox [Wed, 31 May 2023 20:45:03 +0000 (16:45 -0400)]
cmd/go: delete cmd/go/internal/slices in favor of slices
Some files already use "slices", others use "cmd/go/internal/slices".
(Some files are using more than slices.Clip and must use "slices".)
Use "slices" consistently and delete cmd/go/internal/slices.
Russ Cox [Wed, 31 May 2023 14:24:23 +0000 (10:24 -0400)]
cmd/go: make toolchain less special in MVS
We were using the omission of toolchain from the MVS graph
as a signal that toolchain was not mentioned on the go get line,
but not including it in the graph causes various problems,
and it may be reintroduced to the graph during operations like
pruning conversion, after which its presence is not a good signal
about whether it was mentioned on the go get command line.
Fix all this irregularity by explicitly telling WriteGoMod whether
the command line mentioned toolchain instead.
Ian Lance Taylor [Wed, 31 May 2023 21:23:46 +0000 (14:23 -0700)]
doc/go1.21: remove math.Compare TODOs
Change-Id: I975b437240df03da84f2ce7c47f7a0097a597f25
Reviewed-on: https://go-review.googlesource.com/c/go/+/499638 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Eli Bendersky <eliben@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
Robert Griesemer [Tue, 30 May 2023 22:13:53 +0000 (15:13 -0700)]
doc/go1.21: document type inference changes
For #39661.
For #41176.
For #51593.
For #52397.
For #57192.
For #58645.
For #58650.
For #58671.
For #59338.
For #59750.
For #60353.
Change-Id: Ib731c9f2879beb541f44cb10e40c36a8677d3ad4
Reviewed-on: https://go-review.googlesource.com/c/go/+/499282
TryBot-Bypass: Robert Griesemer <gri@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
Ian Lance Taylor [Tue, 30 May 2023 22:19:44 +0000 (15:19 -0700)]
Revert "math: add Compare and Compare32"
This reverts CL 467515. Now that we have cmp.Compare,
we don't need math.Compare or math.Compare32 after all.
For #56491
Fixes #60519
Change-Id: I8ed33464adfc6d69bd6b328edb26aa2ee3d234d9
Reviewed-on: https://go-review.googlesource.com/c/go/+/499416 Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Eli Bendersky <eliben@google.com>
Mark Ryan [Fri, 26 May 2023 08:51:21 +0000 (10:51 +0200)]
runtime: fix alignment code in memmove_riscv64.s
The riscv64 implementation of memmove has two optimizations that are
applied when both source and destination pointers share the same alignment
but that alignment is not 8 bytes. Both optimizations attempt to align the
source and destination pointers to 8 byte boundaries before performing 8 byte
aligned loads and stores. Both optimizations are incorrect. The first
optimization is applied when the destination pointer is smaller than the source
pointer. In this case the code increments both pointers by (pointer & 3) bytes
rather than (8 - (pointer & 7)) bytes. The second optimization is applied
when the destination pointer is larger than the source pointer. In this
case the existing code decrements the pointers by (pointer & 3) bytes instead
of (pointer & 7).
This commit fixes both optimizations avoiding unaligned 8 byte accesses.
As this particular optimization is not covered by any of the existing
benchmarks a new benchmark, BenchmarkMemmoveUnalignedSrcDst,
is provided that exercises both optimizations. Results of the new
benchmark, which were run on a SiFive HiFive Unmatched A00 with 16GB of RAM
running Ubuntu 23.04 are presented below.
Ian Lance Taylor [Wed, 31 May 2023 18:51:28 +0000 (11:51 -0700)]
doc/go1.21: mention upgrade to Unicode 15.0.0
For #48621
For #55079
Change-Id: I279b4fbf07d2fa9de9577559a4e17a57f5692aa3
Reviewed-on: https://go-review.googlesource.com/c/go/+/499618 Reviewed-by: Eli Bendersky <eliben@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
Ian Lance Taylor [Wed, 31 May 2023 18:47:14 +0000 (11:47 -0700)]
doc/go1.21: document new bytes.Buffer methods
For #53685
Change-Id: I237297d19afeb36ad738074d0c61caa7012f65ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/499617 Reviewed-by: Eli Bendersky <eliben@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
Ian Lance Taylor [Wed, 31 May 2023 18:41:31 +0000 (11:41 -0700)]
doc/go1.21: mention debug/elf changes
For #55107
For #56887
For #56892
Change-Id: Ibcca34c931ed3595d877c4573bba221dec66bb5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/499616 Reviewed-by: Eli Bendersky <eliben@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Ian Lance Taylor [Tue, 30 May 2023 22:36:16 +0000 (15:36 -0700)]
doc/go1.21: reading from debug/pe uninitialized section fails
For #47653
Change-Id: Id44c9dba58966f43f188030a53343d890a6ffde7
Reviewed-on: https://go-review.googlesource.com/c/go/+/499419
Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com> Reviewed-by: Eli Bendersky <eliben@google.com>
Ian Lance Taylor [Tue, 30 May 2023 22:31:39 +0000 (15:31 -0700)]
doc/go1.21: mention that embedded files implement ReadAt
For #57803
Change-Id: I8e33f4dd3fc3071bfbf4d2848faefbe8488f5742
Reviewed-on: https://go-review.googlesource.com/c/go/+/499418
TryBot-Bypass: Ian Lance Taylor <iant@google.com> Reviewed-by: Eli Bendersky <eliben@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Ian Lance Taylor [Tue, 30 May 2023 22:27:29 +0000 (15:27 -0700)]
doc/go1.21: mention flag.BoolFunc
For #53747
Change-Id: Ia5e2f89c1184f2dfd6d672b838b0dbb579e6c954
Reviewed-on: https://go-review.googlesource.com/c/go/+/499417 Reviewed-by: Eli Bendersky <eliben@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Ian Lance Taylor [Tue, 30 May 2023 17:42:57 +0000 (10:42 -0700)]
doc/go1.21: document io/fs formatting functions
Also document the new String methods that call them.
For #54451
Change-Id: I5cd7e0fc6c84097bba6d29c4d6012ed3c8bb1e0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/499177 Reviewed-by: Eli Bendersky <eliben@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Bypass: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Ian Lance Taylor [Tue, 30 May 2023 22:15:43 +0000 (15:15 -0700)]
doc/go1.21: mention directive handling in go/{ast,build}
For #56986
For #59033
Change-Id: I7d03fe34d418aff97a551b236b5d43506e402871
Reviewed-on: https://go-review.googlesource.com/c/go/+/499415
TryBot-Bypass: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Michael Anthony Knyszek [Mon, 22 May 2023 21:39:54 +0000 (21:39 +0000)]
runtime: fix race in BenchmarkSetType* benchmarks
Currently the BenchmarkSetType* benchmarks are racy: they call
heapBitsSetType on an allocation that might be in a span in-use for
allocation on another P. Because heap bits are bits but are written
byte-wise non-atomically (because a P assumes it has total ownership of
a span's bits), two threads can race writing the same heap bitmap byte
creating incorrect metadata.
Fix this by forcing every value we're writing heap bits for into a large
object. Large object spans will never be written to concurrently unless
they're freed first.
Also, while we're here, refactor the benchmarks a bit. Use generics to
eliminate the reflect nastiness in gc_test.go, and pass b.ResetTimer
down into the test to get slightly more accurate results.
Fixes #60050.
Change-Id: Ib7d6249b321963367c8c8ca88385386c8ae9af1c
Reviewed-on: https://go-review.googlesource.com/c/go/+/497215 Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Russ Cox [Wed, 31 May 2023 13:57:03 +0000 (09:57 -0400)]
cmd/go: introduce WriteOpts argument for WriteGoMod
This CL is a no-op, just adding the new options and plumbing it through.
'go get' will use this option to let commitRequirements know whether
toolchain was mentioned explicitly on the command line.
Russ Cox [Fri, 26 May 2023 03:28:39 +0000 (23:28 -0400)]
cmd/go: add detection of toolchain switch loops
This happens mainly during testing because the virtual
toolchain switch is not terribly robust, and if you accidentally
try to exec "1.23" instead of "go1.23" it will let you, but it
won't work right.
Of course, although we feel pretty good about the non-test
implementation, perhaps it has a toolchain switch loop lurking too,
or perhaps one will be introduced in the future.
To handle the test bug, and just in case we have a real bug later,
add detection of toolchain switch loops with clear messages.
Also fixes a bug in setting the -lang flag properly when invoking
the Go compiler: this is the first test using 'go 1.21.x' lines
during a build.
Michael Anthony Knyszek [Fri, 26 May 2023 17:56:39 +0000 (17:56 +0000)]
runtime: make TestCPUMetricsSleep even more lenient
This test was introduced as a regression test for #60276. However, it
was quite flaky on a number of different platforms because there are
myriad ways the runtime can eat into time one might expect is completely
idle.
This change re-enables the test, but makes it much more resilient.
Because the issue we're testing for is persistent, we now require 10
consecutive failures to count. Any single success counts as a test
success. This change also makes the test's idle time bound more lenient,
allowing for a little bit of time to be eaten up. The regression we're
testing for results in nearly zero idle time being accounted for.
If this is still not good enough to eliminate flakes, this test should
just be deleted.
For #60276.
Fixes #60376.
Change-Id: Icd81f0c9970821b7f386f6d27c8a566fee4d0ff7
Reviewed-on: https://go-review.googlesource.com/c/go/+/498274
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
Russ Cox [Tue, 30 May 2023 17:28:56 +0000 (13:28 -0400)]
cmd/go: scan $PATH to find version list in NewerToolchain
NewerToolchain needs a list of candidate toolchains.
Currently it always consults the module version list, using the network.
When GOTOOLCHAIN=path, it should probably not do this,
both because =path implies we don't want to use the network
and because not every released version will be in $PATH.
Instead, scan $PATH to find the available versions.
Than McIntosh [Tue, 30 May 2023 23:16:56 +0000 (19:16 -0400)]
internal/coverage/pods: sort counter files first by origin, then name
This patch fixes a problem with the way pods (clumps of related
coverage meta+counter data files) are collected, which was causing
problems for "go tool covdata subtract".
A subtract operation such as "go tool covdata subtract -i=dir1,dir2
-o=out" works by loading in all the counter data files from "dir1"
before any of the data files from "dir2" are loaded. The sorting
function in the pods code was sorting counter files for a given pod
based purely on name, which meant that differences in process ID
assignment could result in some files from "dir2" being presented
before "dir1". The fix is to change the sorting compare function to
prefer origin directory over filename.
Fixes #60526.
Change-Id: I2226ea675fc99666a9a28e6550d823bcdf2d6977
Reviewed-on: https://go-review.googlesource.com/c/go/+/499317
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
Keith Randall [Tue, 30 May 2023 17:54:21 +0000 (10:54 -0700)]
doc: document new panic behavior of flag definition after Set
For #57411
Change-Id: I56c112bb03dde24c2e2643c9b72ce06158a8e717
Reviewed-on: https://go-review.googlesource.com/c/go/+/499278
TryBot-Bypass: Keith Randall <khr@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Keith Randall <khr@google.com>
Keith Randall [Tue, 30 May 2023 18:36:19 +0000 (11:36 -0700)]
doc: document change of cgocheck=2 from debug to experiment
Change-Id: I98bdfe8ab338a5b92c466a5aacfa95266171e5c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/499279 Reviewed-by: Keith Randall <khr@google.com>
TryBot-Bypass: Keith Randall <khr@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
Keith Randall [Tue, 30 May 2023 20:00:00 +0000 (13:00 -0700)]
doc: mention the new purego implementation of hash/maphash
Change-Id: Ieedddf52ae09cf5a8e9347f0f30aff21e8369787
Reviewed-on: https://go-review.googlesource.com/c/go/+/499281 Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Keith Randall <khr@google.com>
TryBot-Bypass: Keith Randall <khr@golang.org>
Robert Griesemer [Fri, 26 May 2023 23:27:28 +0000 (16:27 -0700)]
go/types, types2: use exact unification for component types
This change defines two unification modes used to control unification:
- assign set when unifying types involved in an assignment
- exact if set, types unify if they can be made identical
Currently, unification is inexact: when a defined type is compared
against a type literal, the underlying type of the defined type is
considered. When channel types are compared, the channel direction
is ignored. And when defined types are compared where one (or both)
are interfaces, interface unification is used.
By contrast, exact unification requires types to match exactly:
if they can be unified, the types must be identical (with suitable
type arguments).
Exact unification is required when comparing component types.
For instance, when unifying func(x P) with func(x Q), the two
signatures unify only if P is identical to Q per Go's assignment
rules.
Until now we have ignored exact unification and made due with inexact
unification everywhere, even for component types. In some cases this
led to infinite recursions in the unifier, which we guarded against
with a depth limit (and unification failure).
Go's assignmemt rules allow inexact matching at the top-level but
require exact matching for element types.
This change passes 'assign' to the unifier when unifying parameter
against argument types because those follow assignment rules.
When comparing constraints, inexact unification is used as before.
In 'assign' mode, when comparing element types, the unifyier is
called recursively, this time with the 'exact' mode set, causing
element types to be compared exactly. If unification succeeds for
element types, they are identical (with suitable type arguments).
This change fixes #60460. It also fixes a bug in the test for
issue #60377. We also don't need to rely anymore on the recursion
depth limit (a temporary fix) for #59740. Finally, because we use
exact unification when comparing element types which are channels,
errors caused by assignment failures (due to inexact inference which
succeeded when it shouldn't have) now produce the correct inference
error.
Fixes #60460.
For #60377.
For #59740.
Change-Id: Icb6a9b4dbd34294f99328a06d52135cb499cab85
Reviewed-on: https://go-review.googlesource.com/c/go/+/498895 Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Robert Griesemer [Sat, 27 May 2023 21:31:14 +0000 (14:31 -0700)]
go/types, types2: add unifyMode to unifier, pass it through
Pass a mode parameter through all unifier calls but make no use of it.
When unifying type elements (components of composite types), use emode,
which currently is set to mode.
Preparatory step to fix #60460. Factoring out this mechanical change
will make the actual fix smaller and easier to review and understand.
Because this change doesn't affect the behavior of the unifier, it is
safe.
For #60460.
Change-Id: I5b67499d93025be2128c14cc00bcc3b8cc9f44b2
Reviewed-on: https://go-review.googlesource.com/c/go/+/498955
Auto-Submit: Robert Griesemer <gri@google.com> Reviewed-by: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Griesemer <gri@google.com> Reviewed-by: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Michael Anthony Knyszek [Wed, 24 May 2023 19:53:14 +0000 (19:53 +0000)]
cmd/cgo: rewrite pointer passing rules in terms of pinning
With the introduction of runtime.Pinner, we need to update the cgo
pointer passing rules to accomodate the new functionality. These rule
changes are easier to describe if the rest of the pointer passing rules
are described in terms of pinning as well (Go memory is implicitly
pinned when a pointer to it is passed to a C function, and implicitly
unpinned when that function returns).
For #46787.
Change-Id: I263f03412bc9165f19c9ada72fb005ed0483a8ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/498116 Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
Russ Cox [Thu, 25 May 2023 15:59:50 +0000 (11:59 -0400)]
cmd/go: lock in new toolchain semantics
The design doc says 'toolchain' lines apply even if the default
toolchain is older than the one specified in the toolchain line.
However, that leads to various confusing behavior and security issues.
Instead, treat toolchain as a min go version that only applies
in the current module (not in dependencies).
As an example of confusing behavior / security issue, if I install
Go 1.30 and then run 'go build' in a module I've checked out,
I expect to use Go 1.30 or newer, not to silently use an older toolchain
that may have security problems fixed in Go 1.30.
Making toolchain a min establishes that guarantee.
Also clean up the tests quite a bit.
Finally drop + from the acceptable version suffixes; we use + for +auto and +path.
Russ Cox [Wed, 24 May 2023 21:37:11 +0000 (17:37 -0400)]
cmd/go: switch to newer toolchain in go get as needed
If we run 'go get go@1.40' or 'go get m@v' where m has a go.mod
that says 'go 1.40', we need to write a new go.mod that says 'go 1.40'.
But we can't be sure we know how to write a Go 1.40-compatible go.mod.
Instead, download the latest point release of Go 1.40 and invoke it to
finish the get command.