quote do captures non literal local variables

[timotheecour]

• following code gives BUG1:

???(0, 0) Error: internal error: genLiteral: ty is nil

import macros

proc fun1*(info:LineInfo): string = "bar"
proc fun2*(info:int): string = "bar"

macro echoL*(args: varargs[untyped]): untyped =
  let info = args.lineInfoObj
  let fun1 = bindSym"fun1"
  let fun2 = bindSym"fun2"

  # this would work instead
  # result = newCall(bindSym"fun2", info.line.newLit)

  result = quote do:

    # BUG1: ???(0, 0) Error: internal error: genLiteral: ty is nil
    `fun1`(`info`)

    # BUG2: Error: object constructor needs an object type
    # `fun2`(`info`.line)

echo echoL()

• uncomment line below BUG2 gives Error: object constructor needs an object type

• it works if we instead use result = newCall(bindSym"fun2", info.line.newLit)

[krux02]

Honestliy I hate how quote do tries to capture every local symbol and then fails misably at later compilation stage.

This code works btw:

import macros

proc fun1*(info:LineInfo): string = "bar"
proc fun2*(info:int): string = "bar"

macro echoL*(args: varargs[untyped]): untyped =
  let info = args.lineInfoObj
  let infoLit = info.newLit
  let infoLineLit = info.line.newLit
  let fun1 = bindSym"fun1"
  let fun2 = bindSym"fun2"

  # this would work instead
  # result = newCall(bindSym"fun2", info.line.newLit)

  result = quote do:

    # BUG1: ???(0, 0) Error: internal error: genLiteral: ty is nil
    discard `fun1`(`infoLit`)

    # BUG2: Error: object constructor needs an object type
    discard `fun2`(`infoLineLit`)

echoL()

[narimiran]

Currently (Nim devel 1.1.1):

• `fun1`(`info`) ("Bug1") produces: Error: unhandled exception: 'sons' is not accessible using discriminant 'kind' of type 'TNode' [FieldError]
• `fun2`(`info`.line) ("Bug2") produces:macros.nim(533, 6) Error: type mismatch: got <varargs[untyped]> but expected 'string'

[krux02]

@narimiran I tried to verify your output. I only get this: SIGSEGV: Illegal storage access. (Attempt to read from nil?) for bug1.

[timotheecour]

that's why i usually use git hashes in bug reports; it's more precise than "devel"
in latest devel 574f613 1.1.1 i get the same as #9607 (comment)