async proc or closure iterator with specific variable names causes invalid C code generation

[tersec]

A sufficient (on 0.17.2 and current git head) few lines of code:

import asyncdispatch, sequtils, tables

# These table types don't seem to much matter, but I've
# not reproduced it without a TableRef.
proc main(): Future[void] {.async.} =
  let h1 = newTable(@[("", "")])
  let v2 = toSeq(values(h1))
  let v3 = toSeq(keys(h1))

Change the variable name h1 to anything else I've tried, and it compiles, but with h1:

Error: execution of an external compiler program 'gcc -c  -w  -I/home/user/Nim/lib -o /home/user/nimcache/test0.o /home/user/nimcache/test0.c' failed with exit code: 1

/home/user/nimcache/test0.c:207:4: error: duplicate member ‘h11’
 NI h11;
    ^~~
/home/user/nimcache/test0.c: In function ‘mainIter_5hUhZnHE8acBHekkyBVVlQ’:
/home/user/nimcache/test0.c:701:87: error: array subscript is not an integer
       T20_ = isFilled_IxXD1UAPoEehVDW9cv9cRaew_2tables((*(*colonenvP_).h11).data->data[(*colonenvP_).h11].Field0);
                                                                                       ^
/home/user/nimcache/test0.c:704:84: error: array subscript is not an integer
       asgnRefNoCycle((void**) (&(*colonenvP_).x10), (*(*colonenvP_).h11).data->data[(*colonenvP_).h11].Field1);

Using nimDumpAsync and removing unnecessary-for-reproduction parts:

import asyncdispatch, sequtils, tables

proc main(): Future[void] =
  var retFuture254020 = newFuture[void]("main")
  iterator mainIter254021(): FutureBase {.closure.} =
    let h1 = newTable(@[("", "")])
    let v2 = toSeq(keys(h1))
    let v3 = toSeq(keys(h1))
    complete(retFuture254020)

  var nameIterVar254024 = mainIter254021
  return retFuture254020

The types for which the TableRef is instantiated don't seem to much matter.

[ghost]

Seems to be fixed for me on latest devel. Tested on macOS with clang and gcc-8.
Can anyone else confirm (on other OSes)?

[data-man]

Works on Arch Linux, it's not surprising. :)

[ghost]

@data-man can be closed probably?

[data-man]

Sure.