Now that this commit[1] has landed in LLVM the .syso file can be generated for
OpenBSD.
With the changes to src/runtime running the sample race[2] detects the data
race as expected.
Based on golang/go#39464 (https://go-review.googlesource.com/c/go/+/237057) from
Aaron Bieber <deftly@gmail.com>, however the race_openbsd_amd64.syso file has
been built on OpenBSD 6.4 and necessary changes added to race.bash.
[1] fcf6ae2f07
[2] https://golang.org/doc/articles/race_detector.html
Change-Id: Ic2479ccfa91d6b2cb4585346a11d813d96450f68
Reviewed-on: https://go-review.googlesource.com/c/go/+/275892
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
There is no dir parameter to (f *subFS).fixErr.
Change-Id: I49e42bac5e102cfab0d289658d9871429cfec515
Reviewed-on: https://go-review.googlesource.com/c/go/+/292389
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Check that the target of a constant load is a register and add test coverage
for this error condition. While here, rename the RISC-V testdata and tests
to be consistent with other platforms.
Change-Id: I7fd0bfcee8cf9df0597d72e65cd74a2d0bfd349a
Reviewed-on: https://go-review.googlesource.com/c/go/+/292895
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Address review comments from earlier changes, which would have previously
caused unwanted conflicts.
Change-Id: If2c61ffe977d721cccf276f931825b003521fda1
Reviewed-on: https://go-review.googlesource.com/c/go/+/284116
Trust: Joel Sing <joel@sing.id.au>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
This CL rebases CL 273987 on top of master with @mdempsky's permission.
The last (only?) use for this feature was 387 support, which was
removed in golang.org/cl/258957.
Change-Id: I4f79fee8d0c336c9b6082bcd5eb6ece52c032dc0
Reviewed-on: https://go-review.googlesource.com/c/go/+/292893
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This CL rebases CL 273694 on top of master with @mdempsky's permission.
For assertE2I and assertI2I, there's no need to pass through the
interface's data pointer: it's always going to come back unmodified.
For assertE2I2 and assertI2I2, there's no need for an extra bool
result parameter: it's redundant with testing the returned interface
value for nil.
Change-Id: Ic92d4409ad381952f875d3d74b8cf11c32702fa6
Reviewed-on: https://go-review.googlesource.com/c/go/+/292892
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Previous CL did remove selectnbrecv2 in runtime, the compiler now only
call selectnbrecv, so remove this. Make this as separated CL because it
adds much of noise to git stat.
Change-Id: I06e89c823c0403e9bd66f2633409c455a46d6e79
Reviewed-on: https://go-review.googlesource.com/c/go/+/292891
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The only different between selectnbrecv and selectnbrecv2 is the later
set the input pointer value by second return value from chanrecv.
So by making selectnbrecv return two values from chanrecv, we can get
rid of selectnbrecv2, the compiler can now call only selectnbrecv and
generate simpler code.
Change-Id: Ifaf6cf1314c4f47b06ed9606b1578319be808507
Reviewed-on: https://go-review.googlesource.com/c/go/+/292890
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Currently, we keep track of slice len by mapping from slice ID to
len/cap SSA value. However, slice len/cap can have multiple SSA values,
so when updating fact table for slice len/cap, we only update in one
place.
Instead, we can take advantage of the transitive relations provided by
poset. So all duplicated slice lens are set as equal to one another.
When updating fact table for one, that fact will be reflected to all
others. The same mechanism is applied for slice cap.
Removes 15 bounds checks from std/cmd.
Fixes#42603
Change-Id: I32c07968824cc33765b1e441b3ae2c4b5f5997c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/273670
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Remove the "// UNREVIEWED" marker and add guards (as in go/types)
to prevent data races. To see the added guards, see compare patch
sets 3 and 4. The equivalent changes for go/types were done in
https://golang.org/cl/294411.
Change-Id: Ibef07eaae400bd32bff32b102cc743580290d135
Reviewed-on: https://go-review.googlesource.com/c/go/+/294510
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
So that would make them last choice for a statement boundary.
This is follow up of CL 273506.
Change-Id: I0203aa0e0d95d538064c2113143c85c4fbb1e65e
Reviewed-on: https://go-review.googlesource.com/c/go/+/273666
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Type string printing special-cased printing of unsafe.Pointer because
it's a built-in type; yet it's declared in a package like any other
imported or used-defined type (unlike built-in types such as int).
Use the same mechanism for printing unsafe.Pointer like any other
(non-basic) type. This will make it possible to use the package
Qualifier if so desired.
Fixes#44515.
Change-Id: I0dd1026f850737ecfc4bb99135cfb8e3c18be9e7
Reviewed-on: https://go-review.googlesource.com/c/go/+/295271
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/conversions.go
and conversions.go can be seen by comparing patchset 1 and 2. The actual
change is just removing the "// UNREVIEWED" marker.
Change-Id: I86d20d8100ec29fe3be996b975c9b4aff01be85e
Reviewed-on: https://go-review.googlesource.com/c/go/+/294509
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
The changes between (equivalent, and reviewed) go/types/issues_test.go
and issues_test.go can be seen by comparing patchset 1 and 3. The actual
change is just removing the "// UNREVIEWED" marker and making making
some minor code adjustments to match go/types's version more closely.
Change-Id: I26f3f700d12db69fc68161a6b0dc081a0e9cd0d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/294473
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
Since we have syntax.Walk, we can make this test work again.
Change-Id: I55cbde7303e5bcbe1123b6679f2ce859d377fd86
Reviewed-on: https://go-review.googlesource.com/c/go/+/294472
Trust: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
CL 274294 improved findTypeLoop but also fixed a new found bug on master
branch. This Cl adds test cases for this.
Updates #44266
Change-Id: Ie4a07a3487758a1e4ad2f2847dcde975b10d2a77
Reviewed-on: https://go-review.googlesource.com/c/go/+/292889
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
For import of functions with closures, the connections among closure
variables are constructed on-the-fly via CaptureName(). For multiple
nested closures, we need to temporarily set r.curfn to each closure we
construct, so that the processing of closure variables will be correct
for any nested closure inside that closure.
Fixes#44335
Change-Id: I34f99e2822250542528ff6b2232bf36756140868
Reviewed-on: https://go-review.googlesource.com/c/go/+/294212
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dan Scales <danscales@google.com>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
On my machine (3.1 GHz Quad-Core Intel Core i7, macOS 10.15.7 10.15.7), go 1.15.6
benchstat:
name old time/op new time/op delta
SearchInts-8 20.3ns ± 1% 16.6ns ± 6% -18.37% (p=0.000 n=9+10)
Change-Id: I346e5955fd6df6ce10254b22267dbc8d5a2b16c0
Reviewed-on: https://go-review.googlesource.com/c/go/+/279439
Reviewed-by: Ben Shi <powerman1st@163.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
Trust: Robert Griesemer <gri@golang.org>
The parser was returning the indexed operand when a slice or index or
instance expression was missing any index arguments (as in the
expression `a[]`). This can result in returning an *ast.Ident for the
LHS of the (invalid) assignment `a[] = ...` -- in this case parsing the
LHS as just `a`. Unfortunately, as the indexed operand `a` has already
been resolved, this results in a panic for duplicate resolution.
Fix this by instead returning an ast.BadExpr. This can suppress some
subsequent errors from the typechecker, but those errors may or may not
be correct anyway. Other interpretations, such as an *ast.IndexExpr with
bad or missing X, run into potential misinterpretations downstream (both
caused errors in go/types and/or gopls).
Fixes#44504
Change-Id: I5ca8bed4a1861bcc7db8898770b08937110981d4
Reviewed-on: https://go-review.googlesource.com/c/go/+/295151
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
In CL 288093 we reserve X15 as the zero register and use that to
zero values. It only covered zeroing generated in SSA but missed
zeroing the frame generated late in the compilation. The latter
still uses X0, but now DUFFZERO expects X15, so it doesn't
actually zero the frame. Change it to use X15.
Should fix#44333.
Change-Id: I239d2b78a5f6468bc86b70aecdd294045311759f
Reviewed-on: https://go-review.googlesource.com/c/go/+/295210
Trust: Cherry Zhang <cherryyz@google.com>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
One CFGs that shortcircuit looks for is:
p q
\ /
b
/ \
t u
The test case creates a CFG like that in which p == t.
That caused the compiler to generate a (short-lived) invalid phi value.
Fix this with a relatively big hammer: Disallow single-length loops entirely.
This is probably overkill, but it such loops are very rare.
This doesn't change the generated code for anything in std.
It generates worse code for the test case:
It no longer compiles the entire function away.
Fixes#44465
Change-Id: Ib8cdcd6cc9d7f48b4dab253652038ace24eae152
Reviewed-on: https://go-review.googlesource.com/c/go/+/295130
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
It was fixed by CL 294289, for #44378.
This is a different style of test that uses
line directives instead of extremely long lines.
Fixes#38698.
Change-Id: I50a1585030978b35fffa9981d6ed96b99216dc3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/295129
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is no-functionality change to begin the process of supporting
more than 6 operands.
This rewrites the table to use named arguments, and removes default
initialized argument values. The following sed regexes rewrote the table:
s/{\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\)}/{as:\1,a1:\2,a2:\3,a3:\4,a4:\5,type_:\6,size:\7,param:\8}
s/a[1-4]: C_NONE, //g
s/, param: 0//
Change-Id: I5f4de9da75f2fb3964d625d6b4e2f1ce1e29cc47
Reviewed-on: https://go-review.googlesource.com/c/go/+/294189
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Carlos Eduardo Seo <carlos.seo@linaro.org>
Change the TestInstallationImporter testpoint to query type
information for sort.Search instead of sort.Ints. The latter function
changed recently (1.16 timeframe), parameter "a" is now "x". A better
candidate for this sort of query is sort.Search, which has been stable
for a while.
Fixes#44425.
Change-Id: I314476eac0b0802f86f5cbce32195cab2926db83
Reviewed-on: https://go-review.googlesource.com/c/go/+/294290
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
DWARF generation uses variable source positions (file/line/col) as a
way to uniquely identify locals and parameters, as part of the process
of matching up post-optimization variables with the corresponding
pre-optimization versions (since the DWARF needs to be in terms of the
original source constructs).
This strategy can run into problems when compiling obfuscated or
machine-generated code, where you can in some circumstances wind up
with two local variables that appear to have the same name, file,
line, and column. This patch changes DWARF generation to skip over
such duplicates as opposed to issuing a fatal error (if an
obfuscation tool is in use, it is unlikely that a human being will be
able to make much sense of DWARF info in any case).
Fixes#44378.
Change-Id: I198022d184701aa9ec3dce42c005d29b72d2e321
Reviewed-on: https://go-review.googlesource.com/c/go/+/294289
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
This permits analysis of the syscall package by tools built with
older versions of Go that do not recognize ios as a GOOS.
Fixes#44459
Change-Id: I79cec2ffe0dbcbc2dc45a385e556dc9e62033125
Reviewed-on: https://go-review.googlesource.com/c/go/+/294634
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Updates #40700
Change-Id: Ifff622ccadaa31c0c0684c3c695aadcaa2305623
Reviewed-on: https://go-review.googlesource.com/c/go/+/294669
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Make all our package sources use Go 1.17 gofmt format
(adding //go:build lines).
Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild
Change-Id: Ia0534360e4957e58cd9a18429c39d0e32a6addb4
Reviewed-on: https://go-review.googlesource.com/c/go/+/294430
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Brings in golang.org/x/tools@2363391a
and adjusts, adds cmd/vet tests accordingly.
Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild
This brings in the new //go:build checks in cmd/vet.
Change-Id: I8a9735cc014171691012b307ec30e94c81aadfe1
Reviewed-on: https://go-review.googlesource.com/c/go/+/240609
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild
Gofmt and any other go/printer-using program will now:
- move //go:build and //+build lines to the appropriate file location
- if there's no //go:build line, add one derived from the // +build lines
- if there is a //go:build line, recompute and replace any // +build lines
to match what the //go:build line says
For Go 1.17.
Change-Id: Ide5cc3b4a07507ba9ed6f8b0de846e840876f49f
Reviewed-on: https://go-review.googlesource.com/c/go/+/240608
Trust: Russ Cox <rsc@golang.org>
Trust: Jay Conrod <jayconrod@google.com>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild
- Reject files with multiple //go:build lines.
- If a file has both //go:build and // +build lines, only use the //go:build line.
- Otherwise fall back to // +build lines
- Use go/build/constraint for parsing both //go:build and // +build lines.
For Go 1.17.
Change-Id: I32e2404d8ce266230f767718dc7cc24e77b425e8
Reviewed-on: https://go-review.googlesource.com/c/go/+/240607
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Something is weird about darwin and TestMorestack,
but it is only manifesting on arm64 and race+amd64.
Disable for now.
Change-Id: I5862372fdd0b5ffae802fdefb65b2aa04e266fcc
Reviewed-on: https://go-review.googlesource.com/c/go/+/294409
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
The spec states that a type "may" have a method set associated with it.
Yet every type has a method set, which may be empty. This is clarified
later in the same paragraph. Be clear in the first sentence as well.
Per the suggestion from https://github.com/DQNEO.
Fixes#44318.
Change-Id: I6097b1c7062853e404b7fead56d18a7f9c576fc3
Reviewed-on: https://go-review.googlesource.com/c/go/+/292853
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In its final phase, the typechecker walks the types it produces to
ensure that no unexpanded type instances leak through the API. However,
this also walks shared types (such as those in the universe scope),
resulting in a potential data race during concurrent typechecking
passes.
Fix this by being careful not to write if nothing needs to be changed.
Since any shared types should already be sanitized, this should
eliminate data races.
For #44434
Change-Id: Iadb2e78863efe0e974e69a00e255f26cfaf9386a
Reviewed-on: https://go-review.googlesource.com/c/go/+/294411
Trust: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Minor adjustment to match go/types more closely.
Change-Id: Id79c51f0ecd8cda0f5b68f6e961500f7f22f7115
Reviewed-on: https://go-review.googlesource.com/c/go/+/294270
Reviewed-by: Robert Findley <rfindley@google.com>
Trust: Robert Griesemer <gri@golang.org>
By default, when typechecking a closure, tcClosure() creates a new
closure function. This should really be done separate from typechecking.
For now, we explicitly avoid creating a new closure function when
typechecking an inline body (in ImportedBody). However, the heuristic
for determining when we are typechecking an inline body was not correct
for double nested closures in an inline body, since CurFunc will then be
the inner closure, which has a body.
So, use a simple global variable to indicate when we typechecking an
inline body. The global variable is fine (just like ir.CurFunc), since
the front-end runs serially.
Fixes#44325
Change-Id: If2829fe1ebb195a7b1a240192b57fe6f04d1a36b
Reviewed-on: https://go-review.googlesource.com/c/go/+/294211
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
The codereview sync-branch command wants all involved
branches to have codereview.cfg, and this will help us when
we transition from master to main later this year.
Change-Id: Ia8e4c8b8c86864ed9d730e5d96be1ff386e2e1cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/294291
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
netbsd/amd64's Syscall9 changes SP using ADD and SUB,
which are treated as SPWRITEs (they are not accounted for
in the sp-adjust tracking, and there are too many functions that
would report mismatched stack adjustments at RET if they were).
A traceback starting in Syscall9 as saved by entersyscall complains
about the SPWRITE-ness unnecessarily, since the PC/SP are saved
at the start of the function. Ignore SPWRITE in that case.
netbsd/arm's Syscall6 also changes SP (R13), using a direct write.
So even if we could handle the ADD/SUB in the amd64 case or
rewrote that assembly, we'd still be stuck with a more difficult
problem in this case. Ignoring the SPWRITE fixes it.
Example crashes:
https://build.golang.org/log/160fc7b051a2cf90782b75a99984fff129329e66https://build.golang.org/log/7879e2fecdb400eee616294285e1f952e5b17301
Change-Id: I0c8e9696066e90dafed6d4a93d11697da23f0080
Reviewed-on: https://go-review.googlesource.com/c/go/+/294072
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
This is failing but only under the race detector.
It doesn't really seem fair to expect pprof to find
specific profile events with the race detector slowing
everything down anyway.
Change-Id: I4b353d3d63944c87884d117e07d119b2c7bf4684
Reviewed-on: https://go-review.googlesource.com/c/go/+/294071
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
We want to print hex exit codes for the large values,
but on 32-bit Windows the large values are negative.
Change-Id: I0e350b128414a9468c93eddc62d660f552c1ee05
Reviewed-on: https://go-review.googlesource.com/c/go/+/294070
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The regabi builders are unhappy about badctxt calling throw
calling systemstack calling gosave_systemstack_switch calling
badctxt, all nosplit, repeating. This wouldn't actually happen
since after one systemstack we'd end up on the system stack
and the next one wouldn't call gosave_systemstack_switch at all.
The badctxt call itself is in a very unlikely assertion failure
inside gosave_systemstack_switch.
Keep the assertion check but call runtime.abort instead on failure,
breaking the detected (but not real) cycle.
Change-Id: Iaf5c0fc065783b8c1c6d0f62d848f023a0714b96
Reviewed-on: https://go-review.googlesource.com/c/go/+/294069
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
When generating DWARF inlined info records, it's possible to have a
local function whose only callsites are inlined away, meaning that we
emit an abstract function DIE but no regular subprogram DIE. When
emitting DWARF scope info we need to handle this case (specifically
when scoping PCs, check for the case that the func in question has
been entirely deleted).
Fixes#44344.
Change-Id: I9f5bc692f225aa4c5c23f7bd2e50bcf7fe4fc5f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/293309
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
An embedded struct field is embedded by mentioning its type.
The fact that the field name may be different and derived
from the type doesn't matter for the struct type.
Do print the embedded type rather than the derived field
name, as we have always done in the past. Remove the fancy
new code which was just plain wrong.
The struct output printing is only relevant for debugging
and test cases. Reverting to the original code (pre-generics)
fixes a couple of x/tools tests.
Unfortunately, the original code is (also) not correct for
embedded type aliases. Adjusted a gccgoimporter test
accordingly and filed issue #44410.
This is a follow-up on https://golang.org/cl/293961 which
addressed the issue only partially and left the incorrect
code in place.
Change-Id: Icb7a89c12ef7929c221fb1a5792f144f7fcd5855
Reviewed-on: https://go-review.googlesource.com/c/go/+/293962
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
