Injected symbols aren't resolved properly in expression passed to inner template

[exelotl]

In the example below:

• We are using applyIt from inside some template
• A symbol called it already exists at the top level

The program doesn't compile, because the compiler thinks we are referring to the existing it rather than the one injected by the applyIt template.

Example

import sequtils

var it: string
var nums = @[1,2,3]

template doubleNums() =
  nums.applyIt(it * 2)

doubleNums()
echo nums

Current Output

...
Hint: main [Processing]
Hint: sequtils [Processing]
Hint: macros [Processing]
/home/exelotl/nim/test/it_conflict/main.nim(9, 11) template/generic instantiation of `doubleNums` from here
/home/exelotl/nim/test/it_conflict/main.nim(7, 19) Error: type mismatch: got <string, int literal(2)>
but expected one of: 
proc `*`(x, y: float): float
  first type mismatch at position: 1
  required type for x: float
  but expression 'it' is of type: string
proc `*`(x, y: float32): float32
  first type mismatch at position: 1
  required type for x: float32
  but expression 'it' is of type: string
...
proc `*`[T](x, y: set[T]): set[T]
  first type mismatch at position: 1
  required type for x: set[T]
  but expression 'it' is of type: string

expression: it * 2

Expected Output

@[2, 4, 6]

Additional Information

A workaround is to use a macro that forces it to be an ident, preventing the compiler from making the wrong assumptions about what it could be.

import sequtils, macros

var it: string
var nums = @[1,2,3]

macro doubleNums() =
  let it = ident("it")
  quote do:
    nums.applyIt(`it` * 2)

doubleNums()
echo nums

---

$ nim -v
Nim Compiler Version 1.2.6 [Linux: amd64]

[ringabout]

dirty is another workaround.

import sequtils

var it: string
var nums = @[1,2,3]

template doubleNums() {.dirty.} =
  nums.applyIt(it * 2)

doubleNums()
echo nums

[metagn]

I just got this bug and was shocked to find this is the oldest issue I could find; it's not a regression, I tested it in 0.13 and it still errors. In my case, it completely ignores the symbol created inside the template:

proc foo(x: int) = echo x

template bar() =
  proc foo(y: string) = echo y
  foo("abc")

bar()

/usercode/in.nim(7, 1) Error: type mismatch: got <string>
but expected one of: 
proc foo(x: int)
  first type mismatch at position: 1
  required type for x: int
  but expression '"abc"' is of type: string

expression: foo("abc")

Since procs are injected by default you don't need an {.inject.}, but this is fixed with {.dirty.}. Changing the result type of the template to untyped also doesn't fix it.