confusion of forvar type when supplied as typed macro argument

[Smooth Operator]

I know, I know. This is, at present, a full-fat repro. 😉

Example

This code only runs on Linux.

https://github.com/disruptek/insideout/blob/erasure/tests/6/tbillion2.nim#L49

  block:
    var pool = newPool(ContinuationWaiter)
    for queue in queues.items:  # seq[Mailbox[Continuation]]
      #assert queue is AtomicRef[MailboxObj[Continuation]]
      assert queue is Mailbox[Continuation]
      pause queue
      when true:
        # nimskull says Error: type mismatch: got <AtomicRef>
        pool.add: spawn(ContinuationWaiter, queue)
      elif true:
        # nimskull says Error: type mismatch: got <AtomicRef>
        pool.add: ContinuationWaiter.call(queue)
      elif true:
        # nimskull likes this one
        pool.add: spawn(ContinuationWaiter, Mailbox[Continuation] queue)
      elif true:
        # nimskull likes this one, too
        pool.add: ContinuationWaiter.call(Mailbox[Continuation] queue)

The call macro from cps, which turns a Callback and varargs[typed] into a Continuation, seems to be losing track of the fact that queue is a Mailbox[Continuation] and not merely AtomicRef[MailboxObj[Continuation]]. The code works in old nim and it works if you remove the iterator.

To reproduce...

$ git clone --branch erasure https://github.com/disruptek/insideout
$ cd insideout
# setup a nim.cfg and then...
$ nimph doctor
$ nim c --define:useMalloc --gc:arc --threads:on --panics:on tests/6/tbillion2.nim

Actual Output

tbillion2.nim(49, 25) Error: type mismatch: got <AtomicRef>
but expected one of:
proc (box`gensym7: Mailbox[spec.Continuation]): Continuation{.nimcall.}

Expected Output

Additional Information

Nimskull Compiler Version 0.1.0-dev.21241 [linux: amd64]

Source hash: 9be395f752aa23c01e7214987e0b2386609ae821
Source date: 2024-02-26

active boot switches: -d:release -d:danger⏎

[Saem Ghani]

Thanks for filing this, I'm going to do a quick semantic trace on this to get an initial triage.

[Saem Ghani]

Pretty sure this is the same issue as #1181, and should be restested once #1192 is merged