spec: allow conversion from slice to array #46505

bradfitz · 2021-06-01T22:48:01Z

I recently tried to use the new #395 feature (for converting a slice to an array pointer: https://golang.org/cl/216424) in:

https://go-review.googlesource.com/c/go/+/322329

But in review, it was pointed out that it was a little ugly, as what I wanted to return was an array, which required a dereference:

	return *(*[Size224]byte)(sum[:Size224])

It would've been nicer if I could've just converted to an array instead:

	return ([Size224]byte)(sum[:Size224])

Talking to @ianlancetaylor and @griesemer, we couldn't remember great reasons for not also allowing this as part of #395. It does mean there's an subtle copy, but arguably the * dereference above is also a somewhat subtle copy.

Could we also add support for converting to the array?

/cc @katiehockman @josharian @rogpeppe @mdempsky

The text was updated successfully, but these errors were encountered:

randall77 · 2021-06-01T23:03:19Z

Note the [:Size224] is unnecessary. There, I saved you more characters than the 2 *s you were worried about!

I think the decision to omit direct-to-array casts was just to keep the feature change minimal. We need the cast-to-pointer regardless to support aliasing to the same backing store, and cast-to-array is easily implemented using cast-to-pointer.

zigo101 · 2021-06-02T02:45:55Z

Some like #36890

mdempsky · 2021-06-02T09:04:05Z

I don't immediately see anything wrong with allowing slice to array conversions, but I feel like saving two asterisks in an already rather niche feature doesn't justify the extra complexity on compilers and tooling.

bcmills · 2021-06-02T15:15:43Z

Since this conversion would do a copy anyway, would we also add a conversion from string to [N]byte for consistency?

rsc · 2021-06-02T18:00:47Z

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

rogpeppe · 2021-06-02T20:10:33Z

FWIW I didn't propose this originally because it could easily be implemented, even prior to #395, by using copy, albeit not quite so concisely.

I'm not entirely convinced that it's worth it tbh, especially given the possibility for the expression to panic.

katiehockman · 2021-06-02T20:22:20Z

Question: is it possible to make changes to copy() so that it is equally performant to the *(*array)(slice) conversion? Then we don't need to support this additional conversion at all, and it can just be common practice to use copy in such situations.

FWIW I'm a lot less concerned about a few extra characters in the line than I am about readability. I was pretty confused as a reader to see a conversion in the form *(*array)(slice). I read it as "Cast a slice to a pointer to an array, then dereference this array", which felt more like a hack than a best practice. But maybe I just need to get used to it.

mdempsky · 2021-06-02T20:39:30Z

Question: is it possible to make changes to copy() so that it is equally performant to the *(*array)(slice) conversion? Then we don't need to support this additional conversion at all, and it can just be common practice to use copy in such situations.

Probably. I don't think there's any fundamental reason they'd perform differently. Can you file an issue with examples of code that you think should perform equivalently, and we can look into it for Go 1.18?

I was pretty confused as a reader to see a conversion in the form *(*array)(slice). I read it as "Cast a slice to a pointer to an array, then dereference this array"

Assuming you meant "dereference this [pointer to] array", that description is pretty much how I think of it, though arguably it's more of a (checked) "assertion" (as in type assertions), as conversions generally can't fail. A slice is a pointer + dynamic length (and capacity). The conversion here is changing it to a pointer + static length, with a runtime check to ensure the lengths are compatible.

katiehockman · 2021-06-02T20:48:40Z

Can you file an issue with examples of code that you think should perform equivalently, and we can look into it for Go 1.18?

Brad wrote a little benchmark that demonstrated some of the performance differences which probably shouldn't be different: https://play.golang.org/p/BkYM9Gbi4t2. He got the following results:

BenchmarkNamed-8        201051339                6.263 ns/op
BenchmarkCopy-8         172203873                6.071 ns/op
BenchmarkPointer-8      1000000000               1.031 ns/op

You can also check out the Sum functions in https://go-review.googlesource.com/c/go/+/322329 which are good examples of code that should perform ~equivalently.

mdempsky · 2021-06-02T21:18:26Z

@katiehockman Thanks, filed #46529.

