The prealloc map seems to exist to avoid adding a field to all nodes.
Now we can add a field to just the nodes that need the field,
so let's do that and avoid having a magic global with extra node state
that isn't preserved by operations like Copy nor printed by Dump.
This also makes clear which nodes can be prealloc'ed.
In particular, the code in walkstmt looked up an entry in
prealloc using an ONAME node, but there's no code that
ever stores such an entry, so the lookup never succeeded.
Having fields makes that kind of thing easier to see and fix.
Passes buildall w/ toolstash -cmp.
Change-Id: I418ad0e2847615c08868120c13ee719dc0b2eacb
Reviewed-on: https://go-review.googlesource.com/c/go/+/278915
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>
For globals, Name.Offset is used as a way to address a field within
a global during static initialization. This CL replaces that use with
a separate NameOffsetExpr (ONAMEOFFSET) node.
For locals, Name.Offset is the stack frame offset. This CL calls it
that (FrameOffset, SetFrameOffset).
Now there is no longer any use of Name.Offset or Name.SetOffset.
And now that copies of Names are not being made to change their
offsets, we can lock down use of ir.Copy on Names. The only
remaining uses are during inlining and in handling generic system
functions. At both those times you do want to create a new name
and that can be made explicit by calling the new CloneName method
instead. ir.Copy on a name now panics.
Passes buildall w/ toolstash -cmp.
Change-Id: I0b0a25b9d93aeff7cf4e4025ac53faec7dc8603b
Reviewed-on: https://go-review.googlesource.com/c/go/+/278914
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>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on sinit.go.
Passes buildall w/ toolstash -cmp.
Change-Id: I3e9458e69a7a9b3f2fe139382bf961bc4473cc42
Reviewed-on: https://go-review.googlesource.com/c/go/+/277928
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>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on walk.go.
Passes buildall w/ toolstash -cmp.
Change-Id: I7aab57e4077cf10da1994625575c5e42ad114a9c
Reviewed-on: https://go-review.googlesource.com/c/go/+/277921
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>
ir.Find is called "any" in C#, Dart, Haskell, Python, R, Ruby, and Rust,
and "any_of" in C++, "anyMatch" in Java, "some" in JavaScript,
"exists in OCaml, and "existsb" in Coq.
(Thanks to Matthew Dempsky for the research.)
This CL changes Find to Any to use the mostly standard name.
It also updates wrapper helpers to use the any terminology:
hasCall -> anyCall
hasCallOrChan -> anyCallOrChan
hasSideEffects -> anySideEffects
Unchanged are "hasNamedResults", "hasUniquePos", and "hasDefaultCase",
which are all about a single node, not any node in the IR tree.
I also renamed hasFall to endsInFallthrough, since its semantics are
neither that of "any" nor that of the remaining "has" functions.
So the new terminology helps separate different kinds of predicates nicely.
Change-Id: I9bb3c9ebf060a30447224be09a5c34ad5244ea0d
Reviewed-on: https://go-review.googlesource.com/c/go/+/278912
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>
Test failures started to happen sporadically on some builds after the introduction of NotifyContext.
To make these tests more robust and avoid the risk of crosstalk we run them in a separate process.
Fixes#41561.
Change-Id: Ia7af105c316afd11765358f1e5e253ccfe2adc2b
Reviewed-on: https://go-review.googlesource.com/c/go/+/270198
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Bryan C. Mills <bcmills@google.com>
Trust: Cherry Zhang <cherryyz@google.com>
When doing external linking on Windows, auto-detect the linker flavor
(bfd vs gold vs lld) and when linking with "lld", avoid the use of
"-T" (linker script), since this option is not supported by lld.
[Note: the Go linker currently employs -T to ensure proper placement
of the .debug_gdb_scripts section, to work around issues in older
versions of binutils; LLD recognizes this section and does place it
properly].
Updates #39326.
Change-Id: I3ea79cdceef2316bf86eccdb60188ac3655264ed
Reviewed-on: https://go-review.googlesource.com/c/go/+/278932
Trust: Than McIntosh <thanm@google.com>
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Change the run.go driver to recognize the "gc" build tag.
Change existing tests to use the "gc" build tag if they use some
feature that seems specific to the gc compiler, such as passing specific
options to or expecting specific behavior from "go tool compile".
Change tests to use the "!gccgo" build tag if they use "go build" or
"go run", as while those might work with compilers other than gc, they
won't work with the way that gccgo runs its testsuite (which happens
independently of the go command).
For #43252
Change-Id: I666e04b6d7255a77dfc256ee304094e3a6bb15ad
Reviewed-on: https://go-review.googlesource.com/c/go/+/279052
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
CL 269697 was created before CL 276454 and submitted after,
so the api/go1.16.txt file needs to be updated accordingly
to fix the build.
Updates #32406.
Change-Id: I6bf79cc981be504e0baefa82982814aaee4434dc
Reviewed-on: https://go-review.googlesource.com/c/go/+/278992
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Trust: Katie Hockman <katie@golang.org>
Reviewed-by: Katie Hockman <katie@golang.org>
Change-Id: Id7d242ddd4b80a763787513d0a658dd7aea9db7d
Reviewed-on: https://go-review.googlesource.com/c/go/+/276454
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Alexander Rakoczy <alex@golang.org>
Reviewed-by: Carlos Amedee <carlos@golang.org>
Previous CL uses OSELRECV2 instead of OSELRECV, this CL removes it.
Make this a separated CL as it's not safe for toolstash.
Change-Id: I530ba33fd9311904545e40fe147829af629cf4a8
Reviewed-on: https://go-review.googlesource.com/c/go/+/275459
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: Russ Cox <rsc@golang.org>
OSELRECV2 can represent all possible receive clauses that can appear
in a select statement, and it simplifies later code, so use it instead.
Follow up CL will remove OSELRECV.
Passes buildall w/ toolstash -cmp.
Change-Id: Ibbdae45287ffd888acd8dc89ca8d99e454277cd1
Reviewed-on: https://go-review.googlesource.com/c/go/+/275458
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: Russ Cox <rsc@golang.org>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL handles all the little files that are left.
Passes buildall w/ toolstash -cmp.
Change-Id: I6588c92dbbdd37342a77b365d70e02134a033d2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/277932
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on noder.go.
Passes buildall w/ toolstash -cmp.
Change-Id: Ie870126b51558e83c738add8e91a2804ed6d7f92
Reviewed-on: https://go-review.googlesource.com/c/go/+/277931
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on subr.go.
Passes buildall w/ toolstash -cmp.
Change-Id: I435082167c91e20a4d490aa5d5945c7454f71d61
Reviewed-on: https://go-review.googlesource.com/c/go/+/277930
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on range.go, select.go, and swt.go: the big
control structures.
Passes buildall w/ toolstash -cmp.
Change-Id: I033fe056a7b815edb6e8a06f45c12ffd990f4d45
Reviewed-on: https://go-review.googlesource.com/c/go/+/277929
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on const.go.
Passes buildall w/ toolstash -cmp.
Change-Id: I824f18fa0344ddde56df0522f9fa5e237114bbe2
Reviewed-on: https://go-review.googlesource.com/c/go/+/277927
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on inl.go.
Passes buildall w/ toolstash -cmp.
Change-Id: Iaaee7664cd43e264d9e49d252e3afa7cf719939b
Reviewed-on: https://go-review.googlesource.com/c/go/+/277926
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on iimport.go and iexport.go.
Passes buildall w/ toolstash -cmp.
Change-Id: I63edee54991ae5d982e99efa7a2894478d511910
Reviewed-on: https://go-review.googlesource.com/c/go/+/277925
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on escape.go.
Passes buildall w/ toolstash -cmp.
Change-Id: I3e76e1ef9b72f28e3adad9633929699635d852dd
Reviewed-on: https://go-review.googlesource.com/c/go/+/277924
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on ssa.go.
Passes buildall w/ toolstash -cmp.
Change-Id: Iefacc7104dd9469e3c574149791ab0bff29f7fee
Reviewed-on: https://go-review.googlesource.com/c/go/+/277923
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on order.go.
Passes buildall w/ toolstash -cmp.
Change-Id: Ib5731905a620175a6fe978f512da593e0dae9d87
Reviewed-on: https://go-review.googlesource.com/c/go/+/277922
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL focuses on typecheck.go.
Passes buildall w/ toolstash -cmp.
Change-Id: I32d1d3b813b0a088b1750c9fd28cd858ed813f1d
Reviewed-on: https://go-review.googlesource.com/c/go/+/277920
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
It seems clear after using these for a week that Find need not return
anything other than a bool saying whether the target was found.
The main reason for not using the boolean earlier was to avoid confusion
with Inspect: for Find, returning true means "it was found! stop walking"
while for Inspect, returning true means "keep walking the children".
But it turns out that none of the uses of Inspect need the boolean.
This makes sense because types can contain expressions, expressions
can contain statements (inside function literals), and so on, so there
are essentially no times when you can say based on the current AST node
that the children are irrelevant to a particular operation.
So this CL makes two changes:
1) Change Find to return a boolean and to take a callback function
returning a boolean. This simplifies all existing calls to Find.
2) Rename Inspect to Visit and change it to take a callback with no
result at all. This simplifies all existing calls to Inspect.
Removing the boolean result from Inspect's callback avoids having
two callbacks with contradictory boolean results in different APIs.
Renaming Inspect to Visit avoids confusion with ast.Inspect.
Passes buildall w/ toolstash -cmp.
Change-Id: I344ebb5e00b6842012be33e779db483c28e5f350
Reviewed-on: https://go-review.googlesource.com/c/go/+/277919
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The general concept of an "implicit" operation is provided by every
expr representation, but it really only makes sense for a few of them,
and worse the exact definition of what "implicit" means differs from
node to node.
This CL moves the method to each node implementation, although
they all share the same header bit instead of each defining a bool field
that would turn into 8 bytes on 64-bit systems.
Now we can say precisely which Nodes have a meaningful Implicit
method: AddrExpr, CompLitExpr, ConvExpr, ParenExpr, and StarExpr.
Passes buildall w/ toolstash -cmp.
Change-Id: I7d85cb0507a514cdcb6eed21347f362e5fb57a91
Reviewed-on: https://go-review.googlesource.com/c/go/+/277918
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The initorder pass is already making heavy use of maps,
and it is concerned with relatively few nodes (only the assignments
in package-level variable declarations). The tracking of init order
for these nodes can be done with another map instead of storing
the bits directly in the Node representations.
This will let us drop Offset_ from AssignStmt and AssignListStmt
and drop Initorder from all nodes.
Passes buildall w/ toolstash -cmp.
Change-Id: I151c64e84670292c2004da4e8e3d0660a88e3df3
Reviewed-on: https://go-review.googlesource.com/c/go/+/277917
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
The Nodes type originally served two purposes:
(1) It provided a representation optimized for empty slices,
allocating only a single word in that case instead of three,
at the cost of a non-empty slice being four words instead of three.
This was particularly important with the old Node representation,
in which most Nodes were full of unused fields.
(2) It provided a few useful helper methods beyond what can be
done with slices.
The downside of Nodes is that the API is a bit overwhelming,
with many ways to spell ordinary slice operations. For example,
reassigning the first node in the list can be done with:
ns.Slice()[0] = n
ns.SetIndex(0, n)
ns.SetFirst(n)
*ns.Addr(0) = n
And APIs must decide whether to use Nodes or []ir.Node and
then conversions must be inserted when crossing the boundary.
Now that Node structs are specialized to opcode and most Nodes
lists are actually non-empty, it makes sense to simplify Nodes
to make it actually a slice type, so that ordinary slice operations can
be used, and assignments can automatically convert between
Nodes and []ir.Node.
This CL changes the representation to be a slice and adds a new
Take method, which returns the old slice and clears the receiver.
In a future CL, the Nodes method set will simplify down to:
Copy
Take
Append
Prepend
Format
with the current methods being rewritten:
ns.Len() -> len(ns)
ns.Slice() -> ns
ns.First() -> ns[0]
ns.Second() -> ns[1]
ns.Index(i) -> ns[i]
ns.Addr(i) -> &ns[i]
ns.SetIndex(i, n) -> ns[i] = n
ns.SetFirst(n) -> ns[0] = n
ns.SetSecond(n) -> ns[1] = n
ns.Set1(n) -> ns = []Node{n}
ns.Set2(n, n2) -> ns = []Node{n, n2}
ns.Set3(n, n2, n3) -> ns = []Node{n, n2, n3}
AsNodes(slice) -> Nodes(slice)
ns.AppendNodes(pns) -> ns.Append(pns.Take()...)
ns.MoveNodes(pns) -> ns = pns.Take()
and then all those other methods will be deleted.
Simplifying the API down to just those five methods will also make it
more reasonable to introduce more specialized slices like Exprs and Stmts
at some point in the future.
But again this CL just changes the representation to a slice,
introduces Take, and leaves the rest alone.
Passes buildall w/ toolstash -cmp.
Change-Id: I309ab8335c69bb582d811c92c17f938dd6e0c4fe
Reviewed-on: https://go-review.googlesource.com/c/go/+/277916
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite will add concrete type assertions after
a test of n.Op(), when n can be safely type-asserted
(meaning, n is not reassigned a different type, n is not reassigned
and then used outside the scope of the type assertion,
and so on).
This sequence of CLs handles the code that the automated
rewrite does not: adding specific types to function arguments,
adjusting code not to call n.Left() etc when n may have multiple
representations, and so on.
This CL handles package fmt. There are various type assertions
but also some rewriting to lean more heavily on reflection.
Passes buildall w/ toolstash -cmp.
Change-Id: I503467468b42ace11bff2ba014b03cfa345e6d03
Reviewed-on: https://go-review.googlesource.com/c/go/+/277915
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
I haven't measured this, but it's the only use of EditChildren
where we aren't careful to allocate a closure once and use it
for the whole recursion. This one is allocating a closure at
every level of the recursion, and it was an oversight that it
wasn't cleaned up in the original CL.
Passes buildall w/ toolstash -cmp.
Change-Id: I5e3f1795c6f64c5867a19c077f797643aa1066a3
Reviewed-on: https://go-review.googlesource.com/c/go/+/277914
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
An automated rewrite is going to remove the bulk of the calls
to ir.Nod and friends. This CL takes care of the ones that don't
have fixed opcodes and so aren't amenable to automatic rewriting.
Passes buildall w/ toolstash -cmp.
Replay of CL 275886, lost to the bad-merge history rewrite.
Change-Id: I5bf8d1d182f847f4ab44b7e278b752913e30e4c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/277956
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Avoid using the same variable for two different concrete
Node types in other files (beyond walk). This will smooth the
introduction of specific constructors, replacing ir.Nod and friends.
Passes buildall w/ toolstash -cmp.
Replay of CL 275885, lost to the bad-merge history rewrite.
Change-Id: I0da89502a0bd636b8766f01b6f843c7821b3e9ab
Reviewed-on: https://go-review.googlesource.com/c/go/+/277955
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Avoid using the same variable for two different concrete
Node types in walk. This will smooth the introduction of
specific constructors, replacing ir.Nod and friends.
Passes buildall w/ toolstash -cmp.
Replay of CL 275884, lost to the bad-merge history rewrite.
Change-Id: I05628e20a19c9559ed7478526ef6cb2613f735e5
Reviewed-on: https://go-review.googlesource.com/c/go/+/277954
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This is a port of CL 278132 from the dev.typeparams branch. A notable
addition is a new error code, since no existing codes made sense and we
have an analogous code for type switches.
Fixes#43110
Change-Id: I22b3f9d8777063223f82785504e8b7d299bc5216
Reviewed-on: https://go-review.googlesource.com/c/go/+/278813
Run-TryBot: Robert Findley <rfindley@google.com>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Robert Findley <rfindley@google.com>
Mach-O relocation addend is signed 24-bit. When external linking,
if the addend is larger, we cannot put it directly into a Mach-O
relocation. This CL handles large addend by creating "label"
symbols at sym+0x800000, sym+(0x800000*2), etc., and emitting
Mach-O relocations that target the label symbols with a smaller
addend. The label symbols are generated late (similar to what
we do for RISC-V64).
One complexity comes from handling of carrier symbols, which does
not track its size or its inner symbols. But relocations can
target them. We track them in a side table (similar to what we
do for XCOFF, xcoffUpdateOuterSize).
Fixes#42738.
Change-Id: I8c53ab2397f8b88870d26f00e9026285e5ff5584
Reviewed-on: https://go-review.googlesource.com/c/go/+/278332
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>
When testing if a flag (e.g. "-no-pie") is supported by the
external linker, pass arch-specific flags (like "-marm").
In particular, on the ARM builder, if CGO_LDFLAGS=-march=armv6
is set, the C toolchain fails to build if -marm is not passed.
# cc -march=armv6 1.c
1.c: In function 'main':
1.c:3:1: sorry, unimplemented: Thumb-1 hard-float VFP ABI
int main() {
^~~
This makes the Go linker think "-no-pie" is not supported when it
actually is.
Passing -marm makes it work.
Fixes#43202.
Change-Id: I4e8b71f08818993cbbcb2494b310c68d812d6b50
Reviewed-on: https://go-review.googlesource.com/c/go/+/278592
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>
The code in the new (introduced in 1.15) Go object file reader was
casting a pointer-mmaped-memory into a large array prior to performing
a read of the relocations section:
return (*[1<<20]Reloc)(unsafe.Pointer(&r.b[off]))[:n:n]
For very large object files, this artificial array isn't large enough
(that is, there are more than 1048576 relocs to read), so update the
code to use a larger artifical array size.
Fixes#41621.
Change-Id: Ic047c8aef4f8a3839f2e7e3594bce652ebd6bd5b
Reviewed-on: https://go-review.googlesource.com/c/go/+/278492
Run-TryBot: Than McIntosh <thanm@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Reviewed-by: Jeremy Faller <jeremy@golang.org>
Trust: Than McIntosh <thanm@google.com>
For #40700.
Change-Id: I67dd55b435304e428929c9a54b8881f9b78efdfb
Reviewed-on: https://go-review.googlesource.com/c/go/+/278392
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The transponder sets up a deferred close on accepted connections which
is fine after the client reads all data. However there are no mutexes
nor channels to block the transponder from closing. If the scheduler
runs close before the client read, it will cause an EOF failure.
Fixes#42720
Change-Id: Ic21b476c5efc9265a80a2c6f8484efdb5af66405
Reviewed-on: https://go-review.googlesource.com/c/go/+/273672
Run-TryBot: Meng Zhuo <mzh@golangcn.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Meng Zhuo <mzh@golangcn.org>
Reviewed-by: Damien Neil <dneil@google.com>
Microsoft's linker looks at whether all input objects have an empty
section called @feat.00. If all of them do, then it enables SEH;
otherwise it doesn't enable that feature. So, since around the Windows
XP SP2 era, most tools that make PE objects just tack on that section,
so that it won't gimp Microsoft's linker logic. Go doesn't support SEH,
so in theory, none of this really matters to us. But actually, if the
linker tries to ingest an object with @feat.00 -- which are produced by
LLVM's resource compiler, for example -- it chokes because of the
IMAGE_SYM_ABSOLUTE section that it doesn't know how to deal with. Since
@feat.00 is just a marking anyway, skip IMAGE_SYM_ABSOLUTE sections that
are called @feat.00.
Change-Id: I1d7bfcf6001186c53e2c487c5ac251ca65efefee
Reviewed-on: https://go-review.googlesource.com/c/go/+/268239
Run-TryBot: Jason A. Donenfeld <Jason@zx2c4.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
Trust: Alex Brainman <alex.brainman@gmail.com>
Trust: Jason A. Donenfeld <Jason@zx2c4.com>
The gofrontend code sees that the denominator is not zero,
so it computes the values. Dividing zero by a non-zero value
produces zero. The language spec doesn't require any of these
cases to report an error, so make the errors compiler-specific.
Change-Id: I5ed759a3121e38b937744d32250adcbdf2c4d3c2
Reviewed-on: https://go-review.googlesource.com/c/go/+/278117
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
The bug429 tests is an exact duplicate of TestSimpleDeadlock in the
runtime package. The runtime package is the right place for this test,
and the version in the runtime package will run faster as the build
step is combined with other runtime package tests.
Change-Id: I6538d24e6df8e8c5e3e399d3ff37d68f3e52be56
Reviewed-on: https://go-review.googlesource.com/c/go/+/278173
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
The language spec only requires that floating point values be
represented with 256 bits, which is about 1e75. The issue11371 test
was assuming that the compiler could represent 1e100. Adjusting the
test so that it only assumes 256 bits of precision still keeps the
test valid, and permits it to pass when using the gofrontend.
Change-Id: I9d1006e9adc9438277f4b8002488c912e5d61cc1
Reviewed-on: https://go-review.googlesource.com/c/go/+/278116
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
With the gc compiler the import path implies the package path,
so keeping a canonical path is important. With the gofrontend
this is not the case, so we don't need to report this as a bug.
Change-Id: I245e34f9b66383bd17e79438d4b002a3e20aa994
Reviewed-on: https://go-review.googlesource.com/c/go/+/278115
Trust: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Cherry Zhang <cherryyz@google.com>
