[ARC] compile-time move() on a sink-annotated argument empties the original value even when it's unsafe

[ghost]

This code works fine with refc but fails with arc because system has a different implementation for https://nim-lang.org/docs/system.html#%26%2Cseq%5BT%5D%2CT and with ARC the compiler seems to always pass a variable to a sink-annotated argument even when it's unsafe. Found in https://github.com/PMunch/protobuf-nim

Example

Original example

proc passSeq(data: seq[string]) = 
  # used the system.& proc initially
  let wat = data & "hello"

proc test = 
  let name = @["hello", "world"]
  passSeq(name)
  doAssert name == @["hello", "world"]

# works at runtime but not compile-time
static:
  test()

Example with & taken out of system (fails with both refc/arc):

proc merge(x: sink seq[string], y: sink string): seq[string] =
  newSeq(result, x.len + 1)
  for i in 0..x.len-1:
    result[i] = move(x[i])
  result[x.len] = move(y)

proc passSeq(data: seq[string]) = 
  # used the system.& proc initially
  let wat = merge(data, "hello")

proc test = 
  let name = @["hello", "world"]
  passSeq(name)
  doAssert name == @["hello", "world"]

# works at runtime but not compile-time
static:
  test()

Current Output

stack trace: (most recent call last)
/home/dian/Stuff/protobuf-nim/krr.nim(12, 7) krr
/home/dian/Stuff/protobuf-nim/krr.nim(8, 11) test
/home/dian/Things/Nim/lib/system/assertions.nim(68, 26) failedAssertImpl
/home/dian/Things/Nim/lib/system/assertions.nim(58, 11) raiseAssert
/home/dian/Things/Nim/lib/system/fatal.nim(53, 5) sysFatal
/home/dian/Things/Nim/lib/system/fatal.nim(53, 5) Error: unhandled exception: /home/dian/Stuff/protobuf-nim/krr.nim(8, 12) `name == @["hello", "world"]`  [AssertionDefect]

Expected Output

Successful compilation

$ nim -v
Nim Compiler Version 1.5.1 [Linux: amd64]
Compiled at 2021-02-28
Copyright (c) 2006-2021 by Andreas Rumpf

git hash: 26a6ceb34eb2bfca4e39dec2dac2d0a2cdc1bade
active boot switches: -d:release -d:danger

[ghost]

I'm not sure if this can actually be considered an ARC bug since it can happen with both arc and refc - so maybe we should either make the move proc copy if it's executed in compile-time context, or just don't use move in any compile-time procs?

[ghost]

Example from #16847 :

macro Bug() =
  let a = @[123]
  discard @[456] & a
  let c = @[789] & a
  assert c[1] == 123

Bug()

[ghost]

Example from #17294:

proc recurse(strings:seq[string],recursionsLeft:int) =
  if recursionsLeft != 0:
    echo "Before call: " & $strings
    recurse(strings & @["another string"],recursionsLeft-1)
    echo "After call: " & $strings
  else:
    discard

static:
  recurse(@["string"],1)

[Araq]

Sink parameters are currently under the ARC/ORC umbrella.