Nim: cryptic error (with wrong line number) when using template substitution with keyword argument call

[timotheecour]

EDIT for clarity:
I get a cryptic error (with wrong line number) when using template substitution with keyword argument call, see code below.

• with nim -d:case1 main.nim I get this error:

t48_name_interference.nim(6, 21) Error: identifier expected, but found '""'
    template fun*(a = ""): untyped =

this error: t48_name_interference.nim(6, 21) Error: identifier expected, but found '""' is cryptic; I reduced it from a more complex case where it was hard to figure out what was going on.
The root cause is the template substitution substitutes the keyword argument call funAux(a = "asdf1") with funAux("" = "asdf1") , causing an error.
However, note that the error msg points to the wrong line: template fun*(a = "") instead of pointing to the line where it results in incorrect code: funAux(a = "asdf1")

• with nim -d:case2 main.nim I get this error:

Error: type mismatch: got <strDef: string>
but expected one of:
proc funAux(a: string)

expression: funAux(strDef = "asdf1")

this is the same root cause but the symptom is different, resulting in Error: type mismatch: got <strDef: string> error message, which is more ok (at least the line number is correct)

type Bar = object
  a: string
proc funAux*(a: string)=discard

when defined(case1):
  template fun*(a = ""): untyped =
    let bar = ""
    funAux(a = "asdf1")
    # Note: would have same error with object/tuple construction, eg:
    var foo = Bar(a: "foo")
    foo.a = "baz"
  fun()

when defined(case2):
  const strDef* = ""
  template fun*(a: string = strDef): untyped =
    funAux(a = "asdf1")
  fun()

proposal

• more friendly error msg pointing to actual place where error occurs (see case1 above)
• allow quoting to bypass name replacement => see https://github.com/nim-lang/Nim/issues/8899

[Araq]

Please re-read your posts before posting. It starts with the header "for case2:" and goes downhill from there. You have two seperate issues but merged them in a single snippet with defined(case1) etc. Think I can copy and paste that into a test case easily? In fact, I can hardly be bothered to read this issue.

[Clyybber]

I also think snippets with when defined(caseX) are more complicated than it needs to be.

[timotheecour]

I edited the issue description, hopefully it's clearer now. Only case1 is the real issue here, but case2 is also shown for comparison. I actually like this when defined(caseX) pattern as it allows to run different code paths without having to edit code (the alternative is more messy especially in more complex cases: comment this and that, etc).

[dom96]

I'm sorry to say this but a lot of your issues have this problem. It would make our work far easier if you could try to shorten your issues as much as possible. Right now many of them feel like a wall of text that's difficult to understand.

[timotheecour]

in this case the TLDR was in the title and the first few lines. I'm usually adding more info when I believe it helps to diagnose the issue towards possible resolution (eg to narrow down the cases in which the bug occurs). What I (almost) always do is minimize the test case and have it self contained / copy pasteable, easily triggering each error without having to edit the source code, using compiler flags -d:caseX