As noted in that issue, the first two functions have different semantics than the last function when len(b) < Size256. I suspect that doesn't matter for your use case, but the compiler would need some way to discern that can't happen before it can optimize them identically.

kortschak · 2021-06-02T22:17:09Z

ISTM that the need for a dereference is a nice visual signal to an author that *(*[n]T)(s[:n]) is more costly than (*[n]T)(s[:n]). As it is it's reasonably common the users are surprised that an array expression results in a copy of the array (for example in a range over an array value).

bcmills · 2021-06-03T16:04:44Z

ISTM that the need for a dereference is a nice visual signal to an author

I am personally unlikely to notice that signal among the line-noise of the rest of the expression.
Also note that ([]byte)(s) for a string s, or string(b) for a slice b, has no such visual signal — the destination type is in some sense “good enough”.

As it is it's reasonably common the users are surprised that an array expression results in a copy

Sure, but the ship has already sailed on that one. 😅 Given that we already have array values, it doesn't seem particularly more confusing to allow conversions to them.

bcmills · 2021-06-03T16:08:41Z

I am personally unlikely to noticed that signal among the line-noise of the rest of the expression.

Looking at this again, I'm not sure why the slice part of the expression is needed at all.
@bradfitz, could you not have written that as

	return *(*[Size224]byte)(sum)

?

And then the direct-conversion alternative becomes

	return ([Size224]byte)(sum)

which reads a lot cleaner to me. (Without the redundant slice expression, those redundant * tokens are a larger fraction of the noise.)

kortschak · 2021-06-03T21:43:20Z

Given that we already have array values, it doesn't seem particularly more confusing to allow conversions to them.

It's not a matter of confusion in this case, but signalling that there is more work being done; the pointer conversion is essentially free. WRT the signalling for string/[]byte, the difference there is that they are clearly distinct types, in this situation it is potentially a single character that makes the difference. between behaviours under the proposal.

rsc · 2021-06-09T17:12:15Z

Strictly speaking this is unnecessary. You can always write

*(*[10]int)(x)

instead of the proposed

[10]int(x)

That said, copying data out from a slice into a fixed-size array is pretty common when using fixed-size arrays (like checksums etc), so I don't really see the harm in making that less star-full.

/cc @robpike

rsc · 2021-07-14T17:24:13Z

Any objections to adding this?

randall77 · 2021-07-14T17:48:56Z

I'm leaning against. I don't think adding a new conversion case is worth saving two *s.

mdempsky · 2021-07-14T17:53:15Z

I'm also leaning against.

We've had a string of fixes to x/tools to update code for slice-to-array-pointer conversions. None of the CLs have been very involved, but just cases where we forgot to update it. I don't think this feature is going to be so frequently used to justify forcing tools authors to support both forms.

rsc · 2021-07-21T17:14:53Z

Does anyone want to make an argument in favor?

Splizard · 2021-08-04T06:07:09Z

Does anyone want to make an argument in favor?

I believe that this proposal would result in improved discoverability around this kind of type conversion, when I first started writing Go (~8 years ago) I recall at one point wondering why I couldn't convert a slice to an array just like this. This seemed like the obvious way to do it.

[10]int(x)

