Adds helper functions for users working with other systems which
represent time in milliseconds or microseconds since the Unix epoch.
Fixes#44196
Change-Id: Ibc4490b52ddec94ebd0c692cb7b52a33e4536759
Reviewed-on: https://go-review.googlesource.com/c/go/+/293349
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Emmanuel Odeke <emmanuel@orijtech.com>
TryBot-Result: Go Bot <gobot@golang.org>
Under certain circumstances, the existing rules for bit operations can
produce code that writes beyond its intended bounds. For example,
consider the following code:
func repro(b []byte, addr, bit int32) {
_ = b[3]
v := uint32(b[0]) | uint32(b[1])<<8 | uint32(b[2])<<16 | uint32(b[3])<<24 | 1<<(bit&31)
b[0] = byte(v)
b[1] = byte(v >> 8)
b[2] = byte(v >> 16)
b[3] = byte(v >> 24)
}
Roughly speaking:
1. The expression `1 << (bit & 31)` is rewritten into `(SHLL 1 bit)`
2. The expression `uint32(b[0]) | uint32(b[1])<<8 | uint32(b[2])<<16 |
uint32(b[3])<<24` is rewritten into `(MOVLload &b[0])`
3. The statements `b[0] = byte(v) ... b[3] = byte(v >> 24)` are
rewritten into `(MOVLstore &b[0], v)`
4. `(ORL (SHLL 1, bit) (MOVLload &b[0]))` is rewritten into
`(BTSL (MOVLload &b[0]) bit)`. This is a valid transformation because
the destination is a register: in this case, the bit offset is masked
by the number of bits in the destination register. This is identical
to the masking performed by `SHL`.
5. `(MOVLstore &b[0] (BTSL (MOVLload &b[0]) bit))` is rewritten into
`(BTSLmodify &b[0] bit)`. This is an invalid transformation because
the destination is memory: in this case, the bit offset is not
masked, and the chosen instruction may write outside its intended
32-bit location.
These changes fix the invalid rewrite performed in step (5) by
explicitly maksing the bit offset operand to `BT(S|R|C)(L|Q)modify`. In
the example above, the adjusted rules produce
`(BTSLmodify &b[0] (ANDLconst [31] bit))` in step (5).
These changes also add several new rules to rewrite bit sets, toggles,
and clears that are rooted at `(OR|XOR|AND)(L|Q)modify` operators into
appropriate `BT(S|R|C)(L|Q)modify` operators. These rules catch cases
where `MOV(L|Q)store ((OR|XOR|AND)(L|Q) ...)` is rewritten to
`(OR|XOR|AND)(L|Q)modify` before the `(OR|XOR|AND)(L|Q) ...` can be
rewritten to `BT(S|R|C)(L|Q) ...`.
Overall, compilecmp reports small improvements in code size on
darwin/amd64 when the changes to the compiler itself are exlcuded:
file before after Δ %
runtime.s 536464 536412 -52 -0.010%
bytes.s 32629 32593 -36 -0.110%
strings.s 44565 44529 -36 -0.081%
os/signal.s 7967 7959 -8 -0.100%
cmd/vendor/golang.org/x/sys/unix.s 81686 81678 -8 -0.010%
math/big.s 188235 188253 +18 +0.010%
cmd/link/internal/loader.s 89295 89056 -239 -0.268%
cmd/link/internal/ld.s 633551 633232 -319 -0.050%
cmd/link/internal/arm.s 18934 18928 -6 -0.032%
cmd/link/internal/arm64.s 31814 31801 -13 -0.041%
cmd/link/internal/riscv64.s 7347 7345 -2 -0.027%
cmd/compile/internal/ssa.s 4029173 4033066 +3893 +0.097%
total 21298280 21301472 +3192 +0.015%
Change-Id: I2e560548b515865129e1724e150e30540e9d29ce
GitHub-Last-Rev: 9a42bd29a5
GitHub-Pull-Request: golang/go#45242
Reviewed-on: https://go-review.googlesource.com/c/go/+/304869
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
The cmd/pprof package currently uses golang.org/x/crypto/ssh/terminal
which - as of CL 258003 - is merely a wrapper around golang.org/x/term.
Thus, drop the dependency on golang.org/x/crypto/ssh/terminal and use
golang.org/x/term directly.
Change-Id: Ib15f1f110c338b9dba4a91a873171948ae6298a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/304691
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Pull out the tranformation part of the typechecking functions for:
- selector expressions (OXDOT)
- calls to builtin functions (which go through the typechecker loop
twice, once for the call and once for each different kind of
builtin).
Some of the transformation functions create new nodes that should have
the same type as the original node. For consistency, now each of the
transformation functions requires that the node passed in has its type
and typecheck flag set. If the transformation function replaces or adds
new nodes, it will set the type and typecheck flag for those new nodes.
As usual, passes all the gotests, even with -G=3 enabled.
Change-Id: Ic48b0ce5f58425f4a358afa78315bfc7c28066c4
Reviewed-on: https://go-review.googlesource.com/c/go/+/304729
Trust: Dan Scales <danscales@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Implements FileInfoToDirEntry which converts an fs.FileInfo to fs.DirEntry.
Fixes#42387.
Change-Id: Ie723b6ed583c6c5ecf22bbe64e3b6496f5114254
Reviewed-on: https://go-review.googlesource.com/c/go/+/293649
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
On ARM64, (external) linker generated trampoline may clobber R16
and R17. In CL 183842 we change Duff's devices not to use those
registers. However, this is not enough. The register allocator
also needs to know that these registers may be clobbered in any
calls that don't follow the standard Go calling convention. This
include Duff's devices and the write barrier.
Fixes#32773, second attempt.
Change-Id: Ia52a891d9bbb8515c927617dd53aee5af5bd9aa4
Reviewed-on: https://go-review.googlesource.com/c/go/+/184437
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Meng Zhuo <mzh@golangcn.org>
As suggested by Bryan in CL 249759, remove the forwarding aliases in
cmd/cover and use the symbols from golang.org/x/tools directly.
cmd/cover is not an importable package, so it is fine to remove these
exported symbols.
Change-Id: I887c5e9349f2dbe4c90be57f708412b844e18081
Reviewed-on: https://go-review.googlesource.com/c/go/+/304690
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
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>
