Because we rename type parameters to avoid problems with self-recursive
function calls, there's no need anymore for special (and hard to follow)
logic for pointer-identical types. If they are identical, we have a
match. Simplify the code accordingly.
Change-Id: I2e1838a43e90fa4abfae3ab9e4f7da6463508966
Reviewed-on: https://go-review.googlesource.com/c/go/+/471018
Reviewed-by: 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>
Auto-Submit: Robert Griesemer <gri@google.com>
Adjust imports but no other code changes otherwise.
Change-Id: Iffbd7f9b1786676a42b68d91ee6cc7df07d776bf
Reviewed-on: https://go-review.googlesource.com/c/go/+/471015
Reviewed-by: Robert Griesemer <gri@google.com>
Reviewed-by: Robert Findley <rfindley@google.com>
Auto-Submit: Robert Griesemer <gri@google.com>
Run-TryBot: Robert Griesemer <gri@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The primary change is that type inference now always reports
an error if a unification step fails (rather than ignoring that
case, see infer2.go). This brings the implementation closely to
the description in #58650; but the implementation is more direct
by always maintaining a simple (type parameter => type) mapping.
To make this work, there are two small but subtle changes in the
unifier:
1) When deciding whether to proceed with the underlying type of
a defined type, we also use the underlying type if the other
type is a basic type (switch from !hasName(x) to isTypeLit(x)
in unifier.go). This makes the case in issue #53650 work out.
See the comment in the code for a detailed explanation of this
change.
2) When we unify against an unbound type parameter, we always
proceed with its core type (if any).
Again, see the comment in the code for a detailed explanation
of this change.
The remaining changes are comment and test adjustments. Because
the new logic now results in failing type inference where it
succeeded before or vice versa, and then instatiation or parameter
passing failed, a handful of error messages changed.
As desired, we still have the same number of errors for the same
programs.
Also, because type inference now produces different results, we
cannot easily compare against infer1 anymore (also infer1 won't
work correctly anymore due to the changes in the unifier). This
comparison (together with infer1) is now disabled.
Because some errors and their positions have changed, we need a
slightly larger error position tolerance for types2 (which produces
less accurate error positions than go/types). Hence the change in
types2/check_test.go.
Finally, because type inference is now slightly more relaxed,
issue #51139 doesn't produce a type unification failure anymore
for a (previously correctly) inferred type argument.
Fixes#51139.
Change-Id: Id796eea42f1b706a248843ad855d9d429d077bd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/470916
Reviewed-by: 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>
Auto-Submit: Robert Griesemer <gri@google.com>
The assertion here was to make sure the newly constructed and
typechecked expression selected the same receiver-qualified method,
but in the case of anonymous receiver types we can actually end up
with separate types.Field instances corresponding to each types.Type
instance. In that case, the assertion spuriously failed.
The fix here is to relax and assertion and just compare the method's
name and type (including receiver type).
Fixes#58563.
Change-Id: I67d51ddb020e6ed52671473c93fc08f283a40886
Reviewed-on: https://go-review.googlesource.com/c/go/+/471676
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Since we can't gate tests on the macOS version on normal machines,
restrict TestIssue51759 to only run on builders, where we have a way to
do this.
Change-Id: I70fc83c587689b499b6a38864973a77bb3e52596
Reviewed-on: https://go-review.googlesource.com/c/go/+/472619
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
The -T flag actually means the start address of text symbols, not
the text sections, which may differ by the header size. It has
been behaving like this since at least 2009. Make it clear in the
documentation.
Also remove the -D flag from the doc. The flag doesn't actually
exist in the implementation.
Fixes#58727.
Change-Id: Ic5b7e93adca3f1ff9f0de33dbb6089f46cdf4738
Reviewed-on: https://go-review.googlesource.com/c/go/+/472356
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Convert TestUnknownAuthorityError to use subtests, avoiding continuing
the test after an unrecoverable failure.
Skip TestIssue51759 on pre-macOS 11 builders, which don't enforce the
behavior we were testing for.
Updates #58791Fixes#58812
Change-Id: I4e3e5bc371aa139d38052184c8232f8cb564138f
Reviewed-on: https://go-review.googlesource.com/c/go/+/472496
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Roland Shoemaker <roland@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
The existing runtime/coverage API set includes a "ClearCounters()"
function that zeros out the counter values in a running process so as
enable capturing of a coverage profile from a specific execution time
segment. Calling this function is only permitted if the program is
built with "-covermode=atomic", due (in part) to concerns about
processors with relaxed memory models in which normal stores can be
reordered.
In the bug in question, a test that stresses a different set of
counter-related APIs was hitting an invalid counter segment when
running on a machine (ppc64) which does indeed have a relaxed memory
consistency model.
From a post-mortem examination of the counter array for the harness
from the ppc64 test run, it was clear that the thread reading values
from the counter array was seeing the sort of inconsistency that could
result from stores being reordered (specifically the prolog
"packageID" and "number-of-counters" stores).
To preclude the possibility of future similar problems, this patch
extends the "atomic mode only" restriction from ClearCounters to the
other APIs that deal with counters (WriteCounters, WriteCountersDir).
Fixes#56197.
Change-Id: Idb85d67a84d69ead508e0902ab46ab4dc82af466
Reviewed-on: https://go-review.googlesource.com/c/go/+/463695
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
All amd64 OSes already make use of the NOFRAME flag wherever is
required, so we can remove the frameless nosplit functions heuristic
code path.
Updates #58378
Change-Id: I966970693ba07f8c66da0aca83c23caad7cbbfe5
Reviewed-on: https://go-review.googlesource.com/c/go/+/466458
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
A build constraint reports whether the test binary was compiled with
cgo enabled, but that doesn't necessarily imply that cgo can be used
in the environment in which the test binary is run.
In particular, cross-compiled builders (such as Android) may compile
the test binaries on the host with CGO enabled but not provide a C
toolchain on the device that runs the test.
For #58775.
Change-Id: Ibf2f44c9e956cd3fa898c3de67af4449e8ef2dd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/472215
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
This CL marks some plan9 assembly functions as NOFRAME to avoid
relying on the implicit amd64 NOFRAME heuristic, where NOSPLIT functions
without stack were also marked as NOFRAME.
Updates #58378
Change-Id: Ic8c9ab5c1a0897bebc6c1419ddc903a7492a1b0a
Reviewed-on: https://go-review.googlesource.com/c/go/+/466457
TryBot-Bypass: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This CL removes some NOFRAME flags on Windows assembly files
for several reasons:
- windows/386 does not use a frame pointer
- Leaf frameless functions already skip the frame pointer
- Some non-leaf functions do not contain enough dragons to justify
not using the frame pointer
Updates #58378
Change-Id: I31e71bf7f769e1957a4adba91778da5af66ce1e4
Reviewed-on: https://go-review.googlesource.com/c/go/+/466835
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Quim Muntal <quimmuntal@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
On Windows, replace tests which rely on a root that expired last year.
On Darwin fix an test which wasn't testing the expected behavior, and
fix the behavior which was broken.
Fixes#58791
Change-Id: I771175b9e123b8bb0e4efdf58cc2bb93aa94fbae
Reviewed-on: https://go-review.googlesource.com/c/go/+/472295
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Roland Shoemaker <roland@golang.org>
In the past, we planned to implement asynchronous preemption using
precise register pointer maps. In this strategy, conversions between
unsafe.Pointer and uintptr would need to be marked as unsafe points,
as if a pointer value is temporarily converted to uintptr (and not
live otherwise), the GC would not be able to see it when scanning
the stack (and registers).
But now we actually implemented asynchronous preemption with inner
frame conservative scan. So even if a pointer value lives as an
integer the GC can still see it. There is no need to mark the
conversion as unsafe points. This allows more places to be
preempted, as well as for debugger to inject a call.
Fixes#57719.
Change-Id: I375ab820d8d74d122b565cf72ecc7cdb225dbc01
Reviewed-on: https://go-review.googlesource.com/c/go/+/461696
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
This was noticed while testing hash-search debugging
of the loopvar experiment.
The change is incomplete -- it only addresses local
variables, not parameters. The code to log/search
changes in loop variable semantics depends on this,
so that will be the test.
Change-Id: I0f84ab7696c6cab43486242cacaba6a0bfc45475
Reviewed-on: https://go-review.googlesource.com/c/go/+/464315
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: David Chase <drchase@google.com>
After CL 436435 chain, the only case left where we create an ONAME node
with nil Func is interface method from imported package.
Change-Id: I9d9144916d01712283f2b116973f88965715fea3
Reviewed-on: https://go-review.googlesource.com/c/go/+/468816
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Some folks working on the Go project may have a go.work file in
GOROOT/src in order to test changes in x repos. 'go test cmd/go'
should not fail if that is the case.
For #58767.
Change-Id: I0e57b15fb1d3e4abc4903c177434626c9f125cae
Reviewed-on: https://go-review.googlesource.com/c/go/+/471601
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: David Chase <drchase@google.com>
Workspace mode is specifically for working with modules;
it doesn't make sense in GOPATH mode.
This also fixes a panic in (*modload.MainModuleSet).GoVersion
when go.work is present in GOPATH mode.
For #58767.
Change-Id: Ic6924352afb486fecc18e009e6b517f078e81094
Reviewed-on: https://go-review.googlesource.com/c/go/+/471600
Auto-Submit: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
No test case because the problem can only happen for invalid data. Let
the fuzzer find cases like this.
For #47653Fixes#58754
Change-Id: Ic3ef58b204b946f8bff80310d4c8dfcbb2939a1c
Reviewed-on: https://go-review.googlesource.com/c/go/+/471678
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Because "CopyN" will read one more byte, which will cause us
to overflow when calling "Reader.ReadForm(math.MaxInt64)".
So we should check if the parameter exceeds "math.MaxInt64"
to avoid returning no data.
Fixes#58384.
Change-Id: I30088ce6468176b21e4a9a0b8b6080f2986dda23
Reviewed-on: https://go-review.googlesource.com/c/go/+/467557
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Run-TryBot: hopehook <hopehook@golangcn.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The compiler used to generate ONAME node with nil Func for them, so the
inliner can still analyze, but could not generate inline call for them
anyway.
CL 436961 attempts to create ONAME node with non-nil Func, causing the
inliner complains about missing body reader.
This CL makes inliner recognize type eq/hash functions, and mark them as
non-inlineable. Longer term, if we do want to inline these functions, we
need to integrate the code generation into Unified IR frontend.
Updates #58572
Change-Id: Icdd4dda03711929faa3d48fe2d9886568471f0bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/469017
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Go 1.19 introduced doc links (https://go.dev/doc/comment#doclinks).
It will be convenient when we can directly jump to the suggested
function when the original function is deprecated.
Change-Id: I6172a5265f3b47aefec53179bca60f9904606b3f
GitHub-Last-Rev: b2aa85bf1b
GitHub-Pull-Request: golang/go#58779
Reviewed-on: https://go-review.googlesource.com/c/go/+/471915
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
testGo is currently only configured if testenv.HasGoBuild returns
true, which implies that a complete toolchain is present.
Since setting up testGo now only uses the test binary itself, it does
not actually require 'go build', but fixing that will be a bit more
involved. For now, just skip the test when it isn't set up.
Fixes#58775.
Change-Id: I6487b47b44c87aa139ae11cfa44ce6f0f5f84bd4
Reviewed-on: https://go-review.googlesource.com/c/go/+/472095
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Alan Donovan <adonovan@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
As background, Power10 adds prefixed load, store, and add immediate
instructions which encode 34b signed displacements. Likewise, they
also give the option to compute addresses against the PC. This enables
using simpler PC relative (PC-rel) relocations instead of maintaining a
dedicated pointer (the TOC) to the code/data blob on PPC64/linux.
Similary, there are several Go opcodes where it can be advantageous to
use prefixed instructions instead of composite sequences like oris/ori/add
to implement "MOVD <big const>, Rx" or "ADD <big const>, Rx, Ry", or
large offset load/stores like "MOVD <big constant>(Rx), Ry" using the same
framework which dynamically configures optab.
When selecting prefixed instruction forms, the assembler must also use
new relocations. These new relocations are always PC-rel by design, thus
code assembled as such has no implicit requirement to maintain a TOC
pointer when assembling shared objects. Thus, we can safely avoid
situations where some Go objects use a TOC pointer, and some do not. This
greatly simplifies linking Go objects. For more details about the
challenges of linking TOC and PC-rel compiled code, see the PPC64 ELFv2
ABI.
The TOC pointer in R2 is still maintained in those build configurations
which previously required it (e.x buildmode=pie). However, Go code built
with PC-rel relocations does not require the TOC pointer. A future
change could remove the overhead of maintaining a TOC pointer in those
build configurations.
This is enabled only for power10/ppc64le/linux.
A final noteworthy difference between the prefixed and regular load/store
instruction forms is the removal of the DS/DQ form restrictions. That
is, the immediate operand does not need to be aligned.
Updates #44549
Change-Id: If59c216d203c3eed963bfa08855e21771e6ed669
Reviewed-on: https://go-review.googlesource.com/c/go/+/355150
Reviewed-by: Michael Pratt <mpratt@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Paul Murphy <murp@ibm.com>
No test case because the problem can only happen for invalid data. Let
the fuzzer find cases like this.
For #47653Fixes#58755
Change-Id: I5b95a21f47ec306ad90cd6221f0566c6f8b6c3ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/471835
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
According to the ARM Architecture Reference Manual, LDADDx-like
instructions can take rt as zr when the encode A bit is 0. They
are used by the alias STADDx-like instructions. The current
assembler adds incorrect constraints for them, which is rt can't
be zr when field.enc A is 0. This patch removes it.
Add test cases.
Reported by Matt Horsnell <matt.horsnell@arm.com>
The reference:
https://developer.arm.com/documentation/ddi0602/2022-12/Base-Instructions
Change-Id: Ia2487a5e3900e32994fc14edaf03deeb245e70c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/462295
Reviewed-by: Matt Horsnell <matthew.horsnell@gmail.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: Ica8d5e5799a4de532764ae86cdb623508d3a8e18
GitHub-Last-Rev: 3e97cca9de
GitHub-Pull-Request: golang/go#58689
Reviewed-on: https://go-review.googlesource.com/c/go/+/471021
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
On Arm64, all 32-bit instructions will ignore the upper 32 bits and
clear them to zero for the result. No need to do an unsign extend before
a 32 bit op.
This CL removes the redundant unsign extension only for the existing
32-bit opcodes, and also omits the sign extension when the upper bit of
the result can be predicted.
Fixes#42162
Change-Id: I61e6670bfb8982572430e67a4fa61134a3ea240a
CustomizedGitHooks: yes
Reviewed-on: https://go-review.googlesource.com/c/go/+/427454
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Eric Fang <eric.fang@arm.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Eric Fang <eric.fang@arm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Now that the bare minimum change to make the run.go test runner into
a normal go test is done, there remain many opportunities to simplify,
modernize and generally clean up the test code.
Of all the opportunities available, this change tries to fit somewhere
between doing "not enough" and "way too much". This ends up including:
• replace verbose flag with testing.Verbose()
• replace custom temporary directory creation, removal, -keep flag
with testing.T.TempDir
• replace custom code to find the go command with testenv.GoToolPath
• replace many instances of "t.err = err; return" with "return err",
or with t.Fatal when it's clearly a test infrastructure error
• replace reliance on changing working directory to GOROOT/test to
computing and using absolute paths
• replace uses of log.Fatal with t.Fatal
• replace uses of deprecated ioutil package with their replacements
• add some missing error checks, use more idiomatic identifier names
For #56844.
Change-Id: I5b301bb83a8e5b64cf211d7f2f4b14d38d48fea0
Reviewed-on: https://go-review.googlesource.com/c/go/+/466155
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
As motivated on the issue, we want to move the functionality of the
run.go program to happen via a normal go test. Each .go test case in
the GOROOT/test directory gets a subtest, and cmd/go's support for
parallel test execution replaces run.go's own implementation thereof.
The goal of this change is to have fairly minimal and readable diff
while making an atomic changeover. The working directory is modified
during the test execution to be GOROOT/test as it was with run.go,
and most of the test struct and its run method are kept unchanged.
The next CL in the stack applies further simplifications and cleanups
that become viable.
There's no noticeable difference in test execution time: it takes around
60-80 seconds both before and after on my machine. Test caching, which
the previous runner lacked, can shorten the time significantly.
For #37486.
Fixes#56844.
Change-Id: I209619dc9d90e7529624e49c01efeadfbeb5c9ae
Reviewed-on: https://go-review.googlesource.com/c/go/+/463276
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The misc/cgo/life and misc/cgo/stdio tests started out as fairly simple
test cases when they were added, but the machinery to execute them has
grown in complexity over the years.
They currently reuse the test/run.go runner and its "run" action without
needing much of the additional flexibility that said runner implements.
Given that runner isn't well documented, it makes it harder to see that
ultimately these tests just do 'go run' on a few test programs and check
that the output matches a golden file.
Maybe these test cases should move out of misc to be near similar tests,
or the machinery to execute them can made available in a package that is
easier and safer to reuse. I'd rather not block the refactor of the test
directory runner on that, so for now rewrite these to be self-contained.
Also delete misc/cgo/stdio/testdata/run.out which has no effect on the
test. It was seemingly accidentally kept behind during the refactor in
CL 6220049.
For #56844.
Change-Id: I5e2f542824925092cdddb03b44b6295a4136ccb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/465755
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
When inlining functions that contain function literals, we need to be
careful about position information. The OCLOSURE node should use the
inline-adjusted position, but the ODCLFUNC and its body should use the
original positions.
However, the same problem can arise with certain generic constructs,
which require the compiler to synthesize function literals to insert
dictionary arguments.
go.dev/cl/425395 fixed the issue with user-written function literals
in a somewhat kludgy way; this CL extends the same solution to
synthetic function literals.
This is all quite subtle and the solutions aren't terribly robust, so
longer term it's probably desirable to revisit how we track inlining
context for positions. But for now, this seems to be the least bad
solution, esp. for backporting to 1.20.
Updates #54625.
Fixes#58513.
Change-Id: Icc43a70dbb11a0e665cbc9e6a64ef274ad8253d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/468415
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Fixes#56843
Change-Id: I3cb3e8397499cd8c57a3edddd45f38c510519b36
Reviewed-on: https://go-review.googlesource.com/c/go/+/451997
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Nicolas Hillegeer <aktau@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Rob Pike <r@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
goos: linux
goarch: amd64
pkg: net/http
cpu: DO-Premium-Intel
│ old │ new │
│ sec/op │ sec/op vs base │
HexEscapeNonASCII-4 469.6n ± 20% 371.1n ± 9% -20.98% (p=0.000 n=10)
│ old │ new │
│ B/op │ B/op vs base │
HexEscapeNonASCII-4 192.0 ± 0% 192.0 ± 0% ~ (p=1.000 n=10) ¹
¹ all samples are equal
│ old │ new │
│ allocs/op │ allocs/op vs base │
HexEscapeNonASCII-4 2.000 ± 0% 2.000 ± 0% ~ (p=1.000 n=10) ¹
¹ all samples are equal
Change-Id: Ic8d2b3ddcf2cf724dec3f51a2aba205f2c6e4fe6
Reviewed-on: https://go-review.googlesource.com/c/go/+/425786
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Andy Pan <panjf2000@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Change-Id: I6cccac9295ab4a9bf7f7a33382a34f31b1c4a000
Reviewed-on: https://go-review.googlesource.com/c/go/+/471496
Auto-Submit: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Andy Pan <panjf2000@gmail.com>
mkalldocs.sh required a Unix shell, making it less accessible for
contributors on Windows. It also used a substantially different
codepath to regenerate the file than the one used to check the file
for staleness, making failures in TestDocsUpToDate more complex to
diagnose.
We can solve both of those problems by using the same technique as in
checkScriptReadme: use the test itself as the generator to update the
file. The test is already written in Go, the test binary already knows
how to mimic the 'go' command, and this approach brings the difference
between the test and the generator down to a single flag check.
Updates #26735.
Change-Id: I7c6f65cb0e0c29e334e38a45412e0a73c4d31d42
Reviewed-on: https://go-review.googlesource.com/c/go/+/468636
Reviewed-by: Alan Donovan <adonovan@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Bryan Mills <bcmills@google.com>
Auto-Submit: Bryan Mills <bcmills@google.com>
Some integer comparisons with 1 and -1 can be rewritten as comparisons
with 0. For example, x < 1 is equivalent to x <= 0. This is an
advantageous transformation on riscv64 because comparisons with zero
do not require a constant to be loaded into a register. Other
architectures will likely benefit too and the transformation is
relatively benign on architectures that do not benefit.
Change-Id: I2ce9821dd7605a660eb71d76e83a61f9bae1bf25
Reviewed-on: https://go-review.googlesource.com/c/go/+/350831
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Munday <mike.munday@lowrisc.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
