Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spec: allow conversion from slice to array #46505

Closed
bradfitz opened this issue Jun 1, 2021 · 79 comments
Closed

spec: allow conversion from slice to array #46505

bradfitz opened this issue Jun 1, 2021 · 79 comments
Assignees
Labels
early-in-cycle A change that should be done early in the 3 month dev cycle. FrozenDueToAge LanguageChange Suggested changes to the Go language Proposal Proposal-Accepted Proposal-FinalCommentPeriod
Milestone

Comments

@bradfitz
Copy link
Contributor

bradfitz commented Jun 1, 2021

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

@gopherbot gopherbot added this to the Proposal milestone Jun 1, 2021
@bradfitz bradfitz added LanguageChange Suggested changes to the Go language and removed Proposal labels Jun 1, 2021
@randall77
Copy link
Contributor

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
Copy link

zigo101 commented Jun 2, 2021

Some like #36890

@mdempsky
Copy link
Contributor

mdempsky commented Jun 2, 2021

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
Copy link
Contributor

bcmills commented Jun 2, 2021

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

@rsc rsc changed the title proposal: allow conversion from slice to array proposal: spec: allow conversion from slice to array Jun 2, 2021
@rsc
Copy link
Contributor

rsc commented Jun 2, 2021

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
Copy link
Contributor

rogpeppe commented Jun 2, 2021

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
Copy link
Contributor

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
Copy link
Contributor

mdempsky commented Jun 2, 2021

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
Copy link
Contributor

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
Copy link
Contributor

mdempsky commented Jun 2, 2021

@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
Copy link
Contributor

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
Copy link
Contributor

bcmills commented Jun 3, 2021

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
Copy link
Contributor

bcmills commented Jun 3, 2021

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
Copy link
Contributor

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
Copy link
Contributor

rsc commented Jun 9, 2021

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
Copy link
Contributor

rsc commented Jul 14, 2021

Any objections to adding this?

@randall77
Copy link
Contributor

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

@mdempsky
Copy link
Contributor

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
Copy link
Contributor

rsc commented Jul 21, 2021

Does anyone want to make an argument in favor?

@Splizard
Copy link

Splizard commented Aug 4, 2021

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
Copy link
Contributor

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

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

@mdempsky mdempsky reopened this Sep 19, 2022
gopherbot pushed a commit that referenced this issue Sep 21, 2022
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
Copy link
Contributor

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

gopherbot pushed a commit that referenced this issue Sep 23, 2022
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
Copy link
Contributor

cuiweixie commented Sep 24, 2022

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

@gopherbot
Copy link
Contributor

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

gopherbot pushed a commit to golang/tools that referenced this issue Oct 21, 2022
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
Copy link
Contributor

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

gopherbot pushed a commit that referenced this issue Nov 8, 2022
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
Copy link
Contributor

shuLhan commented Nov 16, 2022

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,

  1. Build Go using above commit
  2. Build golangci/golangci-lint@09fb4d7b using it
  3. 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
Copy link
Contributor

@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
Copy link
Contributor

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

@shuLhan
Copy link
Contributor

shuLhan commented Nov 22, 2022

@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
Copy link
Member

mvdan commented Nov 22, 2022

@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
Copy link
Contributor

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

gopherbot pushed a commit that referenced this issue Nov 30, 2022
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
Copy link
Contributor

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

AlexanderYastrebov added a commit to zalando/skipper that referenced this issue Dec 9, 2023
* fix array conversion that was necessary due to golang/go#46505
* preallocate slice

Signed-off-by: Alexander Yastrebov <[email protected]>
AlexanderYastrebov added a commit to zalando/skipper that referenced this issue Dec 11, 2023
* fix array conversion that was necessary due to golang/go#46505
* preallocate slice

Signed-off-by: Alexander Yastrebov <[email protected]>
@golang golang locked and limited conversation to collaborators Dec 16, 2023
@rsc rsc removed this from Proposals Dec 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
early-in-cycle A change that should be done early in the 3 month dev cycle. FrozenDueToAge LanguageChange Suggested changes to the Go language Proposal Proposal-Accepted Proposal-FinalCommentPeriod
Projects
None yet
Development

No branches or pull requests