All other test files in the runtime/race package have race build
tag, except syso_test.go. The test is only relevant if the race
detector is supported. So apply the build tag.
Fixes#46931.
Change-Id: Icdb94214d3821b4ccf61133412ef39b4d7cc7691
Reviewed-on: https://go-review.googlesource.com/c/go/+/331050
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Elias Naur <mail@eliasnaur.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
TestCheck/issues.src was failing after running
rm -r $(go env GOROOT)/pkg/*/cmd
as the builders do when building binary releases.
For users who write programs that depend on go/types, it should be
reasonable for end users to run the tests for go/types as part of 'go
test all', and those tests should pass even if they installed Go from
a binary release.
The test case in issues.src was importing cmd/compile/internal/syntax
in order to check the reported package name.
I tried to fix the problem by having the test import from source
instead of from export data. Unfortunately, that changed the behavior
under test: the go/types.Package.Imports reports (and is documented to
report) a different set of imported packages when loading from source
as compared to when loading from export data.
For this particular test, after CL 313035 that difference resulted in
go/types treating the "syntax" name as ambiguous when importing from
source, because a transitive dependency on "regexp/syntax" is found
when loading from source but omitted when loading from export data.
The simple fix to make the package unambiguous again is to adapt the
test to import regexp/syntax directly. That not only makes the package
unambiguous with all importers, but also avoids depending on a
cmd-internal package that cannot be loaded from export data in binary
distributions of the Go toolchain.
For #43232
Change-Id: Iba45a680ea20d26daa86ac538fd8f1938e8b73ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/330431
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
TestStdlib was failing after running
rm -r $(go env GOROOT)/pkg/*/cmd
as the builders do when building binary releases.¹
For users who write programs that depend on go/types, it should be
reasonable to run the tests for go/types as part of 'go test all', and
those tests should pass even if they installed Go from a binary
release.
I had originally drafted this as a fallback to import from source only
if the affected packages can't be imported by the default export-data
importer. Unfortunately, I realized that we don't currently have a
builder that tests the actual release (#46900), so it is quite likely
that the fallback path would bit-rot and produce unexpected test
regressions.
So instead, we now unconditionally import from source in TestStdlib.
That makes the test substantially slower (~15s instead of ~5s on my
workstation), but with less risk of regression, and TestStdlib is
skipped in short mode already so short-mode test time is unaffected.
If we change the builders to test the actual release configuration, we
can consider restoring the faster path when export data is available.
¹df58bbac08/cmd/release/release.go (L533-L545)
For #43232
Change-Id: I764ec56926c104053bb2ef23cf258c8f0f773290
Reviewed-on: https://go-review.googlesource.com/c/go/+/330252
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
ncgocall was stored per M, runtime.NumCgoCall lost the counter when a M die.
Fixes#46789
Change-Id: I85831fbb2713f4c30d1800d07e1f47aa0031970e
GitHub-Last-Rev: cbc15fa870
GitHub-Pull-Request: golang/go#46842
Reviewed-on: https://go-review.googlesource.com/c/go/+/329729
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Alexander Rakoczy <alex@golang.org>
CL 313035 had a bug, initializing pkgPathMap by walking the imported
package being considered rather than check.pkg.
Fix this, and enhance our tests to exercise this bug as well as other
edge cases.
Also fix error assertions in issues.src to not use quotation marks
inside the error regexp. The check tests only matched the error regexp
up to the first quotation mark.
Fixes#46905
Change-Id: I6aa8eae4bec6495006a5c03fc063db0d66b44cd6
Reviewed-on: https://go-review.googlesource.com/c/go/+/330629
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
Change-Id: Ie26b9060630e2e774ac23d8492eaaf785bfca6b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/330709
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
In Go 1.12, we added a heuristic to 'go mod tidy' to resolve packages
by adding replaced-but-not-required modules before falling back to
searching for modules from the network. Unfortunately, that heuristic
fails when the replaced version is already lower than the selected
version: adding such a module to the build list doesn't change the
selected version of that module, and so it doesn't make progress
toward resolving the missing package.
Fixes#46659
Change-Id: I75e2387d5290e769f6b0fa1231dcc4605db68597
Reviewed-on: https://go-review.googlesource.com/c/go/+/330432
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The helper function claims that dialing a closed port should be
"nearly instantaneous", but that is empirically not the case on
OpenBSD or Windows. The tests do not appear to be particularly
sensitive to the exact upper bound otherwise, so let's just
remove the arbitrary latency assumption.
Fixes#46884
Change-Id: If00c9fdc3063da6aaf60d365d4a2ee2c94dc6df1
Reviewed-on: https://go-review.googlesource.com/c/go/+/330250
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Fixes#46883
Updates CL 267017
Change-Id: I15c307bfb0aaa2877a148d32527681f79df1a650
Reviewed-on: https://go-review.googlesource.com/c/go/+/330289
Reviewed-by: Kevin Burke <kev@inburke.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
When we are looking for a dependency cycle involving a specific
package, we need to keep track of visited packages in order to avoid
repeatedly traversing a cycle that does not involve that package.
If we're keeping track of all visited packages anyway, we're already
spending O(N) memory on the traversal, so we may as well use
breadth-first search. That not only keeps the bookkeeping simple, but
also guarantees that we will find a shortest path (rather than a
completely arbitrary one).
Fixes#45863
Change-Id: I810c7337857e42dcb83630abbdea75021554be45
Reviewed-on: https://go-review.googlesource.com/c/go/+/330430
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
The real net code uses subtle heuristics to transform a domain name
to its absolute form. Since lookupPTR isn't checking that
transformation specifically, it should use the real code instead of
using a different heuristic.
Fixes#46882
Change-Id: I503357e0f62059c37c359cd54b44d343c7d5ab2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/330249
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The test successfully runs on currently supported versions (6.8 and
6.9) of openbsd.
Fixes#25877
Change-Id: I2694f08c5596b486453c2ac829f17b8bc455f828
Reviewed-on: https://go-review.googlesource.com/c/go/+/329732
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Tobias Klauser <tobias.klauser@gmail.com>
The build.Context ToolTags value is set based on the set of enabled
experiments, which in turn depends on GOARCH. Before this CL the set
of experiments was being set based on GOARCH in the environment.
That is normally fine, but fails with cmd/go when somebody has run
"go env -w GOARCH=val"; in that case cmd/go changes its GOARCH value
after initialization. The new GOARCH value was affect the set of
enabled experiments, which can affect the ToolTags value. With this
CL, we update ToolTags in cmd/go based on the GOARCH value it is using.
This is a pretty ugly fix. We should do something cleaner for 1.18.
Fixes#46815
Change-Id: Ie9416781a168248813c3da8afdc257acdd3fef7e
Reviewed-on: https://go-review.googlesource.com/c/go/+/329930
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>
Add unsafe.Add and unsafe.Slice to the list of built-in functions
which are not permitted in statement context. The compiler and
type checker already enforce this restriction, this just fixes
a documentation oversight.
For #19367.
For #40481.
Change-Id: Iabc63a8db048eaf40a5f5b5573fdf00b79d54119
Reviewed-on: https://go-review.googlesource.com/c/go/+/329925
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Rob Pike <r@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
When type checking t[_], where t is a type name, it was possible to leak
an error message related to generics. Fix this by guarding on
typeparams.Enabled.
In order to test this fix, we need to be able to run the new go/types
test only if type parameters are disabled. Introduce the .go1 test data
suffix (similar to .go2) to control this behavior.
Originally found via fuzzing, though the test case was manually
simplified.
Updates #46404
Change-Id: Ib1e2c27cf974c2a5ca5b9d6d01b84a30ba4d583b
Reviewed-on: https://go-review.googlesource.com/c/go/+/329793
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
This documentation remained from the original dev.typeparams merge. This
flag no longer exists.
Change-Id: Ic9a82071c512614dc1382780d69ef13253fca21d
Reviewed-on: https://go-review.googlesource.com/c/go/+/329792
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
To be consistent with Go 1.16, and to preserve as much information in
the AST as possible, parse an ast.IndexExpr with BadExpr Index for the
invalid expression a[].
A go/types test had to be adjusted to account for an additional error
resulting from this change.
We don't have a lot of test coverage for parser error recovery, so
rather than write an ad-hoc test for this issue, add a new go/types test
that checks that the indexed operand is used.
Updates #46403
Change-Id: I21e6ff4179746aaa50e530d4091fded450e69824
Reviewed-on: https://go-review.googlesource.com/c/go/+/329791
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
For #46366
Change-Id: I8417e6e4dbb8cb56ff7afc16893a01b7bb938217
Reviewed-on: https://go-review.googlesource.com/c/go/+/329529
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
CL 328770 should be sufficient to fix the specific failure in the
report, but when attempting to reproduce it I noticed a related
failure mode, triggered by the environment variables set in
src/run.bash.
The failure mode is currently masked on the Go project builders due to
the lack of any 'longtest' builder running as a non-root user
(#10719).
It is also masked from Go contributors running 'run.bash' locally
because 'run.bash' does not actually run all of the tests unless
GO_TEST_SHORT=0 is set in the environment (#29266, #46054).
Fixes#46695
Change-Id: I272c09dae462734590dce59b3d3c5b6d3f733c92
Reviewed-on: https://go-review.googlesource.com/c/go/+/328771
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
TestAllDependencies is attempting to check that the modules in GOROOT
satisfy certain properties; it should not modify those modules itself.
The “quick” part of the test checks that vendored packages are present
and complete, without constructing a parallel GOROOT. It shouldn't
resolve new dependencies or change formatting in any way.
The longer version of the test already constructs a parallel GOROOT
and tidies the modules within it. That part of the test will flag any
modifications needed to the go.mod and go.sum files, without modifying
the original GOROOT.
From what I can tell, the failure mode in #46695 is caused by running
the test on a module rooted in $GOROOT proper. There is no such module
in the mainline Go repo, but it may have been introduced in the fork
and could also be introduced by stray edits in contributor CLs. It
should be diagnosed clearly.
For #46695
Change-Id: I62b90ccbd54cb3e3b413017021c952a7b1d455e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/328770
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Change-Id: I2d2c02eec4ac6eca218fa5334d32650c1620692c
Reviewed-on: https://go-review.googlesource.com/c/go/+/329689
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
CL 308611 optimized parseIdentifier for ASCII, but inadvertently skipped
error handling for 0 bytes. Don't take the optimized path when
encountering 0.
Fixes#46855
Change-Id: Ic584e077eb74c012611fefa20eb71ca09c81b3c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/329790
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
The issue go#46783 correctly diagnosed the context timeout
caused an intermittent failure when the context was canceled
prior to the BeginTx call. However due to the asynchronous nature
of canceling a Tx through a context on fast systems, the tx.Prepare
also succeeded. On slower systems or if a time.Sleep was inserted
between the BeginTx and Prepare, the Prepare would fail.
Resolve this by moving the context cancel after the Prepare.
This will still trigger the deadlock which I tested locally.
In addition, I interspersed multiple time.Sleep calls and the
test still functioned.
Fixes#46852
Change-Id: I9cbf90d3c12b2555493a37799738772b615ae39d
Reviewed-on: https://go-review.googlesource.com/c/go/+/329830
Run-TryBot: Daniel Theophanes <kardianos@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
This patch reinstates a fix for PowerPC with regard to making VDSO calls
while receiving a signal, and subsequently crashing. The crash happens
because certain VDSO calls can modify the r30 register, which is where g
is stored. This change was reverted for PowerPC because r30 is supposed
to be a non-volatile register. This is true, but that only makes a
guarantee across function calls, but not "within" a function call. This
patch was seemingly fine before because the Linux kernel still had hand
rolled assembly VDSO function calls, however with a recent change to C
function calls it seems the compiler used can generate instructions
which temporarily clobber r30. This means that when we receive a signal
during one of these calls the value of r30 will not be the g as the
runtime expects, causing a segfault.
You can see from this assembly dump how the register is clobbered during
the call:
(the following is from a 5.13rc2 kernel)
```
Dump of assembler code for function __cvdso_clock_gettime_data:
0x00007ffff7ff0700 <+0>: cmplwi r4,15
0x00007ffff7ff0704 <+4>: bgt 0x7ffff7ff07f0 <__cvdso_clock_gettime_data+240>
0x00007ffff7ff0708 <+8>: li r9,1
0x00007ffff7ff070c <+12>: slw r9,r9,r4
0x00007ffff7ff0710 <+16>: andi. r10,r9,2179
0x00007ffff7ff0714 <+20>: beq 0x7ffff7ff0810 <__cvdso_clock_gettime_data+272>
0x00007ffff7ff0718 <+24>: rldicr r10,r4,4,59
0x00007ffff7ff071c <+28>: lis r9,32767
0x00007ffff7ff0720 <+32>: std r30,-16(r1)
0x00007ffff7ff0724 <+36>: std r31,-8(r1)
0x00007ffff7ff0728 <+40>: add r6,r3,r10
0x00007ffff7ff072c <+44>: ori r4,r9,65535
0x00007ffff7ff0730 <+48>: lwz r8,0(r3)
0x00007ffff7ff0734 <+52>: andi. r9,r8,1
0x00007ffff7ff0738 <+56>: bne 0x7ffff7ff07d0 <__cvdso_clock_gettime_data+208>
0x00007ffff7ff073c <+60>: lwsync
0x00007ffff7ff0740 <+64>: mftb r30 <---- RIGHT HERE
=> 0x00007ffff7ff0744 <+68>: ld r12,40(r6)
```
What I believe is happening is that the kernel changed the PowerPC VDSO
calls to use standard C calls instead of using hand rolled assembly. The
hand rolled assembly calls never touched r30, so this change was safe to
roll back. That does not seem to be the case anymore as on the 5.13rc2
kernel the compiler *is* generating assembly which modifies r30, making
this change again unsafe and causing a crash when the program receives a
signal during these calls (which will happen often due to async
preempt). This change happened here:
https://lwn.net/ml/linux-kernel/235e5571959cfa89ced081d7e838ed5ff38447d2.1601365870.git.christophe.leroy@csgroup.eu/.
I realize this was reverted due to unexplained hangs in PowerPC
builders, but I think we should reinstate this change and investigate
those issues separately:
f4ca3c1e0aFixes#46803
Change-Id: Ib18d7bbfc80a1a9cb558f0098878d41081324b52
GitHub-Last-Rev: c3002bcfca
GitHub-Pull-Request: golang/go#46767
Reviewed-on: https://go-review.googlesource.com/c/go/+/328110
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Apparently, TestMorestack is still flaky on darwin/arm64 builder
after CL 307730. Let it spend more time in copying the stack.
With this CL, on my Apple M1 machine it passes reliably in short
mode for 1000 runs, and reliably gets 250+ samples in the 5-second
interval in long mode.
May fix#46755.
Change-Id: I07b36c1cf63ad35f7820e1f8e837e29376a37b2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/329869
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
Documents the mode added in CL 306149 to skip object resolution.
Fixes#46298
Change-Id: I6a14aaa00790f9f7e4e4ba17033355f5e878d74b
Reviewed-on: https://go-review.googlesource.com/c/go/+/329009
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
We've observed some occasional os-arch specific timeouts
in signal.TestSignalTrace(). While the main purpose of a
short timeout is to ensure the passing tests complete
quickly, the unexpected failure path can tolerate waiting
longer (the test is not intended to test how slow or
overloaded the OS is at the time it is run).
Fixes#46736
Change-Id: Ib392fc6ce485a919612784ca88ed76c30f4898e2
Reviewed-on: https://go-review.googlesource.com/c/go/+/329502
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>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
The new RGBA64At method is equivalent to the existing At method (and the
new SetRGBA64 method is equivalent to the existing Set method in the
image/draw package), but they can avoid allocations from converting
concrete color types to the color.Color interface type.
Also update api/go1.17.txt and doc/go1.17.html
Fixes#44808
Change-Id: I8671f3144512b1200fa373840ed6729a5d61bc35
Reviewed-on: https://go-review.googlesource.com/c/go/+/311129
Trust: Nigel Tao <nigeltao@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Rob Pike <r@golang.org>
I wrote code that relied on this API, but I misunderstood the original
description of the "more" result. As a consequence, my code always
stopped one frame early.
This CL expands the documentation to be more explicit and specifically
call out my confusion (i.e., that the "more" result indicates whether
the *next* Next call will return a valid Frame, and not whether this
call did).
Change-Id: If135f8f8c05425073d45377c4179e4f79e6bd6ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/329389
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Matthew Dempsky <mdempsky@google.com>
Otherwise, in c-archive or c-shared mode, there is the chance of
getting a SIGPROF just after the signal handler is removed but before
profiling is disabled, in which case the program will die.
Fixes#46498
Change-Id: I5492beef45fec9fb9a7f58724356d6aedaf799ac
Reviewed-on: https://go-review.googlesource.com/c/go/+/329290
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
runtime/pprof has a more complete list of platforms with broken
profiling than I used in cmd/pprof in https://golang.org/cl/325809.
Duplicate that list in cmd/pprof and clean it up a bit in runtime/pprof
for easier reference.
Change-Id: I8f2580aac223de9b73cfff4355f49916f7b76493
Reviewed-on: https://go-review.googlesource.com/c/go/+/329149
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
I left a TODO to decide whether to add 'go get' arguments as indirect
(as we have in the past), or to make them direct. I considered both
options, and decided to keep the indirect default because it is easier
(and less invasive) for users to fix.
Updates #45979
Change-Id: I1f23a88db59a01bdd9e6fe48c2fffc8a3b55145a
Reviewed-on: https://go-review.googlesource.com/c/go/+/328971
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>
https://golang.org/cl/318049 replaced driver.ObjFile.Base with
driver.ObjFile.ObjAddr. We don't support shared libraries, so these
should be no-op, but CL 318049 accidentally failed to account from the
change in no-op behavior from returning 0 to passing through addr.
Fixes#46636
Change-Id: Iab82224c7db722a1e257ec6e305218e22114d0a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/325809
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Only use safe characters of the test name for the os.MkdirTemp pattern.
This currently includes the alphanumeric characters and ASCII
punctuation characters known not to interact with globs.
Fixes#46624
Change-Id: I402c34775b943fed9b97963c52f79245cc16dc1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/326010
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Only methods that modify the time take pointer receivers;
IsDST does not modify it and therefore should not.
For #42102 and #46688.
Change-Id: I4721ef7f4d7572236ae6e4d99a459b9ffb11999e
Reviewed-on: https://go-review.googlesource.com/c/go/+/326789
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
I needed to also update TestScript/mod_sumdb_golang.
It had been relying on 'go list -mod=mod' to add both the go.mod and
go.sum entries for the named package, but when 'go get' actually adds
all of the needed dependencies, lazy loading kicks in and 'go list'
doesn't end up needing the checksums for go.mod files.
We didn't detect the skew before because the 'go list' command was
(unexpectedly) also adding the missing dependencies, which triggered a
deep scan of the complete module graph.
For #45979
Change-Id: Ica917dee22c83ffa71c6ad0f2e189f911b73edf4
Reviewed-on: https://go-review.googlesource.com/c/go/+/328231
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>
If someone sees "in [0,n)" it might look like a typo.
Saying "in the half-open interval [0,n)" will give people
something to search the web for (half-open interval).
Change-Id: I3c343f0a7171891e106e709ca77ab9db5daa5c84
Reviewed-on: https://go-review.googlesource.com/c/go/+/328210
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
On ARM64, instruction like "MOVD (R1)(R2*1), R3" is accepted and
assembles correctly with Go 1.16, but errors out on tip with
"arm64 doesn't support scaled register format", since CL 289589.
"MOVD (R1)(R2), R3" is the preferred form. But the *1 form works
before and assembles correctly. Keep supporting it.
Fixes#46766.
Change-Id: I0f7fd71fa87ea698919a936b6c68aa5a91afd486
Reviewed-on: https://go-review.googlesource.com/c/go/+/328229
Trust: Cherry Mui <cherryyz@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: eric fang <eric.fang@arm.com>
For typed vs un-typed operation, the compiler do the conversion
un-conditionally, so if the operation is invalid, the error report is
pointed to the conversion, instead of the invalid operation itself.
To fix this, only do the conversion when the operations are valid
for both types.
Fixes#46749
Change-Id: Ib71c7bcd3ed5454e6df55b6a8db4e0f189259ba7
Reviewed-on: https://go-review.googlesource.com/c/go/+/328050
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
