The function runtime.convT64 accepts a single uint64 argument, but the
compiler's rules in the walk phase for determining whether is it ok to
pass a value of type T to a call to runtime.convT64 were slightly off.
In particular the test was allowing a type T with size less than eight
bytes but with more than one internal element (e.g. a struct). This
patch tightens up the rules somewhat to prevent this from happening.
Updates #40724.
Change-Id: I3b909267534db59429b0aa73a3d73333e1bd6432
Reviewed-on: https://go-review.googlesource.com/c/go/+/308069
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
go.mod file was not tidy, made builders sad.
Updates #40724.
Change-Id: I28371a1093108f9ec473eb20bb4d185e35dee67d
Reviewed-on: https://go-review.googlesource.com/c/go/+/308590
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
"Not found" and "no matching version" errors usually indicate the user
is offline or the proxy doesn't have a version of go.mod that could
provide retractions. 'go list -m -u' should still succeed.
We should still report unclassified errors though. Previously, we
reported most errors loading retractions but did not report errors
loading updates. This change makes those operations more consistent.
Fixes#45305
Change-Id: I2f23a566c9481bc7ff229a177f39d78f6a8aae77
Reviewed-on: https://go-review.googlesource.com/c/go/+/306572
Trust: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
However, still only trigger -mod=vendor automatically (and only apply
the more stringent Go 1.14 vendor consistency checks) if the 'go'
version is explicit. This provides maximal compatibility with Go 1.16
and earlier: Go 1.11 modules will continue not to fail vendor
consistency checks, but scripts that assume semantics up to Go 1.16
for unversioned modules will continue to work unmodified.
Fixes#44976
For #36460
Change-Id: Idb05ca320023f57249c71fc8079218e8991d1ff9
Reviewed-on: https://go-review.googlesource.com/c/go/+/308509
Trust: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Jay Conrod <jayconrod@google.com>
On Windows, TLS is uninitialized for C threads calling into Go code.
In this path, before calling into user Go code, we call into needm which
runs without an m, but whose purpose is to pick one up. While in Go
code, we may occasionally restore the G register from TLS for a number
of reasons. Rather than try to flag all these cases, given that needm
(and its callees) are already somewhat special, just set up a dummy TLS
space for it that's read-only. If it ever actually tries to write to
this space (it shouldn't), it will fail loudly. Otherwise, code that
restores the G register will simply load a zero value, but that's OK
since needm is careful never to require the G at any point, because it
doesn't yet have a valid G. Furthermore, by the time needm returns, it
will have set up TLS properly for a Windows C thread, so there's no need
to do anything extra afterwards.
For #40724.
Change-Id: I34e8095059817e4ee663505e89cda8785b634b98
Reviewed-on: https://go-review.googlesource.com/c/go/+/307872
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
In expand_calls, OpSelectN occurs both before and after the rewriting.
Attempting to rewrite a post-expansion OpSelectN is bad.
(The only ones rewritten in place are the ones returning mem;
others are synthesized to replace other selection chains with
register references.)
Updates #40724.
Updates #44816#issuecomment-815258897.
Change-Id: I7b6022cfb47f808d3ce6cc796c067245f36047f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/308309
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
CL 307818 added a package that the runtime depends on, but didn't
update the list of runtime dependencies in this test.
This should fix the longtest builder failures.
Change-Id: I5f3be31b069652e05ac3db9b1ce84dd5dfe0f66f
Reviewed-on: https://go-review.googlesource.com/c/go/+/308469
Trust: Austin Clements <austin@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
t is the type of the function that was called
tv is the type of the result
This fixes the failures for
GOEXPERIMENT=regabi,regabiargs go test go test text/template
GOEXPERIMENT=regabi,regabiargs go test go test html/template
Updates #40724.
Change-Id: Ic9b02d72d18ff48c9de1209987cc39da619c2241
Reviewed-on: https://go-review.googlesource.com/c/go/+/308189
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
As discussed in: https://github.com/golang/go/issues/45429, about entry
type comments, it is possible for p == nil when m.dirty != nil, so
update the commemt about it.
Fixes#45429
Change-Id: I7ef96ee5b6948df9ac736481d177a59ab66d7d4d
GitHub-Last-Rev: 202c598a0a
GitHub-Pull-Request: golang/go#45443
Reviewed-on: https://go-review.googlesource.com/c/go/+/308292
Reviewed-by: Changkun Ou <euryugasaki@gmail.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Trust: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Updates #45402
Change-Id: I3aa82fc2486b4de49b45388bbab24f5ffe558f91
Reviewed-on: https://go-review.googlesource.com/c/go/+/307989
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>
This reverts commit c274a7c03b.
Reason for revert: this can cause a compiler deadlock, and there's
no demonstrable benefit to making the change.
Change-Id: I42325ddea68d37db16fd0061c5baaee112b755b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/308369
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Currently objabi.Experiments is set via side-effect from an init
function, which makes their initialization process somewhat unclear
(indeed, I've messed this up before) and opens the possibility of
accessing them from another init function before it's initialized.
Originally, this init function set several variables, but at this
point it sets only objabi.Experiments, so switch to just using a
variable initializer to make the initialization process clear.
Change-Id: Id0d2ac76ae463824bbf37a9305e8643a275f1365
Reviewed-on: https://go-review.googlesource.com/c/go/+/307821
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This adds the set of GOEXPERIMENTs to the build version if it differs
from the default set of experiments. This exposes the experiment
settings via runtime.Version() and "go version <binary>".
Change-Id: I143dbbc50f66a4cf175469199974e18848075af6
Reviewed-on: https://go-review.googlesource.com/c/go/+/307820
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Right now the rules around handling default-on experiments are
complicated and a bit inconsistent. Notably, objabi.GOEXPERIMENT is
set to a comma-separated list of enabled experiments, but this may not
be the string a user should set the GOEXPERIMENT environment variable
to get that list of experiments: if an experiment is enabled by
default but gets turned off by GOEXPERIMENT, then the string we report
needs to include "no"+experiment to capture that default override.
This complication also seeps into the version string we print for "go
tool compile -V", etc. This logic is further complicated by the fact
that it only wants to include an experiment string if the set of
experiments varies from the default.
This CL rethinks how we handle default-on experiments. Now that
experiment state is all captured in a struct, we can simplify a lot of
this logic. objabi.GOEXPERIMENT will be set based on the delta from
the default set of experiments, which reflects what a user would
actually need to pass on the command line. Likewise, we include this
delta in the "-V" output, which simplifies this logic because if
there's nothing to show in the version string, the delta will be
empty.
Change-Id: I7ed307329541fc2c9f90edd463fbaf8e0cc9e8ee
Reviewed-on: https://go-review.googlesource.com/c/go/+/307819
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently, we have boolean and integral constants for GOEXPERIMENTs in
various places. Consolidate these into automatically generated
constants in the internal/goexperiment package.
Change-Id: I42a49aba2a3b4c722fedea23a613162cd8a67bee
Reviewed-on: https://go-review.googlesource.com/c/go/+/307818
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently there's knowledge about the list of GOEXPERIMENTs in a few
different places. This CL introduces a new package and consolidates
the list into one place: the internal/goexperiment.Flags struct type.
This package gives us a central place to document the experiments as
well as the GOEXPERIMENT environment variable itself. It will also
give us a place to put built-time constants derived from the enabled
experiments.
Now the objabi package constructs experiment names by reflecting over
this struct type rather than having a separate list of these names
(this is similar to how the compiler handles command-line flags and
debug options). We also expose a better-typed API to the toolchain for
propagating enabled experiments.
Change-Id: I06e026712b59fe2bd7cd11a869aedb48ffe5a4b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/307817
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently, the objabi.Experiment fields use Go-standard CamelCase, the
GOEXPERIMENT environment variable flags and build tags use all
lowercase, and the asm macros use upper-case with underscores.
This CL makes asm use the lowercase names for macros so there is one
less spelling, e.g., GOEXPERIMENT_regabiargs. This also makes them
consistent with the GOOS_* and GOARCH_* macros, which also use lower
case.
Change-Id: I305cd89af5e8cd1a89cc148746c034bcfd76db3c
Reviewed-on: https://go-review.googlesource.com/c/go/+/307816
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
We have ways to statically access experiments now, so we don't need a
relatively clunky string-parsing dynamic way to do it.
Change-Id: I5d75480916eef4bde2c30d5fe30593180da77ff2
Reviewed-on: https://go-review.googlesource.com/c/go/+/307815
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Updates #45402
Change-Id: I573133d6b987e8ac23e3e2018652612af684c755
Reviewed-on: https://go-review.googlesource.com/c/go/+/307990
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>
These are privileged instructions, and thus will never work with
usermode code. I don't think there is a case where this isn't
true. The motivation is to simplify handling of MOV* opcodes.
Assembler support for recognizing the MSR as a register is
retained.
Change-Id: Ic33f021a20057b64e69df8ea125e23dd8937e38d
Reviewed-on: https://go-review.googlesource.com/c/go/+/307814
Run-TryBot: Paul Murphy <murp@ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com>
Trust: Carlos Eduardo Seo <carlos.seo@linaro.org>
update comment cause gc/reflect.go has been moved to reflectdata/reflect.go
In the commit (attach below), gc/reflect.go is moved to reflectdata/reflect.go
So the comment referring gc/reflect.go should be updated to reflectdata/reflect.go
There maybe other places that refers gc/reflect.go that should be updated.
I would work around it soon.
commit:
de65151e50e4895ab4c0
Change-Id: Ieed5c48049ffe6889c08e164972fc7825653ac05
GitHub-Last-Rev: eec9c2328d
GitHub-Pull-Request: golang/go#45421
Reviewed-on: https://go-review.googlesource.com/c/go/+/307930
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
When the write barrier pass emits typedmemmove/typedmemclr calls,
even the arguments are in registers, we still need to leave space
for the spill slots. Count that space. Otherwise when the callee
spills arguments it may clobber locals on the caller's frame.
Change-Id: I5326943427feaf66cab7658a5bef55b3baf5d345
Reviewed-on: https://go-review.googlesource.com/c/go/+/307824
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: David Chase <drchase@google.com>
Follow-up on https://golang.org/cl/305573.
As a consequence, re-enable test case that caused problems with that CL.
Change-Id: Ibffee3f016f4885a55b8e527a5680dd437322209
Reviewed-on: https://go-review.googlesource.com/c/go/+/307216
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Make position comparison generally available.
Change-Id: I94b6f658fa19a15b30574dbb2181879115c131a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/307215
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Type parameters for methods are not part of the accepted language,
but maintaining the code for type-checking them ensures regularity
of the type checker implementation. For now, keep the flag internally,
disabled by default. The flag is set when running tests.
Change-Id: Ic99934bd00bd2608dc1178e4131f46dd1507f0f5
Reviewed-on: https://go-review.googlesource.com/c/go/+/307214
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Constraint type inference is part of the proposed language.
Use an internal flag to control the feayure for debugging.
Change-Id: I7a9eaee92b5ffc23c25d9e68a729acc0d705e879
Reviewed-on: https://go-review.googlesource.com/c/go/+/306770
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Rather than splitting up type inference into function argument
and constraint type inference, provide a single Checker.infer
that accepts type parameters, type arguments, value parameters,
and value arguments, if any. Checker.infer returns the completed
list of type arguments, or nil.
Updated (and simplified) call sites.
Change-Id: I9200a44b9c4ab7f2d21eed824abfffaab68ff766
Reviewed-on: https://go-review.googlesource.com/c/go/+/306170
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
There's a problem in liveness, where liveness of any
part of an aggregate keeps the whole aggregate alive,
but the not-live parts don't get spilled. The GC
can observe those live-but-not-spilled slots, which
can contain junk.
A better fix is to change liveness to work
pointer-by-pointer, but that is also a riskier,
trickier fix.
To avoid this, in the case of
(1) an aggregate input parameter
(2) containing pointers
(3) passed in registers
pre-spill the pointers.
Updates #40724.
Change-Id: I6beb8e0a353b1ae3c68c16072f56698061922c04
Reviewed-on: https://go-review.googlesource.com/c/go/+/307909
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
CL 302231 added some optimization rules with instructions CSETM, CSINC,
CSINV, and CSNEG, but did not deal with the situation where flag is
constant, resulting in some cases that could be more optimized cannot
be optimized, and the FlagConstant value is passed to codegen pass. This
CL adds these missing rules.
Fixes#45359
Change-Id: I700608cfb9a6a768a18d1fd5d374d7e92aa6f838
Reviewed-on: https://go-review.googlesource.com/c/go/+/307650
Reviewed-by: eric fang <eric.fang@arm.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: eric fang <eric.fang@arm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: eric fang <eric.fang@arm.com>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
A non-trivial Cgo program may need to use callbacks and interact with
go objects per goroutine. Because of the rules for passing pointers
between Go and C, such a program needs to store handles to associated
Go values. This often causes much extra effort to figure out a way to
correctly deal with: 1) map collision; 2) identifying leaks and 3)
concurrency.
This CL implements a Handle representation in runtime/cgo package, and
related methods such as Value, Delete, etc. which allows Go users can
use a standard way to handle the above difficulties.
In addition, the CL allows a Go value to have multiple handles, and the
NewHandle always returns a different handle compare to the previously
returned handles. In comparison, CL 294670 implements a different
behavior of NewHandle that returns a unique handle when the Go value is
referring to the same object.
Benchmark:
name time/op
Handle/non-concurrent-16 487ns ± 1%
Handle/concurrent-16 674ns ± 1%
Fixes#37033
Change-Id: I0eadb9d44332fffef8fb567c745246a49dd6d4c1
Reviewed-on: https://go-review.googlesource.com/c/go/+/295369
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Cherry Zhang <cherryyz@google.com>
This change refactors the existing funcLayout tests and sets them up to
support the new register ABI by explicitly setting the register counts
to zero. This allows the test to pass if GOEXPERIMENT=regabiargs is set.
A follow-up change will add tests for a non-zero register count.
For #40724.
Change-Id: Ibbe061b4ed4fd70566eb38b9e6182dca32b81127
Reviewed-on: https://go-review.googlesource.com/c/go/+/307869
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
runtime.raceread/racewrite/racewriterange are functions that are
called from compiler instrumented code, follwoing ABIInternal.
They are assembly functions defined as ABIInternal in the runtime,
in order to avoid wrappers because they need to get the caller's
PC. This CL makes them to use the actual internal ABI.
Change-Id: Id91d73cf257f7b11a858958d85c38c4aa904d9c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/307812
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Change-Id: I6d78e0e742cb0e7f5ea3f430e9cec0f5d1ee03e9
Reviewed-on: https://go-review.googlesource.com/c/go/+/307652
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>
This significantly simplifies the implementation of editRequirements
in preparation for making it lazy. It should have no effect on which
version combinations are rejected by 'go get', nor on which solutions
are found if downgrades are needed.
This change results in a small but observable change in error logging.
Before, we were reporting an error line for each argument that would
have exceeded its specified version, attributing it to one arbitrary
cause. Now, we are reporting an error line for each argument that
would cause any other argument to exceed its specified version. As a
result, if one argument would cause two others to exceed their
versions, we will now report one line instead of two; if two arguments
would independently cause one other to exceed its version, we will now
report two lines instead of one.
This change may result in a small performance improvement. Because we
are now scanning and rejecting incompatible requirements earlier, we
may waste less time computing upgrades and downgrades that ultimately
won't matter due to conflicting constraints.
For #36460
Change-Id: I125aa09b4be749dc5bacef23a859333991960e85
Reviewed-on: https://go-review.googlesource.com/c/go/+/305009
Trust: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
Reviewed-by: Michael Matloob <matloob@golang.org>
This caused a problem with
GOEXPERIMENT=regabi,regabiargs go test -c crypto/x509
Updates #40724.
Change-Id: Ia3cdbe9968816c77836cb3e3ba89642aafd1b18d
Reviewed-on: https://go-review.googlesource.com/c/go/+/307529
Trust: David Chase <drchase@google.com>
Run-TryBot: David Chase <drchase@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When a function panics then recovers, it needs to return to the
caller with named results having the correct values. For
in-register results, we need to load them into registers at the
defer return path.
For non-open-coded defers, we already generate correct code, as
the defer return path is part of the SSA CFG and contains the
instructions that are the same as an ordinary return statement,
including putting the results to the right places.
For open-coded defers, we have a special code generation that
emits a disconnected block that currently contains only the
deferreturn call and a RET instruction. It leaves the result
registers unset. This CL adds instructions that load the result
registers on that path.
Updates #40724.
Change-Id: I1f60514da644fd5fb4b4871a1153c62f42927282
Reviewed-on: https://go-review.googlesource.com/c/go/+/307231
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Austin Clements <austin@google.com>
This is a simple workaround for a bug where runtime.GC() can return
before finishing a full sweep, causing gcTestIsReachable to throw. The
right thing is to fix runtime.GC(), but this should get this test
passing reliably in the meantime.
Updates #45315.
Change-Id: Iae141e6dbb26a9c2649497c1feedd4aaeaf540c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/307809
Trust: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
For #36460
Change-Id: Idb0b333a28d2470bc9482fe1829ccb6ddf8abd34
Reviewed-on: https://go-review.googlesource.com/c/go/+/304909
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>
Now that we use square brackets for instantiations, we
can tell type arguments from ordinary arguments without
"guessing" which permits a simpler implementation.
Specifically, replace use of Checker.exprOrTypeList with
Checker.exprList, and delete Checker.exprOrTypeList and
Checker.multiExprOrType.
Disable a test for an (esoteric) failure due to an
unrelated problem with error matching when running
the test.
Change-Id: I17f18fffc32f03fa90d93a68ebf56e5f2fcc9dab
Reviewed-on: https://go-review.googlesource.com/c/go/+/306171
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Now that we use square brackets for instantiations, we
can tell type arguments from ordinary arguments without
"guessing" which permits a simpler implementation.
While at it, also fix a minor position error for type
instantiations (now matching the code for function
instantiations).
Change-Id: I20eca51c5b06259703767b5906e89197d6cd595a
Reviewed-on: https://go-review.googlesource.com/c/go/+/306169
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
This moves the two helper functions startPos and endPos into
the syntax package where they belong. Export the functions and
adjust dependent code.
Change-Id: I8170faeadd7cfa8f53009f81fcffd50ec0fc6a98
Reviewed-on: https://go-review.googlesource.com/c/go/+/305578
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The exact same test case covered by this file is also in
fixedbugs/bug121.go. No need for duplication.
Also, the actual syntax error tested (multiple method names
with a single signature) is an unlikely syntax error, and
only here for historical reasons (in the very beginning, this
was actually possible to write). Now, virtually nobody is making
this mistake.
Change-Id: I9d68e0aee2a63025f44e6338647f8250ecc3077a
Reviewed-on: https://go-review.googlesource.com/c/go/+/307789
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In TestMorestack, on macOS, for some reason it got most of the
samples in synchronization (e.g. pthread_cond_signal and
pthread_cond_wait) and sometimes in other "syscalls" (usleep,
nanotime1), and very few samples in stack copying, sometimes 0,
which causes the test to fail. Maybe synchronization is slower on
macOS? (It doesn't seem so to me.) Or it is the OS's accounting
problem, where it is more likely to trigger a profiling signal
at a syscall (or certain kinds of syscalls)?
As the test is really about whether it can connect stack copying
with the function that grows the stack, this CL makes it spend
more time in copying stack than synchronization. Now it's getting
~100 samples for stack copying on a 5 second interval on my
machine, and the test passes reliably.
Fixes#44418.
Change-Id: I3a462c8c39766f2d67d697598f8641bbe64f16ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/307730
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Pratt <mpratt@google.com>
