With the previous CL, internal/abi.IntArgRegs and FloatArgRegs
is controlled by RegabiArgs (or always enabled), so there is no
need to check for that goexperiment.
There are a few places we guard register-ABI specific code and
tests with the RegabiArgs flag. Switch to checking for the number
of argument registers instead.
Change-Id: I79fff9fd1e919684ffaf73aba9e7e85d5a9e1629
Reviewed-on: https://go-review.googlesource.com/c/go/+/393363
Trust: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
regabireflect goexperiment was helpful in the register ABI
development, to control code paths for reflect calls, before the
compiler can generate register ABI everywhere. It is not necessary
for now. Drop it.
Change-Id: I2731197d2f496e29616c426a01045c9b685946a4
Reviewed-on: https://go-review.googlesource.com/c/go/+/393362
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Kind(-1).String() used to panic; let's not.
Change-Id: I1dfc0e3298beb37d77713d8327579bbde90dd156
Reviewed-on: https://go-review.googlesource.com/c/go/+/393015
Trust: Russ Cox <rsc@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Modify Value.Bytes to be callable addressable byte arrays.
While related, the behavior of Value.SetBytes was not modified.
Fixes#47066
Change-Id: Ic3ba4432353b8da5f33b3188e20034a33b2f6ee8
Reviewed-on: https://go-review.googlesource.com/c/go/+/357331
Trust: Joseph Tsai <joetsai@digital-static.net>
Reviewed-by: Keith Randall <khr@golang.org>
Run-TryBot: Joseph Tsai <joetsai@digital-static.net>
TryBot-Result: Gopher Robot <gobot@golang.org>
Save some stack space, to avoid nosplit overflow in
-race -N -l build.
For #51247.
Change-Id: I7357d6227f816a612a64f55f7ca1b1384e9268e1
Reviewed-on: https://go-review.googlesource.com/c/go/+/386714
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
And then revert the bootstrap cmd directories and certain testdata.
And adjust tests as needed.
Not reverting the changes in std that are bootstrapped,
because some of those changes would appear in API docs,
and we want to use any consistently.
Instead, rewrite 'any' to 'interface{}' in cmd/dist for those directories
when preparing the bootstrap copy.
A few files changed as a result of running gofmt -w
not because of interface{} -> any but because they
hadn't been updated for the new //go:build lines.
Fixes#49884.
Change-Id: Ie8045cba995f65bd79c694ec77a1b3d1fe01bb09
Reviewed-on: https://go-review.googlesource.com/c/go/+/368254
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
When register ABI is used, reflect.Value.Call prepares the call
arguments in a memory representation of the argument registers.
It has special handling to keep the pointers in arguments live.
Currently, this handles pointer-typed arguments. But when an
argument is an aggregate-type that contains pointers and passed
in registers, it currently doesn't keep the pointers live. Do
so in this CL.
May fix#49363.
Change-Id: Ic6a0c5fdf9375ef02f7c03fbe9345e2e98c9353d
Reviewed-on: https://go-review.googlesource.com/c/go/+/363358
Trust: Cherry Mui <cherryyz@google.com>
Run-TryBot: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
CL 344955 and CL 359476 removed almost all // +build lines, but leaving
some assembly files and generating scripts. Also, some files were added
with // +build lines after CL 359476 was merged. Remove these or rename
files where more appropriate.
For #41184
Change-Id: I7eb85a498ed9788b42a636e775f261d755504ffa
Reviewed-on: https://go-review.googlesource.com/c/go/+/361480
Trust: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Use a pointer reciever to avoid copying the hiter struct when
checking if it is intialized.
Found through profiling that showed reflect map iteration spending
a good amount of time in duffcopy.
This change will also help other MapIter methods checking hiter struct
initialization like Value() and Key().
name old time/op new time/op delta
MapIterNext-12 97.9ns ± 4% 83.8ns ± 2% -14.37% (p=0.000 n=10+10)
Change-Id: I73ab964fa28061ee7e6d5c663a85048bd2e0274e
Reviewed-on: https://go-review.googlesource.com/c/go/+/360254
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Martin Möhrmann <martin@golang.org>
This new function, although different in signature from other
reflect functions, allows the caller to avoid the panic caused by
nil embedded fields in calls to FieldByIndex.
Fixes#48218
Change-Id: I447f135bb789148c27ae3f2f23dcf43094f4c1de
Reviewed-on: https://go-review.googlesource.com/c/go/+/357962
Trust: Rob Pike <r@golang.org>
Run-TryBot: Rob Pike <r@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
When these packages are released as part of Go 1.18,
Go 1.16 will no longer be supported, so we can remove
the +build tags in these files.
Ran go fix -fix=buildtag std cmd and then reverted the bootstrapDirs
as defined in src/cmd/dist/buildtool.go, which need to continue
to build with Go 1.4 for now.
Also reverted src/vendor and src/cmd/vendor, which will need
to be updated in their own repos first.
Manual changes in runtime/pprof/mprof_test.go to adjust line numbers.
For #41184.
Change-Id: Ic0f93f7091295b6abc76ed5cd6e6746e1280861e
Reviewed-on: https://go-review.googlesource.com/c/go/+/344955
Trust: Russ Cox <rsc@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Fixes#49187
Change-Id: I4d8c87af8a709f1b909dd4fae3734d422eb36900
Reviewed-on: https://go-review.googlesource.com/c/go/+/359194
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: Ian Lance Taylor <iant@golang.org>
Fixes#49110
Change-Id: I32c2cb26cca067a4a676ce4bbc3e51f1e0cdb259
Reviewed-on: https://go-review.googlesource.com/c/go/+/357959
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Dan Kortschak <dan@kortschak.io>
Reviewed-by: Sebastien Binet <s@sbinet.org>
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Same as CL 350153 did for Value.Elem to panic on bad notinheap pointers.
While at it, also add more tests for notinheap deref.
Change-Id: Id7d9d12ad8467de5926b6a7e8f9d659fea5fedb5
Reviewed-on: https://go-review.googlesource.com/c/go/+/357630
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>
This is the port of CL 356809 for Value.Pointer to fix the mismatch of
methodValueCall code pointer.
Change-Id: I080ac41b94b44d878cd5896207a76a28c57fd48b
Reviewed-on: https://go-review.googlesource.com/c/go/+/356950
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: Cherry Mui <cherryyz@google.com>
CL 350691 added Value.UnsafePointer and make Value.Pointer call it
internally. It has a downside that Value.Pointer can now eligible to be
inlined, thus making un-intentional side effect, like the test in
fixedbugs/issue15329.go becomes flaky.
This CL restore Value.Pointer original implementation, pre CL 350691,
with the deprecation TODO removed.
Fixes#49067
Change-Id: I735af182f8e729294333ca906ffc062f477cfc99
Reviewed-on: https://go-review.googlesource.com/c/go/+/356949
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>
CL 322350 changed how to take address of assembly functions, using
abi.FuncPCABI0 intrinsic. But we forgot to update the code in
Value.UnsafePointer (was Value.Pointer) to reflect that change.
This CL fixes that bug, and also add a test to make sure the code
pointer is in sync.
Change-Id: I05ae7df31c706583a0f374d8af027066528f5ceb
Reviewed-on: https://go-review.googlesource.com/c/go/+/356809
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: Cherry Mui <cherryyz@google.com>
Allowing eliminates a class of possible misuse of unsafe.Pointer, and
allow callers to migrate from Value.Addr and Value.Pointer, thus they
can be now deprecated.
Fixes#40592
Change-Id: I798e507c748922cac5cc1c1971c1b2cc7095a068
Reviewed-on: https://go-review.googlesource.com/c/go/+/350691
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>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The doc mentions that "UnsafeAddr returns a _pointer_ to v's data", but
it returns a uintptr instead, which don't have pointer semantic.
Change-Id: I557d5597cbc485356ca803eb496a99d6db8c63ba
Reviewed-on: https://go-review.googlesource.com/c/go/+/350690
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: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
This CL fixes the subtle issue that Elem can promote a
not-in-heap pointer, which could be any bit pattern, into an
unsafe.Pointer, which the garbage collector can see. If that
resulting value is bad, it can crash the GC.
Make sure that we don't introduce bad pointers that way. We can
make Elem() panic, because any such bad pointers are in the Go heap,
and not-in-heap pointers are not allowed to point into the Go heap.
Update #48399
Change-Id: Ieaf35a611b16b4dfb5e907e229ed4a2aed30e18c
Reviewed-on: https://go-review.googlesource.com/c/go/+/350153
Trust: Keith Randall <khr@golang.org>
Trust: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Same for Value.
Add a bigger test. Include some shouldPanic checks.
Fix a bug in assignment conversion.
Fixes#48294
Change-Id: Id863ee5122a5787a7b35574b18586fd24d118788
Reviewed-on: https://go-review.googlesource.com/c/go/+/356049
Trust: Keith Randall <khr@golang.org>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
This adds the regabi support needed for reflect including:
- implementation of the makeFuncSub and methodValueCall for
reflect
- implementations of archFloat32FromReg and archFloat32ToReg
needed for PPC64 due to differences in the way float32 are
represented in registers as compared to other platforms
- change needed to stack.go due to the functions that are
changed above
Change-Id: Ida40d831370e39b91711ccb9616492b7fad3debf
Reviewed-on: https://go-review.googlesource.com/c/go/+/352429
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
As discussed in #47658, Value already has CanAddr and CanInterface to
test if a call to Addr or Inteface, respectively, does not result in a
panic.
Therefore we add CanInt, CanUint, CanFloat and CanComplex to ease the
test for a possible panic in calling, respectively, Int, Uint, Float and
Complex.
Fixes#47658
Change-Id: I58b77d77e6eec9f34234e985f631eab72b5b935e
Reviewed-on: https://go-review.googlesource.com/c/go/+/352131
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: David Chase <drchase@google.com>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Instead of growing 2x for < 1024 elements and 1.25x for >= 1024 elements,
use a somewhat smoother formula for the growth factor. Start reducing
the growth factor after 256 elements, but slowly.
starting cap growth factor
256 2.0
512 1.63
1024 1.44
2048 1.35
4096 1.30
(Note that the real growth factor, both before and now, is somewhat
larger because we round up to the next size class.)
This CL also makes the growth monotonic (larger initial capacities
make larger final capacities, which was not true before). See discussion
at https://groups.google.com/g/golang-nuts/c/UaVlMQ8Nz3o
256 was chosen as the threshold to roughly match the total number of
reallocations when appending to eventually make a very large
slice. (We allocate smaller when appending to capacities [256,1024]
and larger with capacities [1024,...]).
Change-Id: I876df09fdc9ae911bb94e41cb62675229cb10512
Reviewed-on: https://go-review.googlesource.com/c/go/+/347917
Trust: Keith Randall <khr@golang.org>
Trust: Martin Möhrmann <martin@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Martin Möhrmann <martin@golang.org>
This change is functionally equivalent, but reduces reliance on unsafe
features. This would allow GopherJS to avoid an additional patch to the
standard library we'd have to maintain in order to remain compatible
with Go 1.17+.
Change-Id: I4f113db0c572ec0b81ebfecf5a137145f6c8c41d
GitHub-Last-Rev: 94ebb393ba
GitHub-Pull-Request: golang/go#48346
Reviewed-on: https://go-review.googlesource.com/c/go/+/349469
Reviewed-by: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
The floating point tests were all added into the Inequalities section,
instead of separated into Equalities vs Inequalities.
Rather than separate them, add a new floating point section.
Change-Id: I3713a5aff5850dcc0caf68a754633d695a03ded9
Reviewed-on: https://go-review.googlesource.com/c/go/+/349612
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Joe Tsai <joetsai@digital-static.net>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Joe Tsai <joetsai@digital-static.net>
Reviewed-by: Joe Tsai <joetsai@digital-static.net>
TryBot-Result: Go Bot <gobot@golang.org>
CL 345486 introduced an optimization to reflect's map accesses
which is not quite correct. We can't use the optimized code if the
value type is >128 bytes.
See cmd/compile/internal/walk/walk.go:mapfast
Fixes#48357
Change-Id: I8e3c7858693083dd4393a8de48ca5fa47bab66f2
Reviewed-on: https://go-review.googlesource.com/c/go/+/349593
Trust: Keith Randall <khr@golang.org>
Trust: Joe Tsai <joetsai@digital-static.net>
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Trust: Martin Möhrmann <martin@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
Run-TryBot: Joe Tsai <joetsai@digital-static.net>
Reviewed-by: Joe Tsai <joetsai@digital-static.net>
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Martin Möhrmann <martin@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Over 80% of all Go map types use a string as the key.
The Go runtime already has a specialized implementation for such maps
in runtime/map_faststr.go. However, the Go reflection implementation
has not historically made use of that implementation.
This CL plumbs the appropriate logic to be accessible from Go reflection
so that it can benefit as well.
name old time/op new time/op delta
Map/StringKeys/MapIndex-4 4.65us ± 5% 2.95us ± 3% -36.50% (p=0.016 n=4+5)
Map/StringKeys/SetMapIndex-4 7.47us ± 5% 5.27us ± 2% -29.40% (p=0.008 n=5+5)
Map/Uint64Keys/MapIndex-4 3.79us ± 3% 3.75us ± 2% ~ (p=0.548 n=5+5)
Map/Uint64Keys/SetMapIndex-4 6.13us ± 3% 6.09us ± 1% ~ (p=0.746 n=5+5)
Change-Id: I5495d48948d8caf2d004a03ae1820ab5f8729670
Reviewed-on: https://go-review.googlesource.com/c/go/+/345486
Trust: Joe Tsai <joetsai@digital-static.net>
Run-TryBot: Joe Tsai <joetsai@digital-static.net>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
Currently on amd64 and arm64, float32 values just live in the bottom 32
bits of the register, so reflect simply places them there in a RegArgs
for reflectcall to load them. This works fine because both of these
platforms don't care what the upper 32 bits are, and have instructions
to operate on float32 values specifically that we use. In sum, the
representation of the float32 in memory is identical to that of the
representation in a register.
On other platforms, however, the representation of FP values differ
depending on whether they're in memory or in a register. For instance,
on ppc64, all floating point values get promoted to a float64 when
loaded to a register (i.e. there's only one set of FP instructions). As
another example, on riscv64, narrow-width floats in registers need to be
NaN-boxed.
What all this means is that for supporting the register ABI on these
platforms, reflect needs to do a little extra work to ensure that the
representation of FP values in a RegArgs matches the representation it
takes on in a register. For this purpose, this change abstracts away the
action of storing values into a RegArgs a little bit and adds a
platform-specific hook which currently does nothing but copy the value.
For #40724.
Change-Id: I65dcc7d86d5602a584f86026ac204564617f4c5a
Reviewed-on: https://go-review.googlesource.com/c/go/+/347566
Trust: Michael Knyszek <mknyszek@google.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
I was a little too agressive in CL 258957 (removing 387 support) in
removing a signaling NaN test that should probably still exist.
I should have just removed the 387 skip, not the entire test.
Change-Id: I97ca53f190eb0de00e43b96629b2cae677e7dacb
Reviewed-on: https://go-review.googlesource.com/c/go/+/348209
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Change-Id: Ic3c69906a8afde63278f173df0427b1c460c9f3e
Reviewed-on: https://go-review.googlesource.com/c/go/+/348189
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>
Update #40724
Change-Id: I110cdb7c4a2c5db6b85ca951143430555261abf3
Reviewed-on: https://go-review.googlesource.com/c/go/+/348017
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This is easier to use in documentation.
Adjust the existing documentation that worked around the unfortunate name.
Change-Id: Ia4b7793ab94dfd7fb3968ee983be56cc38c30ec3
Reviewed-on: https://go-review.googlesource.com/c/go/+/347769
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This allows callers to do (amortized) allocation-free iteration
over many maps.
Fixes#46293
Change-Id: I3aa6134dd00da35b508bd1e3b487332a871a3673
Reviewed-on: https://go-review.googlesource.com/c/go/+/321891
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
This reduces the number of allocations per
reflect map iteration from two to one.
For #46293
Change-Id: Ibcff5f42fc512e637b6e460bad4518e7ac83d4c3
Reviewed-on: https://go-review.googlesource.com/c/go/+/321889
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
reflect.Ptr didn't match reflect.UnsafePointer or unsafe.Pointer
so rename it to reflect.Pointer. Keep reflect.Ptr for compatibility.
Likewise with PtrTo.
Change to use it in std will come in a subsequent CL.
Fixes#47651
Change-Id: I5d4abe2b2fe10948bd68bb12c557165bedffbcba
Reviewed-on: https://go-review.googlesource.com/c/go/+/341333
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Joe Tsai <joetsai@digital-static.net>
Reviewed-by: Robert Griesemer <gri@golang.org>
These augment the existing MapIter.Key and MapIter.Value methods.
The existing methods return new Values.
Constructing these new Values often requires allocating.
These methods allow the caller to bring their own storage.
The naming is somewhat unfortunate, in that the spec
uses the word "element" instead of "value",
as do the reflect.Type methods.
In a vacuum, MapIter.SetElem would be preferable.
However, matching the existing methods is more important.
Fixes#32424Fixes#46131
Change-Id: I19c4d95c432f63dfe52cde96d2125abd021f24fa
Reviewed-on: https://go-review.googlesource.com/c/go/+/320929
Trust: Josh Bleecher Snyder <josharian@gmail.com>
Run-TryBot: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
Some memmoves in reflect/value.go for copying arguments
related to the new ABI were using the address of the target
or source instead of using IntArgRegAddr or FloatArgRegAddr
to adjust the address for big endian.
This was found when testing patches for ppc64 and fixes the
failures that were found.
Change-Id: I119aa090a2a8eb859020ff1a1736107a6d0b76f1
Reviewed-on: https://go-review.googlesource.com/c/go/+/343869
Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Trust: Michael Knyszek <mknyszek@google.com>
Trust: Lynn Boger <laboger@linux.vnet.ibm.com>
Conversion between slices with different element types is not allowed.
Previously (1.8 <= goversion <= 1.16), this conversion was allowed
if the base types were from different packages and had identical names.
Update #47785
Change-Id: I359de5b6fe3ff35bdbf9ab5a13902a0f820cac66
Reviewed-on: https://go-review.googlesource.com/c/go/+/343329
Trust: Keith Randall <khr@golang.org>
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>