A receiver expression for a type with parameters may be an IndexExpr
or IndexListExpr in addition to an Ident or StarExpr. Add cases to
recvString to account for the new types.
Add tests that compare the fields of Func, and the fields of Type that
hold Funcs. These fields weren't previously tested.
Change-Id: Ia2cef51c85113422e0c5745c77dddcd53507ee51
Reviewed-on: https://go-review.googlesource.com/c/go/+/375095
Trust: Jonathan Amsterdam <jba@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change the Test function to use sub-tests for each doc mode and
package.
This will allow more fine-grained test execution.
Change-Id: Ie3dda5791bda2781a60776886dd39fd18e670e24
Reviewed-on: https://go-review.googlesource.com/c/go/+/375094
Trust: Jonathan Amsterdam <jba@google.com>
Run-TryBot: Jonathan Amsterdam <jba@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Go 1.16 renamed the iOS port from darwin/arm64 to ios/arm64 and
darwin/arm64 was repurposed for the macOS ARM64 port (see
https://golang.org/doc/go1.16#darwin).
Change tests to only use GOOS=ios to detect special cases for iOS and
stop treating darwin/arm64 as iOS.
Change-Id: I6a19f16fa9ec159ab1386aeb8fe912585e457171
Reviewed-on: https://go-review.googlesource.com/c/go/+/374399
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Go 1.16 renamed the iOS port from darwin/arm64 to ios/arm64 and
darwin/arm64 was repurposed for the macOS ARM64 port (see
https://golang.org/doc/go1.16#darwin).
TestMkdirAllWithSymlink ought to run on darwin/arm64, so enable it on
that platform.
For #45696
Change-Id: I2cad6b1dfddf215e6b6cd262bbd22251f48f3d8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/373359
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
It appears that GCC before version 10 doesn't report file/line
location for asan errors.
Change-Id: I03ee24180ba365636596aa2384961df7ce6ed71f
Reviewed-on: https://go-review.googlesource.com/c/go/+/374874
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Change-Id: Ic05c641bda3cc8f5292921c9b0c0d3df34f3bc48
Reviewed-on: https://go-review.googlesource.com/c/go/+/374794
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
The current -asan option does not print where the error occurred. The
reason is that the current implementation calls incorrect asan runtime
functions, which do not pass sp and pc where asan runtime functions are
called, and report the stack trace from the native code. But asan runtime
functions are called from cgo on a separated stack, so it cannot dump the
Go stack trace correctly.
The correct asan runtime function we should call is __asan_report_error,
which will pass sp and pc, and report where the error occurred correctly.
This patch fixes this issue.
Add the test cases.
Fixes#50362
Change-Id: I12ee1d46c7ae069ddef3d23f2fe86e112db60045
Reviewed-on: https://go-review.googlesource.com/c/go/+/374395
Trust: Fannie Zhang <Fannie.Zhang@arm.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The riscv64 Hifive Unmatched is the only platform that
failed on testcase TestAnalyzeAnnotations occasionally
after CL 332954 had merged. The failure happens when
ticks per second (freq) is over 1e12 which causing the timestamps
of two events are same.
There are 2 reasons causing big frequency:
1. RDCYCLE is HART based according to the riscv manual which makes
negative ticks delta
2. negative float64 -> uint64 is undefined and "lucky" negative float
is too big to handle for trace
For #46737
Change-Id: I1f3c1ac31aae249969000c719c32aaf5a66d29a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/373034
Trust: Zhuo Meng <mzh@golangcn.org>
Run-TryBot: Zhuo Meng <mzh@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
For #47694
For #48052
Change-Id: I136be9b498033309d876099aae16bad330555416
Reviewed-on: https://go-review.googlesource.com/c/go/+/373774
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
We added a workaround in runtime/race. This should not be
necessary now.
Updates #49138.
Change-Id: Ia2010e4acc95c4ddf5f463ab2919401d893c0bac
Reviewed-on: https://go-review.googlesource.com/c/go/+/374314
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
For #47694
Sorry about that! I guess the autocompleter in VSCode auto-closed the paragraph and I didn't notice.
Change-Id: I1e834e47deb708cd5285d26201a442305f8c3b24
GitHub-Last-Rev: ab88731551
GitHub-Pull-Request: golang/go#50305
Reviewed-on: https://go-review.googlesource.com/c/go/+/374014
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
In c-archive mode, when we turn off profiling, we restore the
previous handler for SIGPROF, and ignore SIGPROF signals if no
handler was installed. So if a pending signal lands after we
remove the Go signal handler, it will not kill the program.
In the current code there is a small window, where we can still
receive signals but we are set to not handling the signal. If a
signal lands in this window (possibly on another thread), it will
see that we are not handling this signal and no previous handler
installed, and kill the program. To avoid this race, we set the
previous handler to SIG_IGN (ignoring the signal) when turning on
profiling. So when turning off profiling we'll ignore the signal
even if a stray signal lands in the small window.
Fixes#43828.
Change-Id: I304bc85a93ca0e63b0c0d8e902b097bfdc8e3f1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/374074
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This test works on FreeBSD since CL 165801 was submitted.
Updates #19093
Change-Id: I45ffeb403c1de4385cdb21b9647f21976061e1ea
Reviewed-on: https://go-review.googlesource.com/c/go/+/373358
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For #47694
Change-Id: I9f4838100741d3ba13e9374e70466fa405c6e4d2
Reviewed-on: https://go-review.googlesource.com/c/go/+/372634
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
The links to this example were using an underscore separator
instead of a hyphen, and incorrect casing.
Fixes#50279
Change-Id: I35d76a8a78cd708b7505ff1a70f7dacddaf43efd
Reviewed-on: https://go-review.googlesource.com/c/go/+/373514
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
The test checks RUNTIME_TESTING_SHORT, whereas the test runner
actually set RUNTIME_TEST_SHORT. Check the correct one.
Updates #32023.
Change-Id: Ie8ab00e1f5b8c02112a9aa1ee0e56028185c8a44
Reviewed-on: https://go-review.googlesource.com/c/go/+/373614
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is a pretty straight port of the fuzz test at https://github.com/inetaf/netaddr.
The MarshalText methods of netip.Addr and net.IP, the Is* methods of netip.Addr
and net.IP and the MarshalText and String methods of netip.Addr are also
checked to ensure that they behave the same way.
Fixes#49367
Change-Id: I44abb01f2a7af45f39597992a1fc7ff0305728fa
GitHub-Last-Rev: c2323b0ae1
GitHub-Pull-Request: golang/go#50108
Reviewed-on: https://go-review.googlesource.com/c/go/+/371055
Trust: Matt Layher <mdlayher@gmail.com>
Trust: Katie Hockman <katie@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Fixes#50256
Change-Id: I2327a0b28f8173c801ed2946bec8083967667027
Reviewed-on: https://go-review.googlesource.com/c/go/+/373314
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This is similar to CL 207350, for RISCV64.
May fix#50263.
Updates #35470.
Change-Id: I0d39e195e8254d65fa1aca1cdf1fc553aa8b7cba
Reviewed-on: https://go-review.googlesource.com/c/go/+/373434
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This is a port of CL 372674 from types2 to go/types with
minor adjustments for error handling.
For #49602.
Change-Id: I726081325a2ff2d5690d11ddc8a830bbcbd8ab33
Reviewed-on: https://go-review.googlesource.com/c/go/+/372954
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
When building/using plugins on darwin, we need to use flat
namespace so the same symbol from the main executable and the
plugin can be resolved to the same address. Apparently, when using
flat namespace the dynamic linker can hang at forkExec when
resolving a lazy binding. Work around it by forcing early bindings.
Fixes#38824.
Change-Id: I983aa0a0960b15bf3f7871382e8231ee244655f4
Reviewed-on: https://go-review.googlesource.com/c/go/+/372798
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
For #47694
Change-Id: I9af871a4a45b002e72629904011aac8f076617f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/372974
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The new description matches the implementation (CL 370774).
Also, in the section on type constraints, use "defines" instead of
"determines" because the constraint interface defines the type set
which is precisely the set of acceptable type arguments.
For #49482.
Change-Id: I6f30f49100e8ba8bec0a0f1b450f88cae54312eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/372874
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
For #49602.
Change-Id: I0d3ff8f087dffb3409918494147fd1dceff7514d
Reviewed-on: https://go-review.googlesource.com/c/go/+/372694
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The "someTimeout" constant in the net test is “just to test that
net.Conn implementations don't explode when their SetFooDeadline
methods are called”. It was set to 10 seconds, which is short enough
that it could actually matter on some platforms.
Since the point of the constant is just to make sure methods don't
explode, we should set it to be at least a couple of orders of
magnitude longer than the test: then it is guaranteed not to have any
unintended side-effects.
Fixes#50227
Change-Id: If97ae7bef5e7f16b336d09ccc37f5ea2ea7e70b3
Reviewed-on: https://go-review.googlesource.com/c/go/+/372796
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The parser cannot distinguish a type parameter list of the form
[P *T ] or
[P (T)]
where T is not a type literal from an array length specification
P*T (product) or P(T) (constant-valued function call) and thus
interprets these forms as the start of array types.
This ambiguity must be resolved explicitly by placing *T inside
an interface, adding a trailing comma, or by leaving parentheses
away where possible.
This CL adjusts the parser such that these forms are
interpreted as (the beginning) of type parameter lists
if the token after P*T or P(T) is a comma, or if T is
a type literal.
This CL also adjusts the printer to print a comma if
necessary to avoid this ambiguity, and adds additional
printer tests.
Fixes#49482
Change-Id: I36328e2a7d9439c39ba0349837c445542549e84e
Reviewed-on: https://go-review.googlesource.com/c/go/+/370774
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
We have code that intends to avoid escaping the package path for
built-in packages. But it is hard to determine which packages are
built-in from a general rule, and we really only want to avoid escaping
for the "go.shape" package (since that gives ugly shape type names). So,
fix the code to only avoid escaping the package path specifically for
the "go.shape" package.
Fixes#50200
Change-Id: Ibaedd7690b99a173007c608c5dfa783ef82b326d
Reviewed-on: https://go-review.googlesource.com/c/go/+/372934
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
When a user has showSignature=true set in their Git config and the
commit in question has a signature, the git-show command will output
information about that signature. When this happens, the logic that
tries to parsing a timestamp from the git-show output chokes on this
signature information and the build stamping fails. This change prevents
commit signature information from being displayed even if
showSignature=true, preventing this issue.
Change-Id: I98d0a6fdd1e90dd1b91e0394713b6eb286a69d1a
GitHub-Last-Rev: 610706e23e
GitHub-Pull-Request: golang/go#49790
Reviewed-on: https://go-review.googlesource.com/c/go/+/367034
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Also check that executables exist immediately after building them
in parallel tests.
The parallel tests in this package occasionally fail with
"no such file or directory", implying that either the build
command failed to actually write out the binary or something
concurrently deleted it.
This is purely a shot in the dark, but I'm hoping that perhaps
the stderr output from one of these commands will shed some
light on the underlying failure mode.
For #49693
Change-Id: I2e768190c56053550879b89a3ac88c027d4741dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/369034
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
It is observed to be flaky on the only openbsd/arm builder.
Skipping on that platform until someone can investigate.
For #50218
Change-Id: Id3a6dc12b93b3cec67870d8d81bd608c4589c952
Reviewed-on: https://go-review.googlesource.com/c/go/+/372794
Trust: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
