The -C dir flag was added in Go 1.20.
This CL adds a new restriction: the -C must appear as the first flag on the command line.
This restriction makes finding the -C flag robust and matches the general way
people tend to think about and use the -C flag anyway.
It may break a few scripts that have been written since Go 1.20
but hopefully they will not be hard to find and fix.
(There is no strict compatibility guarantee for the command line.)
For #57001.
Change-Id: Ice2e5982c58d41eabdaef42a80d3624cde2c9873
Reviewed-on: https://go-review.googlesource.com/c/go/+/500915
TryBot-Bypass: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Move NewerToolchain and related code from select.go to switch.go
because it is only used for the Switch operation, not for Select.
This is a separate CL containing only the code move, separate
from any other changes.
For #57001.
Change-Id: I41cf0629b41fd55c30a1e799d857c06039ee99b6
Reviewed-on: https://go-review.googlesource.com/c/go/+/500798
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Additional tests and bug fixes realized while writing go.dev/doc/gotoolchain (CL 500775).
- Handle go get toolchain@go1.22 (resolve to latest patch release, same as go get go@1.22).
(See modload/query.go and gover/mod.go.)
- Handle go get go@patch toolchain@patch.
(See modload/query.go and gover/mod.go.)
- Remove prefix-goVERSION-suffix form for toolchain name,
standardizing on goVERSION-suffix.
I have no good explanation for having two forms, so simplify to one.
(See vendor and gover.)
- Fail toolchain downloads when GOSUMDB=off.
Because toolchain downloads cannot always be predicted
(especially during switching rather than selection),
they cannot be listed in go.sum.
We rely on the checksum database for integrity of the download,
especially if proxied. If the checksum database is disabled,
this integrity check won't happen, so fail toolchain downloads.
(See modfetch/sumdb.go and script/gotoolchain_net.txt)
- Use names from documentation in package toolchain
(Select, Switch; SwitchTo renamed to Exec to avoid both names;
reqs.go renamed to switch.go; toolchain.go renamed to select.go.)
- Make "go env GOTOOLCHAIN" and "go env -w GOTOOLCHAIN"
work even when GOTOOLCHAIN is misconfigured.
(See special case at top of Select in select.go.)
- Clarify what goInstallVersion does
(report whether this is go install or go run pkg@version)
and explain the potential version switch more clearly.
Use the Switcher directly instead of reimplementing it.
(See select.go.)
- Document go@ and toolchain@ forms in go help get,
linking to go.dev/doc/toolchain.
(See modget/get.go.)
- Update URL of documentation in $GOROOT/go.env.
For #57001.
Change-Id: I895ef3519ff95db8710ed23b36ebaf4f648120cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/500797
Reviewed-by: Michael Matloob <matloob@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Bypass: Russ Cox <rsc@golang.org>
Incorporate CL 501035 for toolchain syntax changes
and a fix to a race (harmless outside tests) in sumdb client.
go get golang.org/x/mod@62c7e578 # CL 501035
go mod tidy
go mod vendor
This CL will break the cmd/go tests. The next CL fixes them.
For #57001.
Change-Id: I1fcb9799417595ecff870367f256cbc0a488934c
Reviewed-on: https://go-review.googlesource.com/c/go/+/500796
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Bypass: Russ Cox <rsc@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
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>
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.
Updates #55160.
Change-Id: Iac558c098930ad8d4392b1e82b34f55eaec77c48
Reviewed-on: https://go-review.googlesource.com/c/go/+/501229
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Auto-Submit: Austin Clements <austin@google.com>
Right now, every code generator in dist has a copy of the
// Code generated by go tool dist; DO NOT EDIT.
string. Put it in one place to make sure it doesn't diverge.
Change-Id: I8b2a1904031599d7fc128b6a5d74480dee05fc89
Reviewed-on: https://go-review.googlesource.com/c/go/+/501138
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
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.
Change-Id: Ie3993983734f6da3be453bb4c17a64e22dcf3e8f
Reviewed-on: https://go-review.googlesource.com/c/go/+/501137
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
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".
Change-Id: I1915eb938d1a0e22ae6a64e7648a21894d3e6502
Reviewed-on: https://go-review.googlesource.com/c/go/+/501136
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Russ Cox <rsc@golang.org>
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.
Change-Id: Ifed322d64a7a81a76537fcd9fc7020c7aca48050
Reviewed-on: https://go-review.googlesource.com/c/go/+/501135
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
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>
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>
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>
Make it more consistent with the static devirtualization
diagnostic message. Keep the print of concrete callee's method
name, as it is clearer.
Change-Id: Ibe9b40253eaff2c0071353a2b388177213488822
Reviewed-on: https://go-review.googlesource.com/c/go/+/500960
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Also handle go test -c TODO.
For #15513.
For #56986.
For #57001.
Change-Id: I571ae25d8d8fcd44cb38ac16cdd2a1180016eb94
Reviewed-on: https://go-review.googlesource.com/c/go/+/500956
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Chase <drchase@google.com>
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>
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>
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>
The workaround in CL 69970044 introduced a panic when StartProcess is
called with empty argv. Check the length before trying to access it.
Change-Id: Ic948d86c7067a21c484ba24e100d1f1f80179730
Reviewed-on: https://go-review.googlesource.com/c/go/+/500415
Run-TryBot: Roland Shoemaker <roland@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Do not return prematurely in assignableTo.
Fixes#54424.
Change-Id: I769b3b4ad9d79b7bce60b92cc59c3564117e36db
Reviewed-on: https://go-review.googlesource.com/c/go/+/498400
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>
Reviewed-by: Robert Findley <rfindley@google.com>
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>
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.
For #57001.
Change-Id: Id49ff7a28a969d3475c70e6a09d40d7aa529afa8
Reviewed-on: https://go-review.googlesource.com/c/go/+/499984
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
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.
Fixes#60561
Updates #59959
Change-Id: I48449b7d8b329d84151bd3b506b8093c262eb2a3
GitHub-Last-Rev: 2d53c55fd8
GitHub-Pull-Request: golang/go#60565
Reviewed-on: https://go-review.googlesource.com/c/go/+/500155
Run-TryBot: thepudds <thepudds1460@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
'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).
For #57001.
Change-Id: Ic8e9b87d5979b3a6d1ee70f1f2bf2eea46b1bb0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/499676
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
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.
Revised from CL 498120.
For #57001.
Change-Id: Ic8994737eca4ed61ccc093a69e46f5a6caa8be87
Reviewed-on: https://go-review.googlesource.com/c/go/+/498267
Reviewed-by: Russ Cox <rsc@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
'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.)
For #57001.
Change-Id: I415abac75d8d6de9f8ed470aab0d1ed4c225b08d
Reviewed-on: https://go-review.googlesource.com/c/go/+/499987
Auto-Submit: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
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>
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)
Co-authored-by: Zhiyuan Zheng <zhzy0077@hotmail.com>
GitHub-Last-Rev: db158625bb
GitHub-Pull-Request: golang/go#56161
Change-Id: I7becebc55c8ac612c670c533855f7e6ca397a496
Reviewed-on: https://go-review.googlesource.com/c/go/+/500375
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Auto-Submit: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
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>
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>
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>
Return more errors instead of base.Fatalf, so we can handle them
in the callers.
For #57001.
Change-Id: If3e63d3f64188148f5d750991f9cb1175790d89d
Reviewed-on: https://go-review.googlesource.com/c/go/+/499983
Reviewed-by: Bryan Mills <bcmills@google.com>
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
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.)
For #57001.
Change-Id: I9613653b94808224146077c30d22f814d4e19eed
Reviewed-on: https://go-review.googlesource.com/c/go/+/499980
Auto-Submit: Russ Cox <rsc@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
One issue simply has a reworded message, probably from a new version of
GDB. Another is a new issue.
Fixes#60553.
Fixes#58698.
Updates #39204.
Change-Id: I8389aa981fab5421f57ee761bfb5e1dd237709ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/499975
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
HAUTO should be handled the same way as other stack offsets for
adding to constant pool. Add the missing cases.
Fixes#57955.
Change-Id: If7fc82cafb2bbf0a6121e73e353b8825cb36b5bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/463138
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Some testdir tests fail if GOEXPERIMENT=cgocheck2 is set. Fix this by
skipping these tests.
Change-Id: I58d4ef0cceb86bcf93220b4a44de9b9dc4879b16
Reviewed-on: https://go-review.googlesource.com/c/go/+/499675
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
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>