At the time (even if #395 existed), it would never have occurred to me that I could do something like this:

*(*[10]int)(x)

I had previously been using languages without pointers and I wasn't familiar with the semantics around dereferencing or how slices relate to them.

It's the kind of small thing as a beginner you don't even bother looking into when the compiler throws an error and you simply write it another way until you find out months or years later when you see it somewhere and/or learn more about pointer semantics and realise that this is possible.

IE. somebody who starts learning about pointer semantics in Go can infer that *(*[10]int)(x) is possible if they are already familiar with [10]int(x) but if this proposal is declined then beginners in Go are locked out from benefiting from #395 until they learn more about the language (and this is hindered further if they come from languages without pointers).

Instead of framing this proposal around "saving two asterisks", I would argue that it helps discoverability around #395 because it is an obvious way to convert from a slice to an array.

mdempsky · 2022-09-19T20:00:58Z

I think x/tools/go/ssa still needs support for this. (/cc @timothy-king)

It can probably be represented as SliceToArrayPtr + UnOp/STAR.

Converting from nil slice to zero element array is ok, so explicitly describe the behavior in the spec. For #46505 Change-Id: I68f432deb6c21a7549bf7e870185fc62504b37f7 Reviewed-on: https://go-review.googlesource.com/c/go/+/430835 TryBot-Result: Gopher Robot <[email protected]> Auto-Submit: Cuong Manh Le <[email protected]> Reviewed-by: Robert Griesemer <[email protected]> Reviewed-by: Cherry Mui <[email protected]> Auto-Submit: Robert Griesemer <[email protected]> Run-TryBot: Cuong Manh Le <[email protected]>

gopherbot · 2022-09-22T13:15:02Z

Change https://go.dev/cl/432735 mentions this issue: net/netip: use slice-to-array conversions

Use slice-to-array conversions in AddrFromSlice and (*Addr).UnmarshalBinary. This allows allows to use AddrFrom16 and drop the redundant ipv6Slice helper. For #46505 Change-Id: I0e3a7d8825ad438115b7f23ee97cc74eec41a826 Reviewed-on: https://go-review.googlesource.com/c/go/+/432735 Reviewed-by: Damien Neil <[email protected]> Run-TryBot: Tobias Klauser <[email protected]> Auto-Submit: Tobias Klauser <[email protected]> Reviewed-by: Cherry Mui <[email protected]> TryBot-Result: Gopher Robot <[email protected]>

cuiweixie · 2022-09-24T08:35:41Z

Hi, masters. Please check this cl that add slice to array converstion to x/tools at go/ssa.

gopherbot · 2022-09-24T14:32:20Z

Change https://go.dev/cl/433816 mentions this issue: go/ssa: add slice to array conversion

For golang/go#46505 Change-Id: I642409e383c851277845b37dd8423dc673c12a8b Reviewed-on: https://go-review.googlesource.com/c/tools/+/433816 Run-TryBot: xie cui <[email protected]> Reviewed-by: David Chase <[email protected]> Reviewed-by: Zvonimir Pavlinovic <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Tim King <[email protected]> gopls-CI: kokoro <[email protected]>

gopherbot · 2022-11-07T16:49:44Z

Change https://go.dev/cl/448396 mentions this issue: net/netip: use slice-to-array conversions

Resend of CL 432735 (with one additional conversion that the original CL missed) after it broke the longtest builder on x/tools and was reverted in CL 433478. Now that x/tools/go/ssa has support for this, the longtest x/tools build passes as well. Use slice-to-array conversions in AddrFromSlice and (*Addr).UnmarshalBinary. This allows using AddrFrom16 and drop the redundant ipv6Slice helper. For #46505 Change-Id: I4d8084b7a97f162e4f7d685c86aac56d960ff693 Reviewed-on: https://go-review.googlesource.com/c/go/+/448396 TryBot-Result: Gopher Robot <[email protected]> Auto-Submit: Tobias Klauser <[email protected]> Run-TryBot: Tobias Klauser <[email protected]> Reviewed-by: Michael Knyszek <[email protected]> Reviewed-by: Ian Lance Taylor <[email protected]>

shuLhan · 2022-11-16T05:28:45Z

CC: @tklauser @mknyszek @ianlancetaylor

Hi all,

I have out-of-memory (OoM) issue related to dc98ccd.

The symptom is when using golangci-lint build with above commit, it will crash due to OOM. The steps to reproduce it,

Build Go using above commit
Build golangci/golangci-lint@09fb4d7b using it
Run golangci-lint (unfortunately the repository where this tool running that cause the crash is private)

Let me know if I need to open new ticket or any other information.

git bisect log,

git bisect start
# status: waiting for both good and bad commits
# bad: [7b1330088648e1062e02cda455f14e1f73ee7805] encoding/json: optimize isValidNumber function
git bisect bad 7b1330088648e1062e02cda455f14e1f73ee7805
# status: waiting for good commit(s), bad commit known
# good: [c318f191e45e3496f8afe0a456337e9f76d7f7b4] cmd/link: optimize PPC64 inline plt sequences if local
git bisect good c318f191e45e3496f8afe0a456337e9f76d7f7b4
# good: [3aebf682e4928ab490b64b3ba6729c78c9d066ba] cmd/api: skip tests when 'os/exec' is supported but 'go build' is not
git bisect good 3aebf682e4928ab490b64b3ba6729c78c9d066ba
# bad: [a1c31d6803dac891b200b3598aa00224ab80c0bb] cmd/go: replace Action.Func with Action.Actor
git bisect bad a1c31d6803dac891b200b3598aa00224ab80c0bb
# good: [b07e845e764806fa888cb4e99c8ace4625f0472f] cmd/compile: use CDF to determine PGO inline threshold
git bisect good b07e845e764806fa888cb4e99c8ace4625f0472f
# good: [f187c6b08eac9dddd161bb2e7537def3bbf8ec9a] cmd/compile/internal/pgo: check repeated edge only when node is seen
git bisect good f187c6b08eac9dddd161bb2e7537def3bbf8ec9a
# good: [601ad2e4570896d07df8ace7d2ab9100a57d301c] math: fix function name in comment
git bisect good 601ad2e4570896d07df8ace7d2ab9100a57d301c
# good: [6bead8f77afd2f7317eb011ca019b61ac3d90c17] sync/atomic: disallow type conversions of atomic.Pointer[T]
git bisect good 6bead8f77afd2f7317eb011ca019b61ac3d90c17
# bad: [9860faa5127931183e4dfb716d89ce7dface3f41] math/big: remove underscores from Binomial docs
git bisect bad 9860faa5127931183e4dfb716d89ce7dface3f41
# bad: [dc98ccd836da7d22a5d270b9778fb055826fa07b] net/netip: use slice-to-array conversions
git bisect bad dc98ccd836da7d22a5d270b9778fb055826fa07b
# good: [b417f62b00276a2ccca3fa7e490f3673a1df8a4c] net/netip: remove unused unexported functions and methods
git bisect good b417f62b00276a2ccca3fa7e490f3673a1df8a4c
# first bad commit: [dc98ccd836da7d22a5d270b9778fb055826fa07b] net/netip: use slice-to-array conversions

OOM crash log,

Nov 16 12:04:20 inspiro kernel: qemu-system-x86 invoked oom-killer: gfp_mask=0x140cca(GFP_HIGHUSER_MOVABLE|__GFP_COMP), order=0, oom_score_adj=0
Nov 16 12:04:20 inspiro kernel: CPU: 2 PID: 3074 Comm: qemu-system-x86 Tainted: G     U             6.0.8-arch1-1 #1 9d710c2a17e975eb42321436dd1a075089abf66c
Nov 16 12:04:20 inspiro kernel: Hardware name: Dell Inc. Inspiron 5400 AIO/0H1TR9, BIOS 1.0.0 08/25/2020
Nov 16 12:04:20 inspiro kernel: Call Trace:
Nov 16 12:04:20 inspiro kernel:  <TASK>
Nov 16 12:04:20 inspiro kernel:  dump_stack_lvl+0x48/0x60
Nov 16 12:04:20 inspiro kernel:  dump_header+0x4a/0x1ff
Nov 16 12:04:20 inspiro kernel:  oom_kill_process.cold+0xb/0x10
Nov 16 12:04:20 inspiro kernel:  out_of_memory+0x27e/0x520
Nov 16 12:04:20 inspiro kernel:  __alloc_pages_slowpath.constprop.0+0xcbe/0xe10
Nov 16 12:04:20 inspiro kernel:  __alloc_pages+0x224/0x250
Nov 16 12:04:20 inspiro kernel:  folio_alloc+0x1b/0x50
Nov 16 12:04:20 inspiro kernel:  __filemap_get_folio+0x161/0x380
Nov 16 12:04:20 inspiro kernel:  filemap_fault+0x140/0x930
Nov 16 12:04:20 inspiro kernel:  ? filemap_map_pages+0x157/0x7b0
Nov 16 12:04:20 inspiro kernel:  __do_fault+0x33/0x110
Nov 16 12:04:20 inspiro kernel:  do_fault+0x1c2/0x420
Nov 16 12:04:20 inspiro kernel:  __handle_mm_fault+0x668/0xf70
Nov 16 12:04:20 inspiro kernel:  handle_mm_fault+0xb2/0x290
Nov 16 12:04:20 inspiro kernel:  do_user_addr_fault+0x1be/0x6a0
Nov 16 12:04:20 inspiro kernel:  exc_page_fault+0x74/0x170
Nov 16 12:04:20 inspiro kernel:  asm_exc_page_fault+0x26/0x30
Nov 16 12:04:20 inspiro kernel: RIP: 0033:0x7f9ebc4491b6
Nov 16 12:04:20 inspiro kernel: Code: Unable to access opcode bytes at RIP 0x7f9ebc44918c.
Nov 16 12:04:20 inspiro kernel: RSP: 002b:00007ffcc8c77c80 EFLAGS: 00010293
Nov 16 12:04:20 inspiro kernel: RAX: 0000000000000001 RBX: 00000000351b94c0 RCX: 00007f9ebc4491b6
Nov 16 12:04:20 inspiro kernel: RDX: 00007ffcc8c77ca0 RSI: 000000000000005f RDI: 0000563cb71d8a00
Nov 16 12:04:20 inspiro kernel: RBP: 0000563cb6e457c0 R08: 0000000000000008 R09: 0000000000000000
Nov 16 12:04:20 inspiro kernel: R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffcc8c77ca0
Nov 16 12:04:20 inspiro kernel: R13: 0000563cb6e457c0 R14: 0000563cb530b618 R15: 00007f9ebd638000
Nov 16 12:04:20 inspiro kernel:  </TASK>
Nov 16 12:04:20 inspiro kernel: Mem-Info:
Nov 16 12:04:20 inspiro kernel: active_anon:1033183 inactive_anon:1917261 isolated_anon:0
                                 active_file:180 inactive_file:220 isolated_file:0
                                 unevictable:2370 dirty:0 writeback:0
                                 slab_reclaimable:39629 slab_unreclaimable:47465
                                 mapped:556448 shmem:665764 pagetables:10592 bounce:0
                                 kernel_misc_reclaimable:0
                                 free:34710 free_pcp:2 free_cma:0
Nov 16 12:04:20 inspiro kernel: Node 0 active_anon:4132732kB inactive_anon:7669044kB active_file:720kB inactive_file:880kB unevictable:9480kB isolated(anon):0kB isolated(file):0kB mapped:2225792kB dirty:0kB writeback:0kB shmem:2663056kB s>
Nov 16 12:04:20 inspiro kernel: Node 0 DMA free:13312kB boost:0kB min:64kB low:80kB high:96kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15992kB man>
Nov 16 12:04:20 inspiro kernel: lowmem_reserve[]: 0 1072 15594 15594 15594
Nov 16 12:04:20 inspiro kernel: Node 0 DMA32 free:62720kB boost:0kB min:4644kB low:5804kB high:6964kB reserved_highatomic:0KB active_anon:128812kB inactive_anon:852652kB active_file:36kB inactive_file:0kB unevictable:0kB writepending:0kB >
Nov 16 12:04:20 inspiro kernel: lowmem_reserve[]: 0 0 14522 14522 14522
Nov 16 12:04:20 inspiro kernel: Node 0 Normal free:62808kB boost:0kB min:62872kB low:78588kB high:94304kB reserved_highatomic:0KB active_anon:4003920kB inactive_anon:6816776kB active_file:224kB inactive_file:1076kB unevictable:9480kB writ>
Nov 16 12:04:20 inspiro kernel: lowmem_reserve[]: 0 0 0 0 0
Nov 16 12:04:20 inspiro kernel: Node 0 DMA: 0*4kB 0*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 1*1024kB (U) 2*2048kB (UM) 2*4096kB (M) = 13312kB
Nov 16 12:04:20 inspiro kernel: Node 0 DMA32: 104*4kB (UME) 40*8kB (UME) 24*16kB (UME) 21*32kB (UME) 12*64kB (UME) 6*128kB (UE) 14*256kB (ME) 27*512kB (ME) 31*1024kB (UME) 1*2048kB (U) 2*4096kB (M) = 62720kB
Nov 16 12:04:20 inspiro kernel: Node 0 Normal: 1346*4kB (UME) 595*8kB (UME) 557*16kB (UME) 521*32kB (UME) 335*64kB (UME) 45*128kB (UME) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 62928kB
Nov 16 12:04:20 inspiro kernel: Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB
Nov 16 12:04:20 inspiro kernel: Node 0 hugepages_total=1024 hugepages_free=1024 hugepages_surp=0 hugepages_size=2048kB
Nov 16 12:04:20 inspiro kernel: 675356 total pagecache pages
Nov 16 12:04:20 inspiro kernel: 9108 pages in swap cache
Nov 16 12:04:20 inspiro kernel: Free swap  = 0kB
Nov 16 12:04:20 inspiro kernel: Total swap = 4194300kB
Nov 16 12:04:20 inspiro kernel: 4099966 pages RAM
Nov 16 12:04:20 inspiro kernel: 0 pages HighMem/MovableOnly
Nov 16 12:04:20 inspiro kernel: 97339 pages reserved
Nov 16 12:04:20 inspiro kernel: 0 pages cma reserved
Nov 16 12:04:20 inspiro kernel: 0 pages hwpoisoned
Nov 16 12:04:20 inspiro kernel: Tasks state (memory values in pages):
Nov 16 12:04:20 inspiro kernel: [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
Nov 16 12:04:20 inspiro kernel: [    227]     0   227    16116      114   139264      225          -250 systemd-journal
Nov 16 12:04:20 inspiro kernel: [    250]     0   250     8557      194    90112      492         -1000 systemd-udevd
Nov 16 12:04:20 inspiro kernel: [    275]   981   275     5378       61    86016      302             0 systemd-network
Nov 16 12:04:20 inspiro kernel: [    334]   979   334    22762       36    81920      245             0 systemd-timesyn
...
Nov 16 12:04:20 inspiro kernel: [  52151]  1000 52151     2177        2    61440      457             0 bash
Nov 16 12:04:20 inspiro kernel: [ 109133]  1000 109133     2791        2    69632      115             0 make
Nov 16 12:04:20 inspiro kernel: [ 109135]  1000 109135  3119229  2250713 22908928   511669             0 golangci-lint
Nov 16 12:04:20 inspiro kernel: [ 111376]  1000 111376     2716      271    61440        0             0 top
Nov 16 12:04:20 inspiro kernel: oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=emulator,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-4.scope,task=golangci-lint,pid=109135,uid=1000
Nov 16 12:04:20 inspiro kernel: Out of memory: Killed process 109135 (golangci-lint) total-vm:12476916kB, anon-rss:9002852kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:22372kB oom_score_adj:0

ianlancetaylor · 2022-11-16T23:38:56Z

@shuLhan I don't understand how that change, which is quite small, could possibly have such an effect. Please open a separate issue with as much information as you can provide. Thanks.

timothy-king · 2022-11-17T00:35:34Z

@shuLhan When you open a separate issue, please cc me.

shuLhan · 2022-11-22T14:46:31Z

@ianlancetaylor @timothy-king After updating Go tip to e84ce08 and golangci/golangci-lint@bc333921 there is no more crash, but only panic

golangci-lint run ./...
ERRO [runner] Panic: buildir: package "netip" (isInitialPkg: false, needAnalyzeSource: true): in net/netip.AddrFromSlice: cannot convert Load <[]byte> t0 ([]byte) to [4]byte: goroutine 6688 [running]:
runtime/debug.Stack()
        /home/ms/opt/go/src/runtime/debug/stack.go:24 +0x65
github.com/golangci/golangci-lint/pkg/golinters/goanalysis.(*action).analyzeSafe.func1()
        /home/ms/go/src/github.com/shuLhan/golangci-lint/pkg/golinters/goanalysis/runner_action.go:102 +0x155
panic({0xf29480, 0xc001f65910})
        /home/ms/opt/go/src/runtime/panic.go:884 +0x213
honnef.co/go/tools/go/ir.emitConv(0xc00123cc80, {0x13019a8, 0xc002eb60c0}, {0x12f5f58?, 0xc003bd4060}, {0x12f5648, 0xc003694200})
        /home/ms/go/pkg/mod/honnef.co/go/[email protected]/go/ir/emit.go:293 +0xd29
honnef.co/go/tools/go/ir.(*builder).expr0(0xc001095a18, 0xc00123cc80, {0x12f8d10?, 0xc003694200?}, {0x7, {0x12f5f58, 0xc003bd4060}, {0x0,
0x0}})
        /home/ms/go/pkg/mod/honnef.co/go/[email protected]/go/ir/builder.go:610 +0x5d7
honnef.co/go/tools/go/ir.(*builder).expr(0x12f60e8?, 0xc00123cc80, {0x12f8d10, 0xc003694200})
        /home/ms/go/pkg/mod/honnef.co/go/[email protected]/go/ir/builder.go:566 +0x1fa
honnef.co/go/tools/go/ir.(*builder).emitCallArgs(0x12f60e8?, 0xc00123cc80, 0xc003a12d40, 0xc003694240, {0x0?, 0x0, 0x40e127?})
        /home/ms/go/pkg/mod/honnef.co/go/[email protected]/go/ir/builder.go:975 +0x135
honnef.co/go/tools/go/ir.(*builder).setCall(0xf67560?, 0xc00123cc80, 0xc003694240, 0xc001a714e8)
        /home/ms/go/pkg/mod/honnef.co/go/[email protected]/go/ir/builder.go:1037 +0x8e
honnef.co/go/tools/go/ir.(*builder).expr0(0xc001095a18, 0xc00123cc80, {0x12f8d10?, 0xc003694240?}, {0x7, {0x12f6048, 0xc0035baaf0}, {0x0,
0x0}})
        /home/ms/go/pkg/mod/honnef.co/go/[email protected]/go/ir/builder.go:623 +0x218e

I think I can say that this is issue in golangci-lint itself not on the Go compiler. Sorry for the noise.

mvdan · 2022-11-22T14:51:49Z

@shuLhan that's dominikh/go-tools#1335. Note how @dominikh maintains his own ssa implementation, so this thread does not directly affect staticcheck as much as other tools.

gopherbot · 2022-11-23T18:35:58Z

Change https://go.dev/cl/452936 mentions this issue: spec: document conversion from slice to array

Document that a slice can be converted to either an array or a pointer to an array of a matching underlying array type. This was documented in the "Conversions from slice to array or array pointer" subsection, but not in the list of conversion rules. Updates #46505. Change-Id: I16a89a63ef23c33580129952415e977a8f334009 Reviewed-on: https://go-review.googlesource.com/c/go/+/452936 TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Robert Griesemer <[email protected]> Run-TryBot: Tim King <[email protected]>

mdempsky · 2022-12-16T00:39:35Z

I believe this has been done since https://go.dev/cl/433816 landed.

* fix array conversion that was necessary due to golang/go#46505 * preallocate slice Signed-off-by: Alexander Yastrebov <[email protected]>

gopherbot added this to the Proposal milestone Jun 1, 2021

gopherbot added the Proposal label Jun 1, 2021

bradfitz added LanguageChange Suggested changes to the Go language and removed Proposal labels Jun 1, 2021

ianlancetaylor added the Proposal label Jun 1, 2021

rsc changed the title ~~proposal: allow conversion from slice to array~~ proposal: spec: allow conversion from slice to array Jun 2, 2021

rsc mentioned this issue Jun 2, 2021

proposal: review meeting minutes #33502

Open

mdempsky mentioned this issue Jun 2, 2021

cmd/compile: explore optimizations for fixed-length array copies #46529

Open

mdempsky reopened this Sep 19, 2022

AlexanderYastrebov mentioned this issue Dec 7, 2022

Adds HeaderSHA256 predicate zalando/skipper#1905

Merged

mdempsky closed this as completed Dec 16, 2022

ainar-g mentioned this issue Feb 14, 2023

simple: in Go 1.20, simplify *(*ArrayType)(slice) to ArrayType(slice) dominikh/go-tools#1367

Open

This was referenced Feb 23, 2023

Optimizing crypto/ed25519.go ava-labs/hypersdk#21

Merged

Remove Unnecessary Memory Copies with Slice to Array Conversions ava-labs/hypersdk#23

Open

AlexanderYastrebov added a commit to zalando/skipper that referenced this issue Dec 9, 2023

predicates/auth: fix array conversion

51082a4

* fix array conversion that was necessary due to golang/go#46505 * preallocate slice Signed-off-by: Alexander Yastrebov <[email protected]>

AlexanderYastrebov mentioned this issue Dec 9, 2023

predicates/auth: fix array conversion zalando/skipper#2788

Merged

AlexanderYastrebov added a commit to zalando/skipper that referenced this issue Dec 11, 2023

predicates/auth: fix array conversion (#2788)

3dc744e

* fix array conversion that was necessary due to golang/go#46505 * preallocate slice Signed-off-by: Alexander Yastrebov <[email protected]>

golang locked and limited conversation to collaborators Dec 16, 2023

gopherbot added the FrozenDueToAge label Dec 16, 2023

rsc removed this from Proposals Dec 21, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

spec: allow conversion from slice to array #46505

spec: allow conversion from slice to array #46505

bradfitz commented Jun 1, 2021

randall77 commented Jun 1, 2021

zigo101 commented Jun 2, 2021

mdempsky commented Jun 2, 2021

bcmills commented Jun 2, 2021

rsc commented Jun 2, 2021

rogpeppe commented Jun 2, 2021

katiehockman commented Jun 2, 2021

mdempsky commented Jun 2, 2021

katiehockman commented Jun 2, 2021

mdempsky commented Jun 2, 2021

kortschak commented Jun 2, 2021

bcmills commented Jun 3, 2021 •

edited

Loading

bcmills commented Jun 3, 2021

kortschak commented Jun 3, 2021

rsc commented Jun 9, 2021

rsc commented Jul 14, 2021

randall77 commented Jul 14, 2021

mdempsky commented Jul 14, 2021

rsc commented Jul 21, 2021

Splizard commented Aug 4, 2021 •

edited

Loading

mdempsky commented Sep 19, 2022

gopherbot commented Sep 22, 2022

cuiweixie commented Sep 24, 2022 •

edited

Loading

gopherbot commented Sep 24, 2022

gopherbot commented Nov 7, 2022

shuLhan commented Nov 16, 2022

ianlancetaylor commented Nov 16, 2022

timothy-king commented Nov 17, 2022

shuLhan commented Nov 22, 2022

mvdan commented Nov 22, 2022

gopherbot commented Nov 23, 2022

mdempsky commented Dec 16, 2022

spec: allow conversion from slice to array #46505

spec: allow conversion from slice to array #46505

Comments

bradfitz commented Jun 1, 2021

randall77 commented Jun 1, 2021

zigo101 commented Jun 2, 2021

mdempsky commented Jun 2, 2021

bcmills commented Jun 2, 2021

rsc commented Jun 2, 2021

rogpeppe commented Jun 2, 2021

katiehockman commented Jun 2, 2021

mdempsky commented Jun 2, 2021

katiehockman commented Jun 2, 2021

mdempsky commented Jun 2, 2021

kortschak commented Jun 2, 2021

bcmills commented Jun 3, 2021 • edited Loading

bcmills commented Jun 3, 2021

kortschak commented Jun 3, 2021

rsc commented Jun 9, 2021

rsc commented Jul 14, 2021

randall77 commented Jul 14, 2021

mdempsky commented Jul 14, 2021

rsc commented Jul 21, 2021

Splizard commented Aug 4, 2021 • edited Loading

mdempsky commented Sep 19, 2022

gopherbot commented Sep 22, 2022

cuiweixie commented Sep 24, 2022 • edited Loading

gopherbot commented Sep 24, 2022

gopherbot commented Nov 7, 2022

shuLhan commented Nov 16, 2022

ianlancetaylor commented Nov 16, 2022

timothy-king commented Nov 17, 2022

shuLhan commented Nov 22, 2022

mvdan commented Nov 22, 2022

gopherbot commented Nov 23, 2022

mdempsky commented Dec 16, 2022

bcmills commented Jun 3, 2021 •

edited

Loading

Splizard commented Aug 4, 2021 •

edited

Loading

cuiweixie commented Sep 24, 2022 •

edited

Loading