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>
Ensure that user ConnState callbacks have completed before returning
from (*httptest.Server).Close.
Fixes: #37510Fixes: #37505Fixes: #45237
Change-Id: I8fe7baa089fbe4f3836bf6ae9767c7b1270d1331
Reviewed-on: https://go-review.googlesource.com/c/go/+/304829
Trust: Damien Neil <dneil@google.com>
Run-TryBot: Damien Neil <dneil@google.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 makes the error handling in loadImport somewhat more uniform,
with no discernable effect on reported errors.
Noticed in CL 303869.
Updates #36087
Updates #38034
This somewhat simplifies the code, with no discernable effect on
Change-Id: I30521f658f264d6f99d1844d6701269bbb372246
Reviewed-on: https://go-review.googlesource.com/c/go/+/304069
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>
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>
Change-Id: I868eeb79edaba9e3afc1407ae18b89daf7e67037
Reviewed-on: https://go-review.googlesource.com/c/go/+/304570
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This requires us to add a fake argument to issue36705.go so that the
test driver will build it with "go run" rather than "go tool compile".
Change-Id: Id08b97d898ee3e9d6c1fbb072a0a9317ed9faedd
Reviewed-on: https://go-review.googlesource.com/c/go/+/304569
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>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
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 ABI wrappers are used, we may end up with two functions
having the same name. On ELF we mangle the name with ABI. Do the
same for PE.
TODO: other platforms?
Change-Id: If89f214a6286bc28c062c1aa1bad78dc353a9231
Reviewed-on: https://go-review.googlesource.com/c/go/+/304432
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 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>
Remove more now-redundant code, methods, and types
associated with transition to register ABI.
Repaired some broken comments.
Tested on link-register architectures (arm64, ppc64le)
Updates #40724.
Change-Id: Ie8433f6d38ec4a1d9705f22dcb596f267d81f203
Reviewed-on: https://go-review.googlesource.com/c/go/+/304189
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Corrected typo/thinko.
We should keep the test for this, but it doesn't run yet because of reflection
as far as I know (but I am not testing w/ GOEXPERIMENT).
See https://github.com/golang/go/issues/44816#issuecomment-805297295
Updates #40724
Updates #44816
Change-Id: Ia12d0d4db00a8ec7174e72de460173876bd17874
Reviewed-on: https://go-review.googlesource.com/c/go/+/304233
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>
Change-Id: Icfa204761045b72a8ea173fd55eddf1f0e58d819
Reviewed-on: https://go-review.googlesource.com/c/go/+/304253
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>
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>
