When handling a type declaration like:
```
type B A
```
unified IR has been writing out that B's underlying type is A, rather
than the underlying type of A.
This is a bit awkward to implement and adds complexity to importers,
who need to handle resolving the underlying type themselves. But it
was necessary to handle when A was declared like:
```
//go:notinheap
type A int
```
Because we expected A's not-in-heap'ness to be conferred to B, which
required knowing that A was on the path from B to its actual
underlying type int.
However, since #46731 was accepted, we no longer need to support this
case. Instead we can write out B's actual underlying type.
One stumbling point though is the existing code for exporting
interfaces doesn't work for the underlying type of `comparable`, which
is now needed to implement `type C comparable`. As a bit of a hack, we
we instead export its underlying type as `interface{ comparable }`.
Fixes#54512.
Change-Id: I0fb892068d656f1e87bb8ef97da27756051126d5
Reviewed-on: https://go-review.googlesource.com/c/go/+/424854
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Previously we convert $0 to the ZR register for some reasons, which causes
two problems:
1. Confusion, the special case of the ZR register needs to be considered
when dealing with constants. For encoding, some places we encode ZR, and
some places we encode $0, although we have converted $0 to ZR.
2. Unexpected instruction format. All instructions that support ZR register
operands can be replaced by $0.
This patch removes this conversion. Note that this patch may cause previously
unintendedly supported instruction formats to no longer be supported.
Change-Id: I3d8d2c06711b7614a38191397da7776417f1861c
Reviewed-on: https://go-review.googlesource.com/c/go/+/404316
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
On ARM64 we use two separate instructions to compute the hi and lo
results of a 64x64->128 multiplication. Lower to two separate ops
so if only one result is needed we can deadcode the other.
Fixes#54607.
Change-Id: Ib023e77eb2b2b0bcf467b45471cb8a294bce6f90
Reviewed-on: https://go-review.googlesource.com/c/go/+/425101
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
For #23870
Change-Id: I3bbe0f751254d1354a59a88b45e6f944c7a2fb4d
Reviewed-on: https://go-review.googlesource.com/c/go/+/417874
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
With the introduction of stack objects, VARKILL information is
no longer needed.
With stack objects, an object is dead when there are no more static
references to it, and the stack scanner can't find any live pointers
to it. VARKILL information isn't used to establish live ranges for
address-taken variables any more. In effect, the last static reference
*is* the VARKILL, and there's an additional dynamic liveness check
during stack scanning.
Next CL will actually rip out the VARKILL opcodes.
Change-Id: I030a2ab867445cf4e0e69397911f8a2e2f0ed07b
Reviewed-on: https://go-review.googlesource.com/c/go/+/419234
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
We don't need this special loop construct anymore now that we do
conservative GC scanning of the top of stack. Rewrite instead to a simple
pointer increment on every iteration. This leads to having a potential
past-the-end pointer at the end of the last iteration, but that value
immediately goes dead after the loop condition fails, and the past-the-end
pointer is never live across any call.
This simplifies and speeds up loops.
R=go1.20
TODO: actually delete all support for OFORUNTIL. It is now never generated,
but code to handle it (e.g. in ssagen) is still around.
TODO: in "for _, x := range" loops, we could get rid of the index
altogether and use a "pointer to the last element" reference to determine
when the loop is complete.
Fixes#53409
Change-Id: Ifc141600ff898a8bc6a75f793e575f8862679ba1
Reviewed-on: https://go-review.googlesource.com/c/go/+/414876
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The non-unified frontend had repeated issues with inlining and
generics (#49309, #51909, #52907), which led us to substantially
restrict inlining when shape types were present.
However, these issues are evidently not present in unified IR's
inliner, and the safety restrictions added for the non-unified
frontend can simply be disabled in unified mode.
Fixes#54497.
Change-Id: I8e6ac9f3393c588bfaf14c6452891b9640a9d1bd
Reviewed-on: https://go-review.googlesource.com/c/go/+/424775
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
As a consistency check in devirtualization, when we determine `i` (of
interface type `I`) always has dynamic type `T`, we insert a type
assertion `i.(T)`. This emits an itab check for `go:itab.T,I`, but
it's always true (and so SSA optimizes it away).
However, if `I` is instead the generic interface type `I[T]`, then
`go:itab.T,I[int]` and `go:itab.T,I[go.shape.int]` are equivalent but
distinct itabs. And notably, we'll have originally created the
interface value using the former; but the (non-dynamic) TypeAssertExpr
created by devirtualization would ultimately emit a comparison against
the latter. This comparison would then evaluate false, leading to a
spurious type assertion panic at runtime.
The comparison is just meant as an extra safety check, so it should be
safe to just disable. But for now, it's simpler/safer to just punt on
devirtualization in this case. (The non-unified frontend doesn't
devirtualize this either.)
Change-Id: I6a8809bcfebc9571f32e289fa4bc6a8b0d21ca46
Reviewed-on: https://go-review.googlesource.com/c/go/+/424774
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
This CL switches unified IR to use shape-based stenciling with runtime
dictionaries, like the existing non-unified frontend. Specifically,
when instantiating generic functions and types `X[T]`, we now also
instantiated shaped variants `X[shapify(T)]` that can be shared by
`T`'s with common underlying types.
For example, for generic function `F`, `F[int](args...)` will be
rewritten to `F[go.shape.int](&.dict.F[int], args...)`.
For generic type `T` with method `M` and value `t` of type `T[int]`,
`t.M(args...)` will be rewritten to `T[go.shape.int].M(t,
&.dict.T[int], args...)`.
Two notable distinctions from the non-unified frontend:
1. For simplicity, currently shaping is limited to simply converting
type arguments to their underlying type. Subsequent CLs will implement
more aggressive shaping.
2. For generic types, a single dictionary is generated to be shared by
all methods, rather than separate dictionaries for each method. I
originally went with this design because I have an idea of changing
interface calls to pass the itab pointer via the closure
register (which should have zero overhead), and then the interface
wrappers for generic methods could use the *runtime.itab to find the
runtime dictionary that corresponds to the dynamic type. This would
allow emitting fewer method wrappers.
However, this choice does have the consequence that currently even if
a method is unused and its code is pruned by the linker, it may have
produced runtime dictionary entries that need to be kept alive anyway.
I'm open to changing this to generate per-method dictionaries, though
this would require changing the unified IR export data format; so it
would be best to make this decision before Go 1.20.
The other option is making the linker smarter about pruning unneeded
dictionary entries, like how it already prunes itab entries. For
example, the runtime dictionary for `T[int]` could have a `R_DICTTYPE`
meta-relocation against symbol `.dicttype.T[go.shape.int]` that
declares it's a dictionary associated with that type; and then each
method on `T[go.shape.T]` could have `R_DICTUSE` meta-relocations
against `.dicttype.T[go.shape.T]+offset` indicating which fields
within dictionaries of that type need to be preserved.
Change-Id: I369580b1d93d19640a4b5ecada4f6231adcce3fd
Reviewed-on: https://go-review.googlesource.com/c/go/+/421821
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Updated multiple tests in test/codegen: math.go, mathbits.go, shift.go
and slices.go to verify on ppc64/ppc64le as well
Change-Id: Id88dd41569b7097819fb4d451b615f69cf7f7a94
Reviewed-on: https://go-review.googlesource.com/c/go/+/412115
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Archana Ravindar <aravind5@in.ibm.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Paul Murphy <murp@ibm.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
CL 414836 limited the check for implicit dot for method call enabled by
a type bound. However, the checking condition for ODOTMETH only is not
right. For example, for promoted method, we have a OXDOT node instead,
and we still have to check for implicit dot in this case.
However, if the base type and embedded types have the same method name,
e.g in issue #53419, typecheck.AddImplicitDots will be confused and
result in an ambigus selector.
To fix this, we ensure methods for the base type are computed, then only
do the implicit dot check if we can find a matched method.
Fixes#54348
Change-Id: Iefe84ff330830afe35c5daffd499824db108da23
Reviewed-on: https://go-review.googlesource.com/c/go/+/422274
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The issue is expected to be fixed when Unified IR is enabled by default,
so adding a test to make sure thing works correctly.
Updates #53702
Change-Id: Id9d7d7ca4506103df0d10785ed5ee170d69988ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/423434
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>
I structured the test for issue54343.go after issue46725.go, where I
was careful to use `[4]int`, which is a type large enough to avoid the
tiny object allocator (which interferes with finalizer semantics). But
in that test, I didn't note the importance of that type, so I
mistakenly used just `int` in issue54343.go.
This CL switches issue54343.go to use `[4]int` too, and then adds
comments to both pointing out the significance of this type.
Updates #54343.
Change-Id: I699b3e64b844ff6d8438bbcb4d1935615a6d8cc4
Reviewed-on: https://go-review.googlesource.com/c/go/+/423115
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
With GOEXPERIMENT=unified, the order variables are printed in "live at
entry to f.func1" is sensitive to whether regabi is enabled for some
reason. The order shouldn't matter to correctness, but it is odd.
For now, this CL just relaxes the test expectation order to unblock
enabling GOEXPERIMENT=unified by default. I've filed #54402 to
investigate further to confirm this a concern.
Updates #54402.
Change-Id: Iddfbb12c6cf7cc17b2aec8102b33761abd5f93ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/422975
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
For selector expression "x.M" where "M" is a promoted method, irgen is using
the type of receiver "x" for determining the typeparams for instantiation.
However, because M is a promoted method, so its associated receiver is
not "x", but "x.T" where "T" is the embedded field of "x". That casues a
mismatch when converting non-shape types arguments.
Fixing it by using the actual receiver which has the method, instead of
using the base receiver.
Fixes#53982
Change-Id: I1836fc422d734df14e9e6664d4bd014503960bfc
Reviewed-on: https://go-review.googlesource.com/c/go/+/419294
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
This CL applies the same change to test/live.go that was previously
applied to test/live_regabi.go in golang.org/cl/415240. This wasn't
noticed at the time though, because GOEXPERIMENT=unified was only
being tested on linux-amd64, which is a regabi platform.
Change-Id: I0c75c2b7097544305e4174c2f5ec6ec283c81a8e
Reviewed-on: https://go-review.googlesource.com/c/go/+/422254
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
`go env GOEXPERIMENT` prints what experiments are enabled relative to
the baseline configuration, so it's not a very robust way to detect
what experiments have been statically enabled at bootstrap time.
Instead, we can check build.Default.ToolTags, which has goexperiment.*
for all currently enabled experiments, independent of baseline.
Change-Id: I6132deaa73b1e79ac24176ef4de5af67a507ee26
Reviewed-on: https://go-review.googlesource.com/c/go/+/422234
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
For signed comparisons, the following four optimization rules hold:
(CMPconst [0] z:(AND x y)) && z.Uses == 1 => (TST x y)
(CMPWconst [0] z:(AND x y)) && z.Uses == 1 => (TSTW x y)
(CMPconst [0] x:(ANDconst [c] y)) && x.Uses == 1 => (TSTconst [c] y)
(CMPWconst [0] x:(ANDconst [c] y)) && x.Uses == 1 => (TSTWconst [int32(c)] y)
But currently they only apply to jump instructions, not to conditional
instructions within a block, such as cset, csel, etc. This CL extends
the above rules into blocks so that conditional instructions can also be
optimized.
name old time/op new time/op delta
DivisiblePow2constI64-160 1.04ns ± 0% 0.86ns ± 0% -17.30% (p=0.008 n=5+5)
DivisiblePow2constI32-160 1.04ns ± 0% 0.87ns ± 0% -16.16% (p=0.016 n=4+5)
DivisiblePow2constI16-160 1.04ns ± 0% 0.87ns ± 0% -16.03% (p=0.008 n=5+5)
DivisiblePow2constI8-160 1.04ns ± 0% 0.86ns ± 0% -17.15% (p=0.008 n=5+5)
Change-Id: I6bc34bff30862210e8dd001e0340b8fe502fe3de
Reviewed-on: https://go-review.googlesource.com/c/go/+/420434
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Eric Fang <eric.fang@arm.com>
This CL adds a test that method expressions where the receiver type is
a derived type and embeds a promoted method work correctly.
Change-Id: I2e7c96007b6d9e6f942dc14228970ac508ff5c15
Reviewed-on: https://go-review.googlesource.com/c/go/+/422199
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The Go 1.18 frontend handles package-scope generic method values by
spilling the receiver value to a global temporary variable, which pins
it into memory. This issue isn't present in unified IR, which uses
OMETHVALUE when the receiver type is statically known.
Updates #54343.
Change-Id: I2c4ffeb125a3cf338f949a93b0baac75fff6cd31
Reviewed-on: https://go-review.googlesource.com/c/go/+/422198
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
As it can't appear in user package paths.
There is a hack for handling "go:buildid" and "type:*" on windows/386.
Previously, windows/386 requires underscore prefix on external symbols,
but that's only applied for SHOSTOBJ/SUNDEFEXT or cgo export symbols.
"go.buildid" is STEXT, "type.*" is STYPE, thus they are not prefixed
with underscore.
In external linking mode, the external linker can't resolve them as
external symbols. But we are lucky that they have "." in their name,
so the external linker see them as Forwarder RVA exports. See:
- https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#export-address-table
- https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/pe-dll.c;h=e7b82ba6ffadf74dc1b9ee71dc13d48336941e51;hb=HEAD#l972)
This CL changes "." to ":" in symbols name, so theses symbols can not be
found by external linker anymore. So a hacky way is adding the
underscore prefix for these 2 symbols. I don't have enough knowledge to
verify whether adding the underscore for all STEXT/STYPE symbols are
fine, even if it could be, that would be done in future CL.
Fixes#37762
Change-Id: I92eaaf24c0820926a36e0530fdb07b07af1fcc35
Reviewed-on: https://go-review.googlesource.com/c/go/+/317917
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Currently there is a an ANDconst and an ANDCCconst op in PPC64,
which is confusing since they map onto the same instruction.
One of these ops sets the result of the AND operation, and the
other sets the flag (condition register).
This converts ANDCCconst into an op with the 2 expected results:
the integer result of the AND and the flag setting. The ANDconst
op has been removed.
Note that in the PPC64 ISA the only variation of the 'and immediate'
is the one that sets the condition bit, which probably led to the
original (confusing) implementation.
This also adds a few rules to improve the use of ANDCCconst with
ISELB and some testcases to verify those improvements.
Change-Id: I523703fa4da2098eb995dc3ba744d36fa28e41d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/422015
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Paul Murphy <murp@ibm.com>
When types2 type checks a method expression or method value that
selects a type parameter method, the Selection.Index is indexed based
on the method's index within the type parameter's constraint
interface.
However, with a fully-stenciled implementation, naively using the
index would result in picking a method from the corresponding type
argument's full method set, which could select a different method.
Unified IR currently avoids this because it selects methods based on
name, not index; but experimenting with index-based selection revealed
that there are no test cases that would have caught this failure case.
Change-Id: Idbc39e1ee741714203d4749e47f5bc015af25020
Reviewed-on: https://go-review.googlesource.com/c/go/+/421815
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
We don't need a multiply when the element type is size 0 or 1.
The panic functions don't return, so we don't need any post-call
code (register restores, etc.).
Change-Id: I0dcea5df56d29d7be26554ddca966b3903c672e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/419754
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
There's no need for a and b to match types. The typechecker already
ensured that a and b are both slices with the same base type, or
a and b are (possibly named) []byte and string.
The optimization to treat append(b, make([], ...)) as a zeroing
slice extension doesn't fire when there's a OCONVNOP wrapping the make.
Fixes#53888
Change-Id: Ied871ed0bbb8e4a4b35d280c71acbab8103691bc
Reviewed-on: https://go-review.googlesource.com/c/go/+/418475
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Run-TryBot: Keith Randall <khr@golang.org>
Same as CL 417555, but for cmd/compile.
Fixes#54220
Change-Id: I4cc6deaf0a87c952f636888b4ab73f81a44bfebd
Reviewed-on: https://go-review.googlesource.com/c/go/+/420975
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
The RType field isn't needed when performing type assertions from
non-empty interface types, because we use the ITab field instead. But
the inline body exporter didn't know to expect this.
It's possible we could use a single bool to distinguish whether
we're serializing the RType or ITab field, but using two is simpler
and seems safer.
Fixes#54302.
Change-Id: I9ddac72784fb2241fee0a0dee30493d868a2c259
Reviewed-on: https://go-review.googlesource.com/c/go/+/421755
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Merge List:
+ 2022-08-04 85d87b9c75 all: update vendored golang.org/x dependencies for Go 1.20 development
+ 2022-08-04 fb1bfd4d37 all: remove pre-Go 1.17 workarounds
+ 2022-08-04 44ff9bff0c runtime: clean up panic and deadlock lock ranks
+ 2022-08-04 f42dc0de74 runtime: make the lock rank DAG make more sense
+ 2022-08-04 d29a0282e9 runtime: add mayAcquire annotation for finlock
+ 2022-08-04 c5be4ed7df runtime: add missing trace lock edges
+ 2022-08-04 2b8a9a484f runtime: generate the lock ranking from a DAG description
+ 2022-08-04 ddfd639408 runtime: delete unused lock ranks
+ 2022-08-04 426ea5702b internal/dag: add a Graph type and make node order deterministic
+ 2022-08-04 d37cc9a8cd go/build, internal/dag: lift DAG parser into an internal package
+ 2022-08-04 ab0a94c6d3 cmd/dist: require Go 1.17 for building Go
+ 2022-08-04 1e3c19f3fe runtime: support riscv64 SV57 mode
+ 2022-08-03 f28fa952b5 make.bat, make.rc: show bootstrap toolchain version
+ 2022-08-03 87384801dc cmd/asm: update package doc to describe "-p" option
+ 2022-08-03 c6a2dada0d net: disable TestIPv6WriteMsgUDPAddrPortTargetAddrIPVersion [sic] on DragonflyBSD
+ 2022-08-02 29b9a328d2 runtime: trivial replacements of g in remaining files
+ 2022-08-02 c647264619 runtime: trivial replacements of g in signal_unix.go
+ 2022-08-02 399f50c9d7 runtime: tricky replacements of g in traceback.go
+ 2022-08-02 4509e951ec runtime: tricky replacements of g in proc.go
+ 2022-08-02 4400238ec8 runtime: trivial replacements of _g_ in remaining files
+ 2022-08-02 5999a28de8 runtime: trivial replacements of _g_ in os files
+ 2022-08-02 0e18cf6d09 runtime: trivial replacements of _g_ in GC files
+ 2022-08-02 4358a53a97 runtime: trivial replacements of _g_ in proc.go
+ 2022-08-02 b486518964 runtime: tricky replacements of _g_ in os3_solaris.go
+ 2022-08-02 54a0ab3f7b runtime: tricky replacements of _g_ in os3_plan9.go
+ 2022-08-02 4240ff764b runtime: tricky replacements of _g_ in signal_windows.go
+ 2022-08-02 8666d89ca8 runtime: tricky replacements of _g_ in signal_unix.go
+ 2022-08-02 74cee276fe runtime: tricky replacements of _g_ in trace.go
+ 2022-08-02 222799fde6 runtime: tricky replacements of _g_ in mgc.go
+ 2022-08-02 e9d7f54a1a runtime: tricky replacements of _g_ in proc.go
+ 2022-08-02 5e8d261918 runtime: rename _p_ to pp
+ 2022-08-02 0ad2ec6596 runtime: clean up dopanic_m
+ 2022-08-02 7e952962df runtime: clean up canpanic
+ 2022-08-02 9dbc0f3556 runtime: fix outdated g.m comment in traceback.go
+ 2022-08-02 d723df76da internal/goversion: update Version to 1.20
+ 2022-08-02 1b7e71e8ae all: disable tests that fail on Alpine
+ 2022-08-01 f2a9f3e2e0 test: improve generic type assertion test
+ 2022-08-01 27038b70f8 cmd/compile: fix wrong dict pass condition for type assertions
+ 2022-08-01 e99f53fed9 doc: move Go 1.19 release notes to x/website
+ 2022-08-01 8b13a073a1 doc: mention removal of cmd/compile's -importmap and -installsuffix flags
+ 2022-08-01 e95fd4c238 doc/go1.19: fix typo: EM_LONGARCH -> EM_LOONGARCH
+ 2022-08-01 dee3efd9f8 doc/go1.19: fix a few links that were missing trailing slashes
+ 2022-07-30 f32519e5fb runtime: fix typos
+ 2022-07-29 9a2001a8cc cmd/dist: always pass -short=true with -quick
+ 2022-07-28 5c8ec89cb5 doc/go1.19: minor adjustments and links
+ 2022-07-28 417be37048 doc/go1.19: improve the loong64 release notes
+ 2022-07-28 027855e8d8 os/exec: add GODEBUG setting to opt out of ErrDot changes
Change-Id: Idc0fbe93978c0dff7600b90a2c3ecc067fd9f5f2
The test added in CL 420394 only tested that the type assertions
compiled at all. This CL changes it into a run test to make sure the
type assertions compile and also run correctly.
Updates #54135.
Change-Id: Id17469faad1bb55ff79b0bb4163ef50179330033
Reviewed-on: https://go-review.googlesource.com/c/go/+/420421
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Keith Randall <khr@golang.org>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Fixes#54135
Change-Id: I2b27af8124014b2699ea44bdc765e1fb8f6c8028
Reviewed-on: https://go-review.googlesource.com/c/go/+/420394
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Merge List:
+ 2022-07-27 462b78fe70 misc/cgo/test: use fewer threads in TestSetgidStress in long mode
+ 2022-07-27 055113ef36 math/big: check buffer lengths in GobDecode
+ 2022-07-27 4248146154 net: document UDPConn.ReadFromUDPAddrPort's AddrPort result more
+ 2022-07-26 faf4e97200 net: fix WriteMsgUDPAddrPort addr handling
+ 2022-07-26 caa225dd29 doc/go1.19: note that updated race syso files require GNU ld 2.26
+ 2022-07-26 ceefd3a37b bytes: document that Reader.Reset affects the result of Size
+ 2022-07-26 3e97294663 runtime/cgo: use frame address to set g0 stack bound
+ 2022-07-25 24dc27a3c0 cmd/compile: fix blank label code
+ 2022-07-25 9fcc8b2c1e runtime: fix runtime.Breakpoint() on windows/arm64
+ 2022-07-25 795a88d0c3 cmd/go: add space after comma in 'go help test'
+ 2022-07-25 9eb3992ddd doc/go1.19: minor fixes
+ 2022-07-25 dcea1ee6e3 time: clarify documentation for allowed formats and add tests to prove them
+ 2022-07-25 37c8112b82 internal/fuzz: fix typo in function comments
+ 2022-07-25 850d547d2d doc/go1.19: expand crypto release notes
+ 2022-07-24 64f2829c9c runtime: fix typo in function comments
+ 2022-07-24 2ff563a00e cmd/compile/internal/noder: correct spelling errors for instantiation
+ 2022-07-22 c5da4fb7ac cmd/compile: make jump table symbol local
+ 2022-07-22 774fa58d1d A+C: delete AUTHORS and CONTRIBUTORS
+ 2022-07-21 2d655fb15a unsafe: document when Sizeof/Offsetof/Alignof are not constant
+ 2022-07-21 076c3d7f07 net/http: remove accidental heading in Head documentation
+ 2022-07-21 c4a6d3048b cmd/dist: enable race detector test on S390X
+ 2022-07-20 244c8b0500 cmd/cgo: allow cgo to pass strings or []bytes bigger than 1<<30
+ 2022-07-20 df38614bd7 test: use go tool from tree, not path
+ 2022-07-20 bb1749ba3b cmd/compile: improve GOAMD64=v1 violation test
+ 2022-07-19 176b63e711 crypto/internal/nistec,debug/gosym: fix typos
Change-Id: I96e5d60039381691dffd841e58927f0afff8c544
When checkEnabled is forced true, the 52278 test fails. Be a bit
more careful about processing blank labels.
Update #52278
Change-Id: I48aa89e2c9e3715d8efe599bc4363b5b5879d8a2
Reviewed-on: https://go-review.googlesource.com/c/go/+/419318
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: David Chase <drchase@google.com>
Some of our tests do exec.Command("go", "tool", "compile", ...) or
similar. That "go" is selected from PATH. When run.go is started
from the command line (but not from all.bash), the first "go" is whatever
happens to be first in the user's path (some random older version than
tip). We really want all these tests to use the "go" tool from the
source tree under test. Add GOROOT/bin to the front of the path to
ensure that the tools we use come from the source tree under test.
Change-Id: I609261a4add8cd5cb228316752d52b5499aec963
Reviewed-on: https://go-review.googlesource.com/c/go/+/418474
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The next CL will change Unified IR's switch statement handling to
convert values to empty interface in some tricky cases. My initial
attempt at this accidentally mishandled `case nil:` in some cases, and
this wasn't caught by any existing tests. So this CL adds one.
Change-Id: Idcfaf0e869dca91be46d665e65d4623dc52bb60f
Reviewed-on: https://go-review.googlesource.com/c/go/+/418099
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
In this test, traditionally the comparison `*l == r[0]` was left as a
comparison between `*l` (type `any`) and `r[0]` (type `*int`), and the
rest of the compiler needed to handle mixed-typed comparisons.
However, this means more complexity for wiring up explicit rtypes.
To simplify rtype handling, the next CL will change unified IR to
instead handle the expression as `*l == any(r[0])`. However, a
consequence of this currently is that walk will now sequence the
`any(r[0])` expression first, because it involves a
concrete-to-interface conversion. And in turn, this means the `r[0]`
panic ("index out of bounds") will take priority over the `*l`
panic ("nil pointer dereference").
This is a change in user-visible semantics in some cases, but the Go
spec leaves this unspecified, so it shouldn't be an issue. Note also:
gccgo has the same behavior (i.e., panicking on index out of bounds,
not nil pointer dereference), and cmd/compile also already has the
same behavior when the interface conversion is explicit (as in the
added "nil pointer dereference #3" test case).
Updates #23735.
Updates #32187.
Change-Id: I49e5dcca85b4680f9c8780ef0013e64254d38fe5
Reviewed-on: https://go-review.googlesource.com/c/go/+/418097
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: David Chase <drchase@google.com>
Conflicts:
- test/run.go
Conflicts in the known-fails list, plus removed a test from the known-fails that now works.
Merge List:
+ 2022-07-19 8e1e64c16a cmd/compile: fix mknode script
+ 2022-07-19 28be440d34 A+C: add Weizhi Yan
+ 2022-07-19 85a482fc24 runtime: revert to using the precomputed trigger for pacer calculations
+ 2022-07-19 ae7340ab68 CONTRIBUTORS: update for the Go 1.19 release
+ 2022-07-18 de8101d21b runtime: fix typos
+ 2022-07-18 967a3d985d cmd/compile: revert "remove -installsuffix flag"
+ 2022-07-18 c0c1bbde17 http: improve Get documentation
+ 2022-07-15 2aa473cc54 go/types, types2: correct alignment of atomic.Int64
+ 2022-07-15 4651ebf961 encoding/gob: s/TestIngoreDepthLimit/TestIgnoreDepthLimit/
+ 2022-07-14 dc00aed6de go/parser: skip TestParseDepthLimit for short tests
+ 2022-07-14 783ff7dfc4 encoding/xml: skip TestCVE202230633 for short tests
+ 2022-07-14 aa80228526 cmd/go/internal/modfetch: avoid duplicating path components in Git fetch errors
+ 2022-07-14 b9d5a25442 cmd/go: save zip sums for downloaded modules in 'go mod download' in a workspace
+ 2022-07-14 a906d3dd09 cmd/go: avoid re-enqueuing workspace dependencies with errors
+ 2022-07-14 266c70c263 doc/go1.19: add a release note for 'go list -json=SomeField'
+ 2022-07-13 558785a0a9 cmd/compile: remove -installsuffix flag
+ 2022-07-13 1355ea3045 cmd/compile: remove -importmap flag
+ 2022-07-13 f71f3d1b86 misc/cgo/testshared: run tests only in GOPATH mode
+ 2022-07-13 feada53661 misc/cgo/testcshared: don't rely on an erroneous install target in tests
+ 2022-07-13 c006b7ac27 runtime: clear timerModifiedEarliest when last timer is deleted
+ 2022-07-13 923740a8cc cmd/compile: fix type assert in dict pass
+ 2022-07-12 bf2ef26be3 cmd/go: in script tests, avoid checking non-main packages for staleness
+ 2022-07-12 5f5cae7200 cmd/go: avoid indexing GOROOT packages when the compiler is 'gccgo'
+ 2022-07-12 c2edb2c841 cmd/go: port TestIssue16471 to a script test and add verbose logging
+ 2022-07-12 9c2526e637 cmd/go/internal/modfetch/codehost: add missing newline in '# lock' log message
+ 2022-07-12 85486bcccb image/jpeg: increase TestLargeImageWithShortData timeout by an order of magnitude
+ 2022-07-12 27794c4d4a cmd/go/internal/modload: ignore disallowed errors when checking for updates
+ 2022-07-12 b2b8872c87 compress/gzip: fix stack exhaustion bug in Reader.Read
+ 2022-07-12 ac68c6c683 path/filepath: fix stack exhaustion in Glob
+ 2022-07-12 fa2d41d0ca io/fs: fix stack exhaustion in Glob
+ 2022-07-12 6fa37e98ea encoding/gob: add a depth limit for ignored fields
+ 2022-07-12 695be961d5 go/parser: limit recursion depth
+ 2022-07-12 08c46ed43d encoding/xml: use iterative Skip, rather than recursive
+ 2022-07-12 c4c1993fd2 encoding/xml: limit depth of nesting in unmarshal
+ 2022-07-12 913d05133c cmd/go: avoid spurious readdir during fsys.Walk
+ 2022-07-12 d3d7998756 net/http: clarify that MaxBytesReader returns *MaxBytesError
+ 2022-07-11 126c22a098 syscall: gofmt after CL 412114
+ 2022-07-11 123a6328b7 internal/trace: don't report regions on system goroutines
+ 2022-07-11 846490110a runtime/race: update amd64 syso images to avoid sse4
+ 2022-07-11 b75ad09cae cmd/trace: fix typo in web documentation
+ 2022-07-11 7510e597de cmd/go: make module index loading O(1)
+ 2022-07-11 b8bf820d5d cmd/nm: don't rely on an erroneous install target in tests
+ 2022-07-11 ad641e8521 misc/cgo/testcarchive: don't rely on an erroneous install target in tests
+ 2022-07-11 bf5898ef53 net/url: use EscapedPath for url.JoinPath
+ 2022-07-11 398dcd1cf0 database/sql: make TestTxContextWaitNoDiscard test more robust
+ 2022-07-11 f956941b0f cmd/go: use package index for std in load.loadPackageData
+ 2022-07-11 59ab6f351a net/http: remove Content-Encoding in writeNotModified
+ 2022-07-08 c1a4e0fe01 cmd/compile: fix libfuzzer instrumentation line number
+ 2022-07-08 5c1a13e7a4 cmd/go: avoid setting variables for '/' and ':' in TestScript subprocess environments
+ 2022-07-08 180bcad33d net/http: wait for listeners to exit in Server.Close and Shutdown
+ 2022-07-08 14abe8aa73 cmd/compile: don't convert to interface{} for un-comparable types in generic switch
+ 2022-07-07 1ebc983000 runtime: overestimate the amount of allocated memory in heapLive
+ 2022-07-07 c177d9d98a crypto/x509: restrict CRL number to <=20 octets
+ 2022-07-07 486fc01770 crypto/x509: correctly parse CRL entry extensions
+ 2022-07-07 8ac58de185 crypto/x509: populate Number and AKI of parsed CRLs
+ 2022-07-07 0c7fcf6bd1 cmd/link: explicitly disable PIE for windows/amd64 -race mode
+ 2022-07-07 eaf2125654 cmd/go: default to "exe" build mode for windows -race
+ 2022-07-06 1243ec9c17 cmd/compile: only check implicit dots for method call enabled by a type bound
+ 2022-07-06 c391156f96 cmd/go: set up git identity for build_buildvcs_auto.txt
+ 2022-07-06 2acd3646fc cmd/compile: rework induction variable detector
+ 2022-07-06 53a4152d47 os/exec: clarify that Wait must be called
+ 2022-07-06 177306f630 cmd/internal/notsha256: add purego tag as needed
+ 2022-07-06 f4755fc733 cmd/dist: use purego tag when building the bootstrap binaries
+ 2022-07-06 4484c30f78 misc/cgo/test: make TestSetgidStress cheaper
+ 2022-07-06 2007599dc8 test: recognize new gofrontend error message
+ 2022-07-05 d602380f58 cmd/compile: drop "buildcfg" from no instrument packages
+ 2022-07-05 c111091071 cmd/go: make module@nonexistentversion failures reusable
+ 2022-07-05 5f305ae8e5 cmd/go: add -reuse flag to make proxy invocations more efficient
+ 2022-07-05 84e091eef0 cmd/go: record origin metadata during module download
+ 2022-07-04 ceda93ed67 build/constraint: update doc to mention a feature added in Go 1.17
+ 2022-07-04 3cf79d9610 runtime: pass correct string to exits on Plan 9
+ 2022-07-01 e822b1e26e net/http: omit invalid header value from error message
+ 2022-07-01 4a2a3bca18 cmd/go, go/build: clarify build constraint docs
+ 2022-07-01 9a4d5357f4 flag: highlight support for double dashes in docs
+ 2022-07-01 c847a2c9f0 go/types, types2: document that exported predicates are unspecified for invalid type arguments
+ 2022-06-30 405c269b85 go/types, types2: re-enable a couple of commented out tests
+ 2022-06-30 aad9382e59 go/doc/comment: support links in lists in comments
+ 2022-06-30 af725f4286 os: fix a typo in path_windows.go
Change-Id: I381728322188aca0bfa81a946d6aedda8c07903c
In filenames, macOS translates Ä (U+00c4, c3 84) to Ä (U+0041 U+0308, 41 cc 88).
This causes problems for run.go's crude rules for testing the compiler.
Fixes#53954.
Change-Id: I850421cbf07e022ca5ff8122e0fb4e80deb55adf
Reviewed-on: https://go-review.googlesource.com/c/go/+/418334
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
For type assertions, if src type is empty interface, we should
use normal type assertions rather than dynamic type assertions.
Fixes#53762
Change-Id: I596b2e4ad647fe5e42ad884f7273c78f8f50dac2
Reviewed-on: https://go-review.googlesource.com/c/go/+/416736
Run-TryBot: Wayne Zuo <wdvxdr@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
