Currently, in the non-DynlinkingGo case with external linking, we generate a
R_X86_64_GOTPCREL relocation for the imported symbol. This results in the
external linker turning this into a R_X86_64_GLOB_DAT relocation, rather
than a R_X86_64_JUMP_SLOT. Always generate R_X86_64_PLT32 for SDYNIMPORT
calls so that these calls work correctly.
Update #36435Fixes#42671
Change-Id: I8a28884b7853cb4135053ed817bedc919482f4ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/270377
Trust: Joel Sing <joel@sing.id.au>
Run-TryBot: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
This CL only adds the new constant, which is not safe for toolstash -cmp.
Change-Id: I774463a0ab5f57113d67a8888b6ac787be68510c
Reviewed-on: https://go-review.googlesource.com/c/go/+/274110
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
These are fairly rote implementations of structs appropriate to
each Op (or group of Ops).
The names of these are unknown except to ir.NodAt for now.
A later, automated change will introduce direct use of the types
throughout package gc.
(This CL is expressions; the previous one was statements.)
This is the last of the Ops that were previously handled by the
generic node struct, so that struct and its methods can be
and are deleted in this CL.
Passes buildall w/ toolstash -cmp.
Change-Id: I1703f35f24dcd3f7c5782a278e53c3fe04e87c37
Reviewed-on: https://go-review.googlesource.com/c/go/+/274109
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
It's not types's responsibility to understand how package
initialization is implemented. Instead, have gc keep track of the
order that packages were imported, and then look for inittask
declarations.
Also, use resolve to force importing of the inittask's export data, so
that we can get the appropriate linker symbol index. (This is also why
this CL doesn't satisfy "toolstash -cmp".)
Change-Id: I5b706497d4a8d1c4439178863b4a8dba4da0f5a9
Reviewed-on: https://go-review.googlesource.com/c/go/+/274006
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
The compile -h flag is *meant* to panic, so you can see the stack
trace where the error is being printed. Make it do that again.
Change-Id: Ieb0042863582d7a4c5d08d2f866a144962915b06
Reviewed-on: https://go-review.googlesource.com/c/go/+/274116
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
These are fairly rote implementations of structs appropriate to
each Op (or group of Ops).
The names of these are unknown except to ir.NodAt for now.
A later, automated change will introduce direct use of the types
throughout package gc.
Passes buildall w/ toolstash -cmp.
Change-Id: Ie9835fcd2b214fda5b2149e187af369d76534487
Reviewed-on: https://go-review.googlesource.com/c/go/+/274108
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The list is no longer needed and can be deleted.
Doing so reduces the inlining cost of any function containing
an explicit call to new by 1 point, so this change is not
toolstash -cmp safe.
Change-Id: Id29e115d68e466a353708ab4b8c1021e9c85a628
Reviewed-on: https://go-review.googlesource.com/c/go/+/274132
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Using expression nodes restricts the set of valid SetOp operations,
because you can't SetOp across representation. Rewrite various code
to avoid crossing those as-yet-unintroduced boundaries.
This also includes choosing a single representation for any given Op.
For example, OCLOSE starts out as an OCALL, so it starts with a List
of one node and then moves that node to Left. That's no good with
real data structures, so the code picks a single canonical implementation
and prepares it during the conversion from one Op to the next.
In this case, the conversion of an OCALL to an OCLOSE now creates
a new node with Left initialized from the start. This pattern repeats.
Passes buildall w/ toolstash -cmp.
Change-Id: I55a0872c614d883cac9d64976c46aeeaa639e25d
Reviewed-on: https://go-review.googlesource.com/c/go/+/274107
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Just a little cleaner to read.
Passes buildall w/ toolstash -cmp.
Change-Id: I27b9f09bf6756f74f1c01794444518ded1a7d625
Reviewed-on: https://go-review.googlesource.com/c/go/+/274106
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Using statement nodes restricts the set of valid SetOp operations,
because you can't SetOp across representation. Rewrite various
code to avoid crossing those as-yet-unintroduced boundaries.
In particular, code like
x, y := v.(T)
x, y := f()
x, y := m[k]
x, y := <-c
starts out with Op = OAS2, and then it turns into a specific Op
OAS2DOTTYPE, OAS2FUNC, OAS2MAPR, OAS2RECV, and then
later in walk is lowered to an OAS2 again.
In the middle, the specific forms move the right-hand side from
n.Rlist().First() to n.Right(), and then the conversion to OAS2 moves
it back. This is unnecessary and makes it hard for these all to
share an underlying Node implementation.
This CL changes these specific forms to leave the right-hand side
in n.Rlist().First().
Similarly, OSELRECV2 is really just a temporary form of OAS2.
This CL changes it to use same fields too.
Finally, this CL fixes the printing of OAS2 nodes in ir/fmt.go,
which formerly printed n.Right() instead of n.Rlist().
This results in a (correct!) update to cmd/compile/internal/logopt's
expected output: ~R0 = <N> becomes ~R0 = &y.b.
Passes buildall w/ toolstash -cmp.
Change-Id: I164aa2e17dc55bfb292024de53d7d250192ad64a
Reviewed-on: https://go-review.googlesource.com/c/go/+/274105
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Apparently, the macOS ARM64 kernel has a bug where when a signal
arrives and the signal stack is not currently faulted in, it may
kill the program with a SIGILL. Work around it by mlock the
signal stacks.
Fixes#42774.
Change-Id: I99a4b3fdb6d8af1c945725ddc2c25568d81c510a
Reviewed-on: https://go-review.googlesource.com/c/go/+/273686
Trust: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
The handling of ONIL and Orig has been a mess for a while, and dates
back to how fmt.go used to print out typed nils. That hasn't applied
for a while, but we've kept dragging it along to appease toolstash
with the intention of someday finally removing it.
Today is that day.
Change-Id: I9a441628e53068ab1993cd2b67b977574d8117b7
Reviewed-on: https://go-review.googlesource.com/c/go/+/274212
Trust: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Fixes#41752
Change-Id: I83520d2303e5fd2e5f6329f092b40e73c13771a1
Reviewed-on: https://go-review.googlesource.com/c/go/+/271908
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Noticed while skimming through recent master commits.
Change-Id: I42a99ea7d71c05fc5b6107627105375a21920f5e
Reviewed-on: https://go-review.googlesource.com/c/go/+/271990
Trust: Daniel Martí <mvdan@mvdan.cc>
Reviewed-by: Jay Conrod <jayconrod@google.com>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This matches the error messages after CL 273890.
syntax/semi4.go:11:9: error: unexpected semicolon or newline, expecting ‘{’ after for clause
syntax/semi4.go:10:13: error: reference to undefined name ‘x’
syntax/semi4.go:12:17: error: reference to undefined name ‘z’
Change-Id: Ic88ff6e27d50bf70f5b2114383b84c42c0682f39
Reviewed-on: https://go-review.googlesource.com/c/go/+/273891
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
shift1.go:76:16: error: shift of non-integer operand
shift1.go:77:16: error: shift of non-integer operand
Change-Id: I48584c0b01f9f6912a93b5f9bba55b5803fbeced
Reviewed-on: https://go-review.googlesource.com/c/go/+/273888
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
As of https://golang.org/cl/273886:
fixedbugs/bug340.go:15:18: error: reference to method ‘x’ in interface with no methods
For golang/go#10700
Change-Id: Id29eb0e34bbb524117614229c4c27cfd17dae286
Reviewed-on: https://go-review.googlesource.com/c/go/+/273887
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
These are plain data now, not nodes (see previous CL).
The opcode deletions are not safe for toolstash -cmp,
so they are split into a separate CL.
Change-Id: Icef8a01e190195a7539a35b92f42835d823e314a
Reviewed-on: https://go-review.googlesource.com/c/go/+/274104
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The type syntax is reused to stand in for the actual type once typechecked,
to avoid updating all the possible references to the original type syntax.
So all these implementations allow changing their Op from the raw syntax
like OTMAP to the finished form OTYPE, even though obviously the
representation does not change.
Passes buildall w/ toolstash -cmp.
Change-Id: I4acca1a5b35fa2f48ee08e8f1e5a330a004c284b
Reviewed-on: https://go-review.googlesource.com/c/go/+/274103
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
This is a general operation on IR nodes, so it belongs in ir.
The copied implementation is adapted to support the
extension pattern, allowing nodes to implement their
own DeepCopy implementations if needed.
This is the first step toward higher-level operations instead
of Left, Right, etc. It will allow the new type syntax nodes
to be properly immutable and opt out of those fine-grained methods.
Passes buildall w/ toolstash -cmp.
Change-Id: Ibd64061e01daf14aebc6586cb2eb2b12057ca85a
Reviewed-on: https://go-review.googlesource.com/c/go/+/274102
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This is not safe for toolstash -cmp and so is split into its own CL.
Change-Id: Ic3254e68fb84a90a11ac5f0b59ef252135c23658
Reviewed-on: https://go-review.googlesource.com/c/go/+/274101
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Now there are no longer any generic nodes with a non-nil
associated Func, so node.fn can be deleted. Also all manipulation
of func fields is done with concrete types, so Node.SetFunc can be
deleted, along with generic implementations.
Passes buildall w/ toolstash -cmp.
Change-Id: I4fee99870951ec9dc224f146d87b22e2bfe16889
Reviewed-on: https://go-review.googlesource.com/c/go/+/274099
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Closures are another reference to Funcs,
and it cleans up the code quite a bit to be clear about types.
OCLOSUREVAR is renamed to OCLOSUREREAD to make
clearer that it is unrelated to the list Func.ClosureVars.
Passes buildall w/ toolstash -cmp.
Change-Id: Id0d28df2d4d6e9954e34df7a39ea226995eee937
Reviewed-on: https://go-review.googlesource.com/c/go/+/274098
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Now that we have specific types for ONAME and ODCLFUNC nodes
(*Name and *Func), use them throughout the compiler to be more
precise about what data is being operated on.
This is a somewhat large CL, but once you start applying the types
in a few places, you end up needing to apply them to many other
places to keep everything type-checking. A lot of code also melts
away as types are added.
Passes buildall w/ toolstash -cmp.
Change-Id: I21dd9b945d701c470332bac5394fca744a5b232d
Reviewed-on: https://go-review.googlesource.com/c/go/+/274097
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Before this CL, an ODCLFUNC Node was represented by both
a node struct and a Func struct (and a Name for the ONAME,
which isn't changing here). Now Func can be repurposed as
the ODCLFUNC implementation, replacing the two structs
totaling 280+144 = 424 bytes (64-bit) with a single 320-byte struct.
Using the *Func as the node also gives us a clear, typed answer to
“which node should we use to represent functions?”
The next CL will clean up uses. This CL is just the trivial
change in representation.
Passes buildall w/ toolstash -cmp.
Change-Id: Ie6d670da91d6eb8d67a85f8f83630b9586dc7443
Reviewed-on: https://go-review.googlesource.com/c/go/+/274096
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
No code changes here, only copying of text.
This will make the diffs in a future CL readable.
Passes buildall w/ toolstash -cmp.
Change-Id: I325a62e79edd82f1437769891ea63a32f51c0170
Reviewed-on: https://go-review.googlesource.com/c/go/+/274095
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Before this CL, an ONAME Node was represented by three structs
linked together: a node, a Name, and a Param. Previous CLs removed
OLABEL and OPACK from the set of nodes that knew about Name.
Now Name can be repurposed to *be* the ONAME Node implementation,
replacing three linked structs totaling 152+64+88 = 304 bytes (64-bit)
with a single 232-byte struct.
Many expressions in the code become simpler as well, without having
to use .Param. and sometimes even .Name().
(For a node n where n.Name() != nil, n.Name() == n.(*Name) now.)
Passes buildall w/ toolstash -cmp.
Change-Id: Ie719f1285c05623b9fd2faaa059e5b360a64b3be
Reviewed-on: https://go-review.googlesource.com/c/go/+/274094
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
OPACK was using a whole Node and Name and Param
to hold about three fields. Give it its own implementation.
Passes buildall w/ toolstash -cmp.
Change-Id: I85a28b43d37183b2062d337b0b1b2eea52884e8c
Reviewed-on: https://go-review.googlesource.com/c/go/+/274093
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
No code changes here, only copying of text.
This will make the diffs in a future CL readable.
Passes buildall w/ toolstash -cmp.
Change-Id: I1b8d8b9ec9408859e36af5ff3bef7c6c10eac0d6
Reviewed-on: https://go-review.googlesource.com/c/go/+/274092
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
These are the first three specific implementations of Node.
They are both a bit of a warmup and also working toward
removing references to Name from Node types other than
the proper named things - ONAME, ONONAME, OTYPE, OLITERAL.
(In this case, BranchStmt and LabelStmt.)
Passes buildall w/ toolstash -cmp.
Change-Id: Ide816b162025ee4c858dd061d7c29ed633fb7baf
Reviewed-on: https://go-review.googlesource.com/c/go/+/274091
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
In preparation for OEMPTY being its own Node implementation,
remove SetOp(OEMPTY) calls that assume other implementations
can be turned into OEMPTY.
Passes buildall w/ toolstash -cmp.
Change-Id: Icac16d12548f35f52a5efa9d09dacf8260f42075
Reviewed-on: https://go-review.googlesource.com/c/go/+/274090
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
These are only needed for a few opcodes, and we can avoid
wasting storage in every implementation by using the extension
interface pattern with a helper function for access.
Of course, in the current codebase, there is only one Node
implementation (*node) and it has these methods, so there
is no danger of a functional change in this particular CL.
Passes buildall w/ toolstash -cmp.
Change-Id: I440c6c232f1fe7b56b852a00dc530f8f49a6b12d
Reviewed-on: https://go-review.googlesource.com/c/go/+/274089
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Start a list of which ops are valid for the default
node struct implementation (currently all of them).
Add a Node implementation helper for a minimal node.
Passes buildall w/ toolstash -cmp.
Change-Id: I7ae45f2cf2be85013cb71ab00524be53f243e13d
Reviewed-on: https://go-review.googlesource.com/c/go/+/274088
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Node.HasOpt is only used once, and that use can use Opt instead.
Interface is one method smaller.
Passes buildall w/ toolstash -cmp.
Change-Id: I6a9d5859a9977a8f4c9db70e166f50f0d8052160
Reviewed-on: https://go-review.googlesource.com/c/go/+/274087
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
- The use of a label's Name.Defn to point at the named for/select/switch
means that any rewrite of the for/select/switch must overwrite the original
or else the pointer will dangle. Remove that pointer by adding the label
name directly to the for/select/switch representation instead.
- The only uses of a label's Sym.Label were ephemeral values during
markbreak and escape analysis. Use a map for each. Although in general
we are not going to replace all computed fields with maps (too slow),
the one in markbreak is only for labeled for/select/switch, and the one
in escape is for all labels, but even so, labels are fairly rare.
In theory this cleanup should make it easy to allow labeled for/select/switch
in inlined bodies, but this CL does not attempt that. It's only concerned
with cleanup to enable a new Node representation.
Passes buildall w/ toolstash -cmp.
Change-Id: I7e36ee98d2ea40dbae94e6722d585f007b7afcfa
Reviewed-on: https://go-review.googlesource.com/c/go/+/274086
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Separating iOS into its own runtime constant broke the logic
here to derive the correct home, cache, and config directories
on iOS devices.
Fixes#42878
Change-Id: Ie4ff57895fcc34b0a9af45554ea3a346447d2e7a
GitHub-Last-Rev: 5e74e64917
GitHub-Pull-Request: golang/go#42879
Reviewed-on: https://go-review.googlesource.com/c/go/+/273947
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
CL 268578 was not formatted properly.
Change-Id: I08d2fc691e4f90a38d8165344c135b7b4f73b339
GitHub-Last-Rev: 6183bb0639
GitHub-Pull-Request: golang/go#42736
Reviewed-on: https://go-review.googlesource.com/c/go/+/271807
Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com>
Reviewed-by: Michael Pratt <mpratt@google.com>
Trust: Michael Pratt <mpratt@google.com>
Trust: Alberto Donizetti <alb.donizetti@gmail.com>
Run-TryBot: Michael Pratt <mpratt@google.com>
On illumos systems, libc can under some conditions make use of files
from /proc. In the case of this test, the creation of new threads was
(in the target thread) causing libc to open and close
"/proc/self/lwp/5/lwpname" to set the thread name, which raced with the
leaking descriptor check (see detailed analysis in #42431).
This change requests that the Go runtime use less threads in the child
process used to check for leaked descriptors, without just disabling the
test. After a thousand repeated trials, the test no longer fails on
illumos.
Fixes#42431.
Change-Id: Iefda26134fc91f7cb205754676e9845d9b7205cc
Reviewed-on: https://go-review.googlesource.com/c/go/+/273966
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
This is blocking forward progress of the de-bitrotting work, and I don't
know off hand how to fix this. Seeing as its disabled on other
platforms, I suspect pprof might not be a very reliable feature, so just
allow for the tests to fail for now, until somebody more motivated comes
along to fix it.
Updates #42862.
Change-Id: Ibc5cd1d82d97b9c2f887d7f3565f2fa70207c8b0
Reviewed-on: https://go-review.googlesource.com/c/go/+/273826
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
These changes match the following gofrontend error messages:
blank1.go:16:1: error: may not define methods on non-local type
chan/perm.go:28:9: error: expected channel
chan/perm.go:29:11: error: left operand of ‘<-’ must be channel
chan/perm.go:69:9: error: argument must be channel
complit1.go:25:16: error: attempt to slice object that is not array, slice, or string
complit1.go:26:16: error: attempt to slice object that is not array, slice, or string
complit1.go:27:17: error: attempt to slice object that is not array, slice, or string
complit1.go:49:41: error: may only omit types within composite literals of slice, array, or map type
complit1.go:50:14: error: expected struct, slice, array, or map type for composite literal
convlit.go:24:9: error: invalid type conversion (cannot use type unsafe.Pointer as type string)
convlit.go:25:9: error: invalid type conversion (cannot use type unsafe.Pointer as type float64)
convlit.go:26:9: error: invalid type conversion (cannot use type unsafe.Pointer as type int)
ddd1.go:63:9: error: invalid use of ‘...’ calling non-variadic function
fixedbugs/bug176.go:12:18: error: index expression is not integer constant
fixedbugs/bug332.go:17:10: error: use of undefined type ‘T’
fixedbugs/issue4232.go:22:16: error: integer constant overflow
fixedbugs/issue4232.go:33:16: error: integer constant overflow
fixedbugs/issue4232.go:44:25: error: integer constant overflow
fixedbugs/issue4232.go:55:16: error: integer constant overflow
fixedbugs/issue4458.go:19:14: error: type has no method ‘foo’
fixedbugs/issue5172.go:24:14: error: too many expressions for struct
init.go:17:9: error: reference to undefined name ‘runtime’
initializerr.go:26:29: error: duplicate value for index 1
interface/explicit.go:60:14: error: type assertion only valid for interface types
label.go:64:9: error: reference to undefined label ‘go2’
label1.go:18:97: error: continue statement not within for
label1.go:22:97: error: continue statement not within for
label1.go:106:89: error: continue statement not within for
label1.go:108:26: error: invalid continue label ‘on’
label1.go:111:118: error: break statement not within for or switch or select
label1.go:113:23: error: invalid break label ‘dance’
map1.go:64:9: error: not enough arguments
map1.go:65:9: error: not enough arguments
map1.go:67:9: error: argument 1 must be a map
method2.go:36:11: error: reference to undefined field or method ‘val’
method2.go:37:11: error: reference to undefined field or method ‘val’
method2.go:41:12: error: method requires pointer (use ‘(*T).g’)
syntax/chan1.go:13:19: error: send statement used as value; use select for non-blocking send
syntax/chan1.go:17:11: error: send statement used as value; use select for non-blocking send
Change-Id: I98047b60a376e3d2788836300f7fcac3f2c285cb
Reviewed-on: https://go-review.googlesource.com/c/go/+/273527
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
If the linker thinks that it's in exe mode instead of pie mode, it
won't emit relocations when generating the pcln table, and we wind
up with crashes like this on windows/arm, where all binaries are
in fact relocated:
Building Go toolchain2 using go_bootstrap and Go toolchain1.
fatal error: minpc or maxpc invalid
runtime: panic before malloc heap initialized
This problem was already solved by darwin/arm64, so solve it the same
way here for windows/arm.
Fixes CL 228478.
Fixes#42786.
Change-Id: I6d1db6907c131183649fc263ccca06783188f344
Reviewed-on: https://go-review.googlesource.com/c/go/+/273566
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Apparently we're being called on arm 1 byte off, just like on 386 and
amd64, so unify the handler for isAbortPC.
Fixes#42859.
Updates #29050.
Change-Id: I97fffeb4a33d93ca3397ce1c9ba2b05137f391ca
Reviewed-on: https://go-review.googlesource.com/c/go/+/273727
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
Reviewed-by: Alex Brainman <alex.brainman@gmail.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
This function's prototype includes a return value, so return a value.
Otherwise clang gets upset:
--- FAIL: TestDLLPreloadMitigation (1.40s)
syscall_windows_test.go:986: failed to build dll: exit status 1 - nojack.c:7:1: error: non-void function does not return a value [-Werror,-Wreturn-type]
}
^
1 error generated.
Fixes#42860.
Change-Id: I65b8eb9ccb502692c5b65bd34829f331cd86eef0
Reviewed-on: https://go-review.googlesource.com/c/go/+/273726
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
None of the other, older, doc comments use the '*Logger' form, and while
'Logger' and 'logger' are both used in the package doc comment, the
common term used with the intended meaning is 'standard logger', which
appears another eleven times in doc comments.
Change-Id: I089103198fc82390517615eb27bbe7ef77107d34
Reviewed-on: https://go-review.googlesource.com/c/go/+/273486
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
The bug was introduced by https://golang.org/cl/220844.
Updates #42792.
Fixes#42835.
Change-Id: I03065c7526488aded35ef2f800b7162e1606877a
Reviewed-on: https://go-review.googlesource.com/c/go/+/273326
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
