Bryan C. Mills [Wed, 16 Feb 2022 15:24:42 +0000 (10:24 -0500)]
[release-branch.go1.18] os: eliminate arbitrary sleep in Kill tests
The test spawned a subprocess that arbitrarily slept for one second.
However, on some platforms, longer than one second may elapse between
starting the subprocess and sending the termination signal.
Instead, the subprocess now closes stdout and reads stdin until EOF,
eliminating the need for an arbitrary duration. (If the parent test
times out, the stdin pipe will break, so the subprocess still won't
leak forever.)
This also makes the test much faster in the typical case: since it
uses synchronization instead of sleeping, it can run as quickly as the
host OS can start and kill the process.
Updates #44131.
Change-Id: I9753571438380dc14fc3531efdaea84578a47fae
Reviewed-on: https://go-review.googlesource.com/c/go/+/386174
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>
(cherry picked from commit eaf040502b763a6f00dced35e4173c2ce90eb52f)
Reviewed-on: https://go-review.googlesource.com/c/go/+/386196
Trust: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Heschi Kreinick <heschi@google.com>
Bryan C. Mills [Wed, 16 Feb 2022 17:33:17 +0000 (12:33 -0500)]
cmd/go/internal/modload: set errors for packages with invalid import paths
Prior to CL 339170, relative errors in module mode resulted in a
base.Fatalf from the module loader, which caused unrecoverable errors
from 'go list -e' but successfully rejected relative imports (which
were never intended to work in module mode in the first place).
After that CL, the base.Fatalf is no longer present, but some errors
that had triggered that base.Fatalf were no longer diagnosed at all:
the module loader left them for the package loader to report, and the
package loader assumed that the module loader would report them.
Since the module loader already knows that the paths are invalid,
it now reports those errors itself.
Michael Matloob [Tue, 15 Feb 2022 19:27:13 +0000 (14:27 -0500)]
cmd/go: set go.work path using GOWORK, and remove -workfile flag
This change removes the -workfile flag and allows the go.work file path
to be set using GOWORK (which was previously read-only). This removes
the potential discrepancy and confusion between the flag and environment
variable.
GOWORK will still return the actual path of the go.work file found if it
is set to '' or 'auto'. GOWORK will return 'off' if it is set to 'off'.
For #45713
Fixes #51171
Change-Id: I72eed65d47c63c81433f2b54158d514daeaa1ab3
Reviewed-on: https://go-review.googlesource.com/c/go/+/385995
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com>
Ian Lance Taylor [Thu, 27 Jan 2022 00:19:47 +0000 (16:19 -0800)]
time: document that Parse truncates to nanosecond precision
For #48685
Fixes #50806
Change-Id: Ie8be40e5794c0998538890a651ef8ec92cb72d3a
Reviewed-on: https://go-review.googlesource.com/c/go/+/381155
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Paul Jolly <paul@myitcv.org.uk> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Ian Lance Taylor [Tue, 15 Feb 2022 21:40:49 +0000 (13:40 -0800)]
net: increase maximum accepted DNS packet to 1232 bytes
The existing value of 512 bytes as is specified by RFC 1035.
However, the WSL resolver reportedly sends larger packets without
setting the truncation bit, which breaks using the Go resolver.
For 1.18 and backports, just increase the accepted packet size.
This is what GNU glibc does (they use 65536 bytes).
For 1.19 we plan to use EDNS to set the accepted packet size.
That will give us more time to test whether that causes any problems.
No test because I'm not sure how to write one and it wouldn't really
be useful anyhow.
Fixes #6464
Fixes #21160
Fixes #44135
Fixes #51127
For #51153
Change-Id: I0243f274a06e010ebb714e138a65386086aecf17
Reviewed-on: https://go-review.googlesource.com/c/go/+/386015
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Damien Neil <dneil@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Ian Lance Taylor [Tue, 15 Feb 2022 21:38:57 +0000 (13:38 -0800)]
Revert "net: send EDNS(0) packet length in DNS query"
This reverts https://go.dev/cl/385035. For 1.18 we will use a simple
change to increase the accepted DNS packet size, to handle what appear
to be broken resolvers that don't honor the 512 byte limit. For 1.19
we will restore CL 385035 to make a proper EDNS request, so that it
has more testing time before it goes out in a release.
For #6464
For #21160
For #44135
For #51127
For #51153
Change-Id: Ie4a0eb85ca0a6a73bee5cd4cfc6b7d2a15ef259f
Reviewed-on: https://go-review.googlesource.com/c/go/+/386014
Trust: Ian Lance Taylor <iant@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Damien Neil <dneil@google.com>
alex.schade [Tue, 15 Feb 2022 15:35:03 +0000 (15:35 +0000)]
cmd/go/internal/modfetch: avoid leaking a lockedfile.File in case of write errors
The go modules download command has a method called hashZip which checks the
hash of a zipped directory versus an expected value, and then writes it out
to a file. In the event that the write operation is not successful, we do
not close the file, leading to it being leaked. This could happen if the
user runs out of disk space, causing the underlying OS write command to
return an error. Ultimately, this led to a panic in lockfile.OpenFile which
was invoked from a finalizer garbage collecting the leaked file. The result
was a stack trace that didn't show the call stack from where the write
operation actually failed.
Michael Pratt [Fri, 4 Feb 2022 22:15:28 +0000 (17:15 -0500)]
runtime, syscall: reimplement AllThreadsSyscall using only signals.
In issue 50113, we see that a thread blocked in a system call can result
in a hang of AllThreadsSyscall. To resolve this, we must send a signal
to these threads to knock them out of the system call long enough to run
the per-thread syscall.
Stepping back, if we need to send signals anyway, it should be possible
to implement this entire mechanism on top of signals. This CL does so,
vastly simplifying the mechanism, both as a direct result of
newly-unnecessary code as well as some ancillary simplifications to make
things simpler to follow.
Major changes:
* The rest of the mechanism is moved to os_linux.go, with fields in mOS
instead of m itself.
* 'Fixup' fields and functions are renamed to 'perThreadSyscall' so they
are more precise about their purpose.
* Rather than getting passed a closure, doAllThreadsSyscall takes the
syscall number and arguments. This avoids a lot of hairy behavior:
* The closure may potentially only be live in fields in the M,
hidden from the GC. Not necessary with no closure.
* The need to loan out the race context. A direct RawSyscall6 call
does not require any race context.
* The closure previously conditionally panicked in strange
locations, like a signal handler. Now we simply throw.
* All manual fixup synchronization with mPark, sysmon, templateThread,
sigqueue, etc is gone. The core approach is much simpler:
doAllThreadsSyscall sends a signal to every thread in allm, which
executes the system call from the signal handler. We use (SIGRTMIN +
1), aka SIGSETXID, the same signal used by glibc for this purpose. As
such, we are careful to only handle this signal on non-cgo binaries.
Synchronization with thread creation is a key part of this CL. The
comment near the top of doAllThreadsSyscall describes the required
synchronization semantics and how they are achieved.
Note that current use of allocmLock protects the state mutations of allm
that are also protected by sched.lock. allocmLock is used instead of
sched.lock simply to avoid holding sched.lock for so long.
Fixes #50113
Change-Id: Ic7ea856dc66cf711731540a54996e08fc986ce84
Reviewed-on: https://go-review.googlesource.com/c/go/+/383434 Reviewed-by: Austin Clements <austin@google.com>
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Michael Pratt [Tue, 8 Feb 2022 21:45:14 +0000 (16:45 -0500)]
runtime/internal/syscall: new package for linux
Add a generic syscall package for use by the runtime. Eventually we'd
like to clean up system calls in the runtime to use more code generation
and be moved out of the main runtime package.
The implementations of the assembly functions are based on copies of
syscall.RawSyscall6, modified slightly for more consistency between
arches. e.g., renamed trap to num, always set syscall num register
first.
For now, this package is just the bare minimum needed for
doAllThreadsSyscall to make an arbitrary syscall.
For #51087.
For #50113.
Change-Id: Ibecb5e6303279ce15286759e1cd6a2ddc52f7c72
Reviewed-on: https://go-review.googlesource.com/c/go/+/383999
Trust: Michael Pratt <mpratt@google.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
Michael Pratt [Mon, 7 Feb 2022 22:02:57 +0000 (17:02 -0500)]
runtime: move doAllThreadsSyscall to os_linux.go
syscall_runtime_doAllThreadsSyscall is only used on Linux. In
preparation of a follow-up CL that will modify the function to use other
Linux-only functions, move it to os_linux.go with no changes.
For #50113.
Change-Id: I348b6130038603aa0a917be1f1debbca5a5a073f
Reviewed-on: https://go-review.googlesource.com/c/go/+/383996
Trust: Michael Pratt <mpratt@google.com> Reviewed-by: Andrew G. Morgan <agm@google.com> Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Robert Findley [Mon, 14 Feb 2022 03:48:39 +0000 (22:48 -0500)]
go/parser, go/printer: fix parsing of ambiguous type parameter lists
This is a port of CL 370774 to go/parser and go/printer. It is adjusted
for the slightly different factoring of parameter list parsing and
printing in go/parser and go/printer.
For #49482
Change-Id: I1c5b1facddbfcb7f7b2be356c817fc7e608223f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/385575
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Keith Randall [Mon, 14 Feb 2022 22:57:55 +0000 (14:57 -0800)]
cmd/compile: drop column info when line number saturates
When line number saturates, we can end up getting non-monotonic
position info, because the start of the next line after line=lineMax,col=2
is line=lineMax,col=1.
Instead, if line==lineMax, make the column always 0 (no column info).
If the line number is wrong, having column info probably isn't that helpful.
Fixes #51193
Change-Id: If3d90472691b1f6163654f3505e2cb98467f2383
Reviewed-on: https://go-review.googlesource.com/c/go/+/385795
Trust: Keith Randall <khr@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
Bryan C. Mills [Fri, 11 Feb 2022 21:49:51 +0000 (16:49 -0500)]
net: in TestNotTemporaryRead, do not assume that a dialed connection has been accepted
Previously, TestNotTemporaryRead issued the Read on the Accept side of
the connection, and Closed the Dial side. It appears that on some
platforms, Dial may return before the connection has been Accepted,
and if that connection is immediately closed with no bytes written and
SO_LINGER set to 0, the connection may no longer even exist by the
time Accept returns, causing Accept to block indefinitely until the
Listener is closed.
If we were to just swap the directions, we would have an analogous
problem: Accept could accept the connection and close it before the
client even finishes dialing, causing Dial (instead of Read) to return
the ECONNRESET error.
Here, we take a middle path: we Accept and Dial the connection
concurrently, but wait until both the Accept and the Dial have
returned (indicating that the connection is completely established and
won't vanish from the accept queue) before resetting the connection.
Damien Neil [Wed, 19 Jan 2022 19:26:46 +0000 (11:26 -0800)]
net/http: deflake request-not-written path
When we receive an error writing the first byte of a request to a
reused connection, we retry the request on a new connection. Remove
a flaky path which could cause the request to not be retried if
persistConn.roundTrip reads the error caused by closing the connection
before it reads the write error that caused the connection to be
closed.
Robert Findley [Mon, 14 Feb 2022 01:27:55 +0000 (20:27 -0500)]
go/types, types2: no need to revert tparam renaming in inference results
This is a follow up to CL 385494. In early patch sets of that CL,
renamed type parameters were substituted in arguments, which meant that
they could leak into the inference results. However, we subsequently
realized that we could instead substitute in the signature parameters.
In this case it is not possible for the substituted type parameters to
appear in the resulting type arguments, so there is no need to
un-substitute.
Change-Id: I4da45b0b8d7ad809d0ddfa7061ae5f6f07895540
Reviewed-on: https://go-review.googlesource.com/c/go/+/385574
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Robert Griesemer [Fri, 11 Feb 2022 20:18:33 +0000 (12:18 -0800)]
spec: highlight missing prose for easier review, fixed a few sections
The (temporary) highlights will make it easier to review the spec
in formatted form as opposed to html text.
Added a missing rule about the use of adjusted core types for
constraint type inference.
Adjusted rule for invalid embedding of interface types.
Change-Id: Ie573068d2307b66c937e803c486724175415b9c6
Reviewed-on: https://go-review.googlesource.com/c/go/+/385535
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Type inference uses type parameter pointer identity to keep track of the
correspondence between type parameters and type arguments. However, this
technique can misidentify type parameters that are used in explicit type
arguments or function arguments, as in the recursive instantiation
below:
func f[P *Q, Q any](p P, q Q) {
f[P]
}
In this example, the fact that the P used in the instantation f[P] has
the same pointer identity as the P we are trying to solve for via
unification is coincidental: there is nothing special about recursive
calls that should cause them to conflate the identity of type arguments
with type parameters. To put it another way: any such self-recursive
call is equivalent to a mutually recursive call, which does not run into
any problems of type parameter identity. For example, the following code
is equivalent to the code above.
We can turn the first example into the second example by renaming type
parameters in the original signature to give them a new identity. This
CL does this for self-recursive instantiations.
Fixes #51158
Fixes #48656
Updates #48619
Change-Id: I54fe37f2a79c9d98950cf6a3602335db2896dc24
Reviewed-on: https://go-review.googlesource.com/c/go/+/385494
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Ian Lance Taylor [Sat, 12 Feb 2022 22:16:51 +0000 (14:16 -0800)]
test: add notinheap test that caused a gofrontend crash
Change-Id: Ie949f2131845f9f9292caff798f6933648779122
Reviewed-on: https://go-review.googlesource.com/c/go/+/385434
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
type inference attempts to unify the types of m1 and m2. This leads
to the unification attempt of M1 and M2. The result is that the type
argument for M1 is inferred to be M2. Since there is no furter function
argument to use, constraint type inference attempts to infer the type
for K1 which is still missing. Constraint type inference (inferB in
the trace below) compares the inferred type for M1 (i.e., M2) against
map[K1]int. M2 is bound to f2, not f1; with the existing algorithm
that means M2 is simply a named type without further information.
Unification fails and with that type inference, and the type checker
reports an error.
With this change, when attempting to unify M2 with map[K1]int,
rather than failing, the unifier now considers the core type of
M2 which is map[K2]int. This leads to the unification of K1 and
K2; so type inference successfully infers M2 for M1 and K2 for K1.
The fix for this issue was provided by Rob Findley in CL 380375;
this change is a copy of that fix with some additional changes:
- Constraint type inference doesn't simply use a type parameter's
core type. Instead, if the type parameter type set consists of
a single, possibly named type, it uses that type. Factor out the
existing code into a new function adjCoreType. This change is not
strictly needed but makes it easier to think about the code.
- Tracing code is added for debugging type inference. All tracing
code is guarded with the flag traceEnabled which is set to false
by default.
- The change to the unification algorithm is guarded with the flag
enableCoreTypeUnification.
- The sprintf function has a new type switch case for lists of
type parameters. This is used for tracing output (and was also
missing for a panic that was printing type parameter lists).
Fixes #50755.
Change-Id: Ie50c8f4540fcd446a71b07e2b451a95339b530ce
Reviewed-on: https://go-review.googlesource.com/c/go/+/385354
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>
Ian Lance Taylor [Fri, 11 Feb 2022 04:09:07 +0000 (20:09 -0800)]
net: send EDNS(0) packet length in DNS query
We used to only accept up to 512 bytes in a DNS packet, per RFC 1035.
Increase the size we accept to 1232 bytes, per https://dnsflagday.net/2020/,
and advertise that larger limit in a EDNS(0) OPT record.
Change-Id: I496a294e9a8015de4161cbc1825b0dc5b4e9f5d8
Reviewed-on: https://go-review.googlesource.com/c/go/+/385035
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Robert Griesemer [Fri, 11 Feb 2022 21:16:52 +0000 (13:16 -0800)]
go/types, types2: better error message for invalid array length
If an invalid array length is just an identifier, mention
"array length" so that it's clear this is an invalid array
declaration and not a (invalid) generic type declaration.
Fixes #51145.
Change-Id: I8878cbb6c7b1277fc0a9a014712ec8d55499c5c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/385255
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>
Cherry Mui [Mon, 7 Feb 2022 17:00:44 +0000 (12:00 -0500)]
cmd/compile, runtime: use unwrapped PC for goroutine creation tracing
With the switch to the register ABI, we now generate wrapper
functions for go statements in many cases. A new goroutine's start
PC now points to the wrapper function. This does not affect
execution, but the runtime tracer uses the start PC and the
function name as the name/label of that goroutine. If the start
function is a named function, using the name of the wrapper loses
that information. Furthur, the tracer's goroutine view groups
goroutines by start PC. For multiple go statements with the same
callee, they are grouped together. With the wrappers, which is
context-dependent as it is a closure, they are no longer grouped.
This CL fixes the problem by providing the underlying unwrapped
PC for tracing. The compiler emits metadata to link the unwrapped
PC to the wrapper function. And the runtime reads that metadata
and record that unwrapped PC for tracing.
(This doesn't work for shared buildmode. Unfortunate.)
TODO: is there a way to test?
Fixes #50622.
Change-Id: Iaa20e1b544111c0255eb0fc04427aab7a5e3b877
Reviewed-on: https://go-review.googlesource.com/c/go/+/384158
Trust: Cherry Mui <cherryyz@google.com> Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Bryan C. Mills [Fri, 11 Feb 2022 16:32:11 +0000 (11:32 -0500)]
runtime: skip TestSegv/SegvInCgo failures with "runtime: unknown pc"
This test has failed on four different builders in the past month.
Moreover, because every Go program depends on "runtime", it is likely
to be run any time a user runs 'go test all' in their own program.
Since the test is known to be flaky, let's skip it to avoid
introducing testing noise until someone has time to investigate. It
seems like we have enough samples in the builder logs to at least
start with.
Robert Griesemer [Fri, 11 Feb 2022 05:51:04 +0000 (21:51 -0800)]
spec: combine section on type parameters and type parameter lists
This change moves the relevant prose of the section on type parameters
into the section on type parameter lists and eliminates the former.
With this change, the section on types now exclusively describes all
Go composite types.
User-defined named types (defined types and type parameters) are
described with their declarations.
Change-Id: I3e421cd236e8801d31a4a81ff1e5ec9933e3ed20
Reviewed-on: https://go-review.googlesource.com/c/go/+/385037
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Fri, 11 Feb 2022 05:10:34 +0000 (21:10 -0800)]
spec: add a section on implementing an interface
Also, fixed several closing header tags and removed a duplicate "the".
(Thanks to @hopehook and Hossein Zolfi for pointing these out.)
Change-Id: I85a40ba44b8570a578bce8d211dcc5ea3901fb1e
Reviewed-on: https://go-review.googlesource.com/c/go/+/385036
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Fri, 11 Feb 2022 04:10:33 +0000 (20:10 -0800)]
spec: describe processing of function arguments for type inference more precisely
The outcome of type inference depends critically on when function
argument type inference stops processing arguments. Describe this
and explain an example with some detail.
Also: In the section on the built-in function delete, refer to the
value rather than the type of the second argument, as it may be an
untyped constant.
Change-Id: Ice7fbb33f985afe082380b8d37eaf763238a3818
Reviewed-on: https://go-review.googlesource.com/c/go/+/385034
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Kevin Burke [Fri, 11 Feb 2022 04:44:03 +0000 (20:44 -0800)]
doc: fix spelling error in link ID
Change-Id: I6de236442f213ab4b4f19ec881add4923d8bfd8d
Reviewed-on: https://go-review.googlesource.com/c/go/+/385054 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Kevin Burke <kevin@burke.dev>
Robert Griesemer [Fri, 11 Feb 2022 00:02:48 +0000 (16:02 -0800)]
spec: introduce notion of basic interface, misc. fine-tuning
A basic interface is a classical Go interface containing only
methods or embedding basic interfaces.
Use this to simplify rule about what interfaces may be used
where. The term "basic interface" will also be useful when
talking about various interfaces in general.
Fix rule restricting union terms: as it was written it also
excluded interface terms with non-empty method sets due to
embedded non-interface types with methods.
Split the large section on interfaces into three smaller
pieces by introducing section titles.
Change-Id: I142a4d5609eb48aaa0f7800b5b85c1d6c0703fcb
Reviewed-on: https://go-review.googlesource.com/c/go/+/384994
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>
Suvaditya Sur [Thu, 10 Feb 2022 06:26:55 +0000 (11:56 +0530)]
abi-internal: Fix typo in register assignment documentation
If register assignment fails, revert back the value to stack
Change-Id: I6f65092461ad4d793206a679a5fef1b560b387f0
Reviewed-on: https://go-review.googlesource.com/c/go/+/384455 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Ian Lance Taylor <iant@golang.org> Reviewed-by: Austin Clements <austin@google.com>
Robert Griesemer [Thu, 10 Feb 2022 01:36:51 +0000 (17:36 -0800)]
spec: move all sections describing type properties into one place
This change only shuffles sections for better organization; there
are no other changes except title and link adjustments.
Until now, the sections on underlying types and method sets were
immediately following the introduction of types. As it becomes
necessary to introduce the notion of a core type more centrally,
the natural place is immediately following the section on underlying
types. All together, these sections, immediately after the introduction
of types, would distract from purpose of the section on types, which
is to introduce the various types that Go offers.
The more natural place for the definition of underlying, core, and
specific types is the section on properties of types and values.
To accomplish this, the section on the structure of interfaces is
split into a section on core types and one on specific types, and
the various sections are reorganized appropriately.
The new organization of the section on types now simply introduces
all Go types as follows:
Michael Matloob [Tue, 8 Feb 2022 21:45:17 +0000 (16:45 -0500)]
cmd/go: mention go.work when local path outside modules in go.work
In workspace mode, if a user lists a package or patternthat's inside a
module that's not listed in go.work, mention that the package or pattern
is outside the modules listed in go.work so the user has a better idea
of how to fix the issue.
(Question: it's valid in those flows to add a pattern that points into
the module cache. Should we expand the error to say "package outside
modules listed in go.work file or contained in module cache"? That seems
clunky (and is the uncommon case) which is why I didn't do so in this
case, but it's possible)
Fixes #49632
Change-Id: I3f0ea1b2f566d52a8079b58593fcc5cc095e7a41
Reviewed-on: https://go-review.googlesource.com/c/go/+/384236
Trust: Michael Matloob <matloob@golang.org>
Run-TryBot: Michael Matloob <matloob@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Michael Anthony Knyszek [Tue, 8 Feb 2022 00:52:11 +0000 (00:52 +0000)]
runtime: make piController much more defensive about overflow
If something goes horribly wrong with the assumptions surrounding a
piController, its internal error state might accumulate in an unbounded
manner. In practice this means unexpected Inf and NaN values.
Avoid this by identifying cases where the error overflows and resetting
controller state.
In the scavenger, this case is much more likely. All that has to happen
is the proportional relationship between sleep time and estimated CPU
usage has to break down. Unfortunately because we're just measuring
monotonic time for all this, there are lots of ways it could happen,
especially in an oversubscribed system. In these cases, just fall back
on a conservative pace for scavenging and try to wait out the issue.
In the pacer I'm pretty sure this is impossible. Because we wire the
output of the controller to the input, the response is very directly
correlated, so it's impossible for the controller's core assumption to
break down.
While we're in the pacer, add more detail about why that controller is
even there, as well as its purpose.
Finally, let's be proactive about other sources of overflow, namely
overflow from a very large input value. This change adds a check after
the first few operations to detect overflow issues from the input,
specifically the multiplication.
No tests for the pacer because I was unable to actually break the
pacer's controller under a fuzzer, and no tests for the scavenger because
it is not really in a testable state.
However:
* This change includes a fuzz test for the piController.
* I broke out the scavenger code locally and fuzz tested it, confirming
that the patch eliminates the original failure mode.
* I tested that on a local heap-spike test, the scavenger continues
operating as expected under normal conditions.
Fixes #51061.
Change-Id: I02a01d2dbf0eb9d2a8a8e7274d4165c2b6a3415a
Reviewed-on: https://go-review.googlesource.com/c/go/+/383954 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Bryan C. Mills [Wed, 9 Feb 2022 16:04:01 +0000 (11:04 -0500)]
runtime/pprof: remove arbitrary sleeps in TestBlockProfile
The "block" helpers in TestBlockProfile previously slept for an
arbitrary duration and assumed that that duration was long enough for
the parent goroutine to have registered as blocking. However —
especially on slow or overloaded builders — the current arbitrary
duration is sometimes not quite long enough.
Rather than increasing the duration to a different arbitrary value
(which would make the test slower but not actually eliminate the
possibility of flakes!), we can use the runtime's own accounting to
detect when the goroutine is actually blocked: we obtain a goroutine
dump from the runtime, and assume that blocking has been registered in
the profile only if the runtime shows the test goroutine in the
appropriate blocked state.
That not only makes the test more reliable, but also makes it
significantly lower-latency when run on a fast machine.
Russ Cox [Wed, 2 Feb 2022 21:41:32 +0000 (16:41 -0500)]
regexp/syntax: reject very deeply nested regexps in Parse
The regexp code assumes it can recurse over the structure of
a regexp safely. Go's growable stacks make that reasonable
for all plausible regexps, but implausible ones can reach the
“infinite recursion?” stack limit.
This CL limits the depth of any parsed regexp to 1000.
That is, the depth of the parse tree is required to be ≤ 1000.
Regexps that require deeper parse trees will return ErrInternalError.
A future CL will change the error to ErrInvalidDepth,
but using ErrInternalError for now avoids introducing new API
in point releases when this is backported.
Fixes #51112.
Change-Id: I97d2cd82195946eb43a4ea8561f5b95f91fb14c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/384616
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Michael Anthony Knyszek [Fri, 21 Jan 2022 06:52:43 +0000 (06:52 +0000)]
runtime: simplify histogram buckets considerably
There was an off-by-one error in the time histogram buckets calculation
that caused the linear sub-buckets distances to be off by 2x.
The fix was trivial, but in writing tests I realized there was a much
simpler way to express the calculation for the histogram buckets, and
took the opportunity to do that here. The new bucket calculation also
fixes the bug.
Fixes #50732.
Change-Id: Idae89986de1c415ee4e148f778e0e101ca003ade
Reviewed-on: https://go-review.googlesource.com/c/go/+/380094 Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Robert Griesemer [Wed, 9 Feb 2022 22:16:05 +0000 (14:16 -0800)]
go/types, types2: rename structuralType/String to coreType/String
This is a pure rename of the respective Go functions/methods
with corresponding adjustments to error messages and tests.
A couple of comments were manually rephrased.
With this change, the implementation and error messages match
the latest spec.
No functionality change.
Change-Id: Iaa92a08b64756356fb2c5abdaca5c943c9105c96
Reviewed-on: https://go-review.googlesource.com/c/go/+/384618
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Tamir Duberstein [Thu, 27 Jan 2022 15:29:04 +0000 (15:29 +0000)]
syscall: use RLIMIT_CPU instead of RLIMIT_NOFILE
The latter is subject to kern.maxfilelimit restrictions on darwin which
are not reflected in the return value. This makes it difficult to
reliably restore the default after the test is complete. RLIMIT_CPU
should hopefully sidestep this problem.
Updates #40564.
Change-Id: Ifb33c7d46f2708130cef366dc245c643a2d5e465
Reviewed-on: https://go-review.googlesource.com/c/go/+/383234
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com>
Trust: Bryan Mills <bcmills@google.com>
Robert Griesemer [Wed, 9 Feb 2022 20:43:21 +0000 (12:43 -0800)]
spec: document behavior of generic type switch cases
Fixes #51110.
Change-Id: I11370417f1ef435b05dfab18eeabc2c3c1b7b8a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/384674
Trust: Robert Griesemer <gri@golang.org>
Trust: Dan Scales <danscales@google.com> Reviewed-by: Dan Scales <danscales@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Wed, 9 Feb 2022 02:40:28 +0000 (18:40 -0800)]
spec: the type of a constant cannot be a type parameter
Add corresponding rules and a couple of examples.
Fixes #50202.
Change-Id: I4287b5e2d0fd29a0c871795e07f1bb529c9c6004
Reviewed-on: https://go-review.googlesource.com/c/go/+/384240
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Robert Griesemer [Tue, 8 Feb 2022 18:41:27 +0000 (10:41 -0800)]
spec: use "core type" rather than "structural type"
This change in terminology prevents potential confusion
that migth be caused by associating "structural type"
with "structural typing"; the two are not connected.
Also, adjusted introductory paragraph of section on
constraint type inference: type inference goes in both
directions, from type parameter to core type and vice
versa. The previous description was not quite accurate.
Change-Id: If4ca300f525eea660f68486302619aa6ad5dbc2c
Reviewed-on: https://go-review.googlesource.com/c/go/+/384238
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Eric Lagergren [Wed, 9 Feb 2022 06:38:28 +0000 (22:38 -0800)]
crypto/aes: fix key size typo
AES-196 does not exist, but AES-192 does.
Signed-off-by: Eric Lagergren <eric@ericlagergren.com>
Change-Id: I8c9ac67735e99e5b2ee7fb9824029c1164221153
Reviewed-on: https://go-review.googlesource.com/c/go/+/384374
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
Bryan C. Mills [Tue, 8 Feb 2022 22:09:40 +0000 (17:09 -0500)]
net: fix a race in TestLookupContextCancel
If the actual DNS lookup in LookupIPAddr completes quickly enough,
it may succeed even if the passed-in Context is already canceled.
That would (rarely) cause TestLookupContextCancel to fail due to an
unexpectedly-nil error.
This change uses the existing testHookLookupIP hook to delay the
cancellation until the lookup has started (to try to provoke the code
path for which the test was added), and then block the lookup result
until LookupIPAddr has noticed it.
Bryan C. Mills [Tue, 8 Feb 2022 17:23:50 +0000 (12:23 -0500)]
runtime/debug: replace (*BuildInfo).Marshal methods with Parse and String
Since a String method cannot return an error, escape fields that may
contain unsanitized values, and unescape them during parsing.
Add a fuzz test to verify that calling the String method on any
BuildInfo returned by Parse produces a string that parses to the same
BuildInfo. (Note that this doesn't ensure that String always produces
a parseable input: we assume that a user constructing a BuildInfo
provides valid paths and versions, so we don't bother to escape those.
It also doesn't ensure that ParseBuildInfo accepts all inputs that
ought to be valid.)
Meng Zhuo [Wed, 9 Feb 2022 02:39:15 +0000 (10:39 +0800)]
runtime: AES maphash scramble 3 times on 386
Issue #43130 shows flaky hash not inbalanced on 386 platform,
which is using AES hashing instead of wyhash.
This CL increase the scramble times to 3 that amd64 using right now.
Robert Griesemer [Tue, 8 Feb 2022 04:59:59 +0000 (20:59 -0800)]
doc/go1.18: document behavior of go/types predicates for extended interfaces
For #47694.
Change-Id: Ic27193b65ef4b3c0c932107b8731b5f8d3190ad5
Reviewed-on: https://go-review.googlesource.com/c/go/+/383918
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Cherry Mui [Tue, 8 Feb 2022 19:46:58 +0000 (14:46 -0500)]
cmd/dist: test cgo internal linking on darwin-arm64
CL 383554 disables testing cgo internal linking on all ARM64 but
Windows, because it doesn't work with newer GCC. But
- darwin-arm64 works, and it does not use GCC
- we don't support cgo internal linking on windows-arm64 anyway.
This CL fixes the condition.
Change-Id: I9eb7b81ef75e482f5e95d2edae4863ba21396432
Reviewed-on: https://go-review.googlesource.com/c/go/+/384269
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>
Sean Liao [Tue, 8 Feb 2022 21:34:13 +0000 (22:34 +0100)]
net/smtp: match actual behavior for Auth.Start
Looking at history, it appears to never have worked as documented.
Fixes #48759
Change-Id: I066307c28e3ed1875c1c4049bade62e2818dd400
Reviewed-on: https://go-review.googlesource.com/c/go/+/383998 Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Mui <cherryyz@google.com>
Robert Griesemer [Tue, 8 Feb 2022 02:37:02 +0000 (18:37 -0800)]
go/types, types2: AssertableTo is undefined for generalized interfaces
Document that AssertableTo is undefined (at least for 1.18) if
the first argument is a generalized interface; i.e., an interface
that may only be used as a constraint in Go code.
Still, implement it as we might expect it to be defined in the
future, to prevent problems down the road due to Hyrum's Law.
While at it, also removed the internal flag forceStrict and its
one use in Checker.assertableTo; forceStrict was never enabled
and if it would have been enabled, the behavior would not have
been correct.
Change-Id: Ie4dc9345c88d04c9640f881132154a002db22643
Reviewed-on: https://go-review.googlesource.com/c/go/+/383917
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Ian Lance Taylor [Tue, 8 Feb 2022 01:07:44 +0000 (17:07 -0800)]
runtime: restore old mp.fastrand initialization
CL 337350 changed mp.fastrand from a [2]uint32 to a uint64 and changed
the initialization to a single call of int64Hash. However, int64Hash
returns uintptr, so 32-bit systems this always left the most
significant 32 bits of mp.fastrand initialized to 0. The new code also
did not protect against initializing mp.fastrand to 0, which on a
system that does not implement math.Mul64 (most 32-bit systems) would
lead fastrand to always return 0.
This CL restores the mp.fastrand initialization to what it was before
CL 337350, adjusted for the change from [2]uint32 to uint64.
Change-Id: I663b415d9424d967e8e665ce2d017604dcd5b204
Reviewed-on: https://go-review.googlesource.com/c/go/+/383916
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Robert Griesemer [Tue, 8 Feb 2022 17:47:46 +0000 (09:47 -0800)]
spec: explicitly define integer, floating-point, and complex types
The terms "integer type", "floating-point type", and "complex type"
are used frequently in the spec but are not explicitly (only indirectly)
defined.
Slightly rephrased the section on numeric types and introduce these
terms explicitly. Add links to this section.
Change-Id: I3fb888933bece047da8b356b684c855618e9aee4
Reviewed-on: https://go-review.googlesource.com/c/go/+/384157
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ian Lance Taylor [Tue, 8 Feb 2022 21:11:09 +0000 (13:11 -0800)]
builtin: clarify that interface types do not implement comparable
Fixes #51083
Change-Id: Ic9207ae4104b06749925186e0eb4f18edf1b5007
Reviewed-on: https://go-review.googlesource.com/c/go/+/384235
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>
Bryan C. Mills [Tue, 8 Feb 2022 20:07:21 +0000 (15:07 -0500)]
runtime: skip TestGdbBacktrace flakes matching a known GDB internal error
TestGdbBacktrace occasionally fails due to a GDB internal error.
We have observed the error on various linux builders since at least
October 2020, and it has been reported upstream at least twice.¹²
Since the bug is external to the Go project and does not appear to be
fixed upstream, this failure mode can only add noise.
Daniel Martí [Tue, 8 Feb 2022 14:49:30 +0000 (14:49 +0000)]
misc/reboot: don't use symlinks when copying GOROOT/src
go:embed disallows using symlinked files by design.
crypto/elliptic is the first std package to use it as of CL 380475,
and unfortunately that broke the TestRepeatBootstrap long test.
The reason it uses symlinks is for speed; it wants to copy GOROOT/src,
but regular files aren't going to be modified in any way,
so a symlink, if supported, means not needing to copy the contents.
Replace the symlink attempt with hard links,
which will mean regular files remain as such, fixing go:embed.
It's worth noting that on many systems hard links won't work,
as the temporary filesystem tends to be separate,
but it doesn't hurt to try.
In my system, where /tmp is tmpfs, the test now copies more bytes.
With the added Logf, I can see overlayDir goes from ~30ms to ~100ms.
This makes sense, as GOROOT/src currently weighs around 100MiB.
To alleviate that slow-down, stop copying testdata directories,
as they currently weigh around 20MiB and aren't needed for the test.
This gets overlayDir on my system down to an acceptable ~70ms.
I briefly considered teaching overlayDir what files can be symlinks,
but that seemed fairly complex long-term, as any file could be embedded.
While here, start using testing.T.TempDir and fs.WalkDir.
Daniel Martí [Mon, 24 Jan 2022 15:26:33 +0000 (15:26 +0000)]
crypto/elliptic: use go:embed for the precomputed p256 table
go.dev/cl/339591 changed the code generation to use a constant string,
so that the ~88KiB table can be marked read-only.
The compiled code became a lot better, but unfortunately,
the generated Go source became significantly more inefficient.
The numbers below compare "gofmt -l" and "go tool compile" of said file,
where "old" is the file as of Go 1.17, and "new" as of master in 2022/01/19:
name old time/op new time/op delta
Gofmt 22.8ms ± 6% 898.5ms ± 3% +3837.32% (p=0.000 n=8+8)
GoToolCompile 26.9ms ± 2% 371.1ms ± 2% +1278.36% (p=0.000 n=7+8)
name old user-time/op new user-time/op delta
Gofmt 25.7ms ±65% 897.1ms ± 3% +3383.86% (p=0.000 n=8+8)
GoToolCompile 35.1ms ±26% 367.2ms ± 3% +945.80% (p=0.000 n=8+8)
name old sys-time/op new sys-time/op delta
Gofmt 6.42ms ±276% 7.23ms ±38% ~ (p=0.412 n=8+6)
GoToolCompile 9.20ms ±100% 13.90ms ±53% ~ (p=0.105 n=8+8)
name old peak-RSS-bytes new peak-RSS-bytes delta
Gofmt 9.11MB ± 7% 22.79MB ± 1% +150.23% (p=0.000 n=8+8)
GoToolCompile 25.1MB ± 2% 68.6MB ± 2% +173.57% (p=0.000 n=8+8)
"+" operators are binary expressions at the syntax tree level,
which are represented by packages like go/ast as roughly:
struct {
X Expr
Op Token
Y Expr
}
Since each node is a pointer, chains of "+" operators act like linked lists.
The generated code has about 14k lines, and 8 "+" operators per line,
meaning that we end up with a linked list with over 11k elements.
This explains the slow-down in gofmt; the printer must walk said list,
and it does so more than once to work out how to format it.
It seems like the compiler is similarly affected by the huge length.
To remedy the effect of the linked list, use go:embed instead.
This results in the same string variable with the binary table,
but it greatly reduces the amount of syntax and its cost above.
We still keep the generator around, but modified so it produces the
binary file to be embedded rather than a large Go file.
Finally, we update go/build/deps_test.go to allow crypto/elliptic to
depend on embed; it's a tiny package and crypto/elliptic was already
manually embedding assets via code generation.
The change to deps_test.go was briefly discussed in the issue below.
Robert Findley [Tue, 1 Feb 2022 22:13:53 +0000 (17:13 -0500)]
go/parser: fix incorrect resolution of receiver type parameters
Declare receiver type parameters in the function scope, but don't
resolve them (for now), as ast.Object.Decl is not documented to hold
*ast.Idents. This avoids incorrect resolution of identifiers to names
outside the function scope.
Also make tracing and error reporting more consistent.
For golang/go#50956
Change-Id: I8cd61dd25f4c0f6b974221599b00e23d8da206a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/382247
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com> Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Robert Griesemer [Mon, 7 Feb 2022 19:28:14 +0000 (11:28 -0800)]
go/types, types2: ensure we have an interface before checking constraints
Due to delayed computation of constraint type sets it is possible that
a type argument is checked against a constraint before that constraint
has been wrapped into an implicit interface (if needed).
When the type checker is about to check whether a type argument
implements a constraint, it's always safe to force wrapping of
a constraint in an implicit interface (if necessary) before doing
the implements check.
Also, use a better position for tracing output related to constraint
type set computation.
Fixes #51048.
Change-Id: I52fecbf57814f09b62762452d7e17c2a230fdd59
Reviewed-on: https://go-review.googlesource.com/c/go/+/383834
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Ian Lance Taylor [Mon, 7 Feb 2022 03:33:03 +0000 (19:33 -0800)]
runtime: don't assume that 0.25 * 100 is representable as int
For the gofrontend, it's not; there are some trailing one bits,
which is permitted by the spec.
Change-Id: I58f5a5347068bb488306ec8e73da7c59376f1ae1
Reviewed-on: https://go-review.googlesource.com/c/go/+/383635
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
Ian Lance Taylor [Mon, 7 Feb 2022 18:02:30 +0000 (10:02 -0800)]
doc/go1.18: mention new x/exp generic packages
Change-Id: I119cfb1a0da9af89ced78935b8fcdfdb8d9b4ab6
Reviewed-on: https://go-review.googlesource.com/c/go/+/383794
Trust: Ian Lance Taylor <iant@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org>
Bryan C. Mills [Mon, 7 Feb 2022 16:33:30 +0000 (11:33 -0500)]
misc/cgo: fix aliasing bugs in parallel tests that append to shared slices
These tests use a slice to represent the base C compiler command (with
flags). Appending to that slice can cause subtle aliasing bugs, such
as commands that silently corrupt the arguments of other concurrent
commands in parallel tests.
In this change, we explicitly reduce the capacity of the command slice
to force appends to it to always allocate unique new slices.
Benny Siegert [Sat, 5 Feb 2022 16:23:26 +0000 (17:23 +0100)]
cmd/dist: skip internal linking tests on arm64
The previous workaround for issue #39466 only disabled this test for
Linux. However, the issue manifests for all arm64 systems with gcc 9.4
and above. The new netbsd-arm64 builder uses NetBSD-current with gcc
10.3, so it fails in the same way.
Updates #39466
Change-Id: I276a99a5e60914e5c22f74a680e461bea17cfe92
Reviewed-on: https://go-review.googlesource.com/c/go/+/383554
Trust: Benny Siegert <bsiegert@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
Ian Lance Taylor [Sat, 5 Feb 2022 05:14:13 +0000 (21:14 -0800)]
runtime: change sys.PtrSize to goarch.PtrSize in comments
The code was updated, the comments were not.
Change-Id: If387779f3abd5e8a1b487fe34c33dcf9ce5fa7ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/383495
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Robert Griesemer [Fri, 4 Feb 2022 00:07:28 +0000 (16:07 -0800)]
go/types, types2: always use missingMethodReason in checker.Implements
Remove special case where we don't have a *Checker and always use
Checker.missingMethodReason in Checker.implements.
Look for zero methods rather than empty interface to exit early
from Checker.missingMethod, and remove the extra test in
Checker.implements.
With this change we get consistent and more detailed error messages
from all places where we do a form of the "implements" test.
To make this possible, allow for the receiver to be nil in
- Checker.sprintf
- Checker.missingMethodReason
- Checker.interfacePtrError
- Checker.funcString
Allowing Checker.sprintf with nil Checker permits further simplifying
in a couple of places.
Change-Id: I0ea7178c9efbcd4a25ded2a66e2b058db52dc4d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/383054
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Robert Griesemer [Thu, 3 Feb 2022 23:03:02 +0000 (15:03 -0800)]
go/types, types2: simplify Checker.typeAssertion, use same code in both type checkers
- Remove the xtyp argument from the Checker.typeAssertion parameter
list; it was confusing and not needed. Adjusted call sites.
- Simplify logic in Checker.typeAssertion.
- Use the same code in both types2 and go/types, specifically
use the same error positions.
- Adjust error messages as needed.
This removes another subtle discrepancy between types2 and go/types.
The go/types error messages don't have the have/want appendix for
the affected error messages yet because we don't use case folding
in lookups yet.
Change-Id: Id39f5c473da36c9baad60082f85cf1f34dc26c50
Reviewed-on: https://go-review.googlesource.com/c/go/+/383014
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Robert Griesemer [Thu, 3 Feb 2022 05:36:50 +0000 (21:36 -0800)]
go/types, types2: simplify missingMethodReason
Added a funcString helper so we don't need to rewrite strings
with strings.Replace.
Use compiler format for error message about wrong method type;
this removes another unnecessary variation.
Simplify conditions for pointer-to-interface related error:
if one of the involved types is an interface pointer, it can't
have any methods.
Rewrite logic so we don't need all the else-if branches.
Adjusted a test case for types2 accordingly. The go/types version
of this test case has a different error because the implementation
of Checker.typeAssertion is different in the two type checkers
(the types2 version gives errors closer to the 1.17 compiler).
Change-Id: I19e604d7063c3e31e8290bd78384a9f38bb0d740
Reviewed-on: https://go-review.googlesource.com/c/go/+/382694
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Robert Griesemer [Thu, 3 Feb 2022 00:31:26 +0000 (16:31 -0800)]
go/types, types2: fix bug in types2.MissingMethod
Because Checker.missingMethod also looks up methods matching
matching case-folded names, when Checker.missingMethod returns
an alternative method, that method does not automatically have
the wrong type. It may be a method with a different name.
Adjust types2.MissingMethod to check the alternative method
name before reporting a wrong type.
Add API test that verifies (now correct) behavior for this
case.
Ported the code also to go/types, though it was not a bug
there yet because looking up with case-folding is not yet
enabled.
Change-Id: Iaa48808535c9265a9879338ea666c6c021e93a2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/382634
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Robert Griesemer [Wed, 2 Feb 2022 23:04:58 +0000 (15:04 -0800)]
go/types, types2: remove superflous type parameter length checks
There is no need to check for length equality of type parameter
lists in Checker.missingMethod: the Identical predicate does
this check. Furthermore, we don't have methods with their own
type parameters. Remove the unnecessary (duplicate) code.
Also, update doc string on missingMethod and rename the 2nd
result parameter for clarity, and clarify internal comments.
For go/types, include the same case-folding code as for types2
but leave it disabled or now. Adjust any other differences in
the missingMethod implementation.
With this change, the types2 and go/types code of missingMethod
is identical again except for the disabled case-folding lookup.
No functionality changes.
Preparation for fixing some of the outstanding error reporting issues.
Change-Id: I4778d006c17f4e084ecc2cac7386c68e86aa49eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/382614
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>
Robert Griesemer [Wed, 2 Feb 2022 21:18:56 +0000 (13:18 -0800)]
go/types, types2: use same method lookup code in both type checkers
types2 has some code to handle case-folding when doing method lookups
which was missing in go/types. This change is a first step to match
the implementations. Specifically:
In types2:
- remove the lookupMethodFold names in favor of just lookupMethod,
but with the foldCase flag (e.g., instead if lookupMethodFold,
we just use lookupMethod)
- rename checkFold to foldCase everywhere
- add foldCase parameter where it was missing
- moved foldCase paremeter to the end in lookupFieldOrMethod
- no functionality changes
In go/types:
- match function signatures with types2 use
- always provide false as argument for foldCase for now
- no functionality changes
Preparation for fixing some of the outstanding error reporting issues.
Change-Id: If129a5feb89ddf96a3596e8d73b23afa591875a0
Reviewed-on: https://go-review.googlesource.com/c/go/+/382461
Trust: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com>