Nim: 3 consecutive mapIt compilation problem

[timotheecour]

nim c -o:app -r bugs/t06_mapIt_redef.nim

simplified from a more complex example:

import sequtils

proc main()=
  let a = [1,2,3].
    mapIt(it).
    mapIt(it).
    mapIt(it)

main()

Error: execution of an external compiler program 'clang -c  -w  -I/Users/timothee/homebrew/Cellar/nim/0.18.0_1/nim/lib -o /Users/timothee/git_clone/nim/timn/build/nimcache/t06_mapIt_redef.o /Users/timothee/git_clone/nim/timn/build/nimcache/t06_mapIt_redef.c' failed with exit code: 1

/Users/timothee/git_clone/nim/timn/build/nimcache/t06_mapIt_redef.c:160:37: error: redefinition of 'result_4'
        tySequence_qwqHTkRvwhrRyENtudHQ7g* result_4;
                                           ^
/Users/timothee/git_clone/nim/timn/build/nimcache/t06_mapIt_redef.c:149:37: note: previous definition is here
        tySequence_qwqHTkRvwhrRyENtudHQ7g* result_4;
                                           ^
/Users/timothee/git_clone/nim/timn/build/nimcache/t06_mapIt_redef.c:161:34: error: redefinition of 't_4'
        tyArray_Bd4h7Ocx9bGTvrKzPIWNlHw t_4;
                                        ^
/Users/timothee/git_clone/nim/timn/build/nimcache/t06_mapIt_redef.c:150:34: note: previous definition is here
        tyArray_Bd4h7Ocx9bGTvrKzPIWNlHw t_4;
                                        ^
/Users/timothee/git_clone/nim/timn/build/nimcache/t06_mapIt_redef.c:162:5: error: redefinition of 'i_4'
        NI i_4;
           ^
/Users/timothee/git_clone/nim/timn/build/nimcache/t06_mapIt_redef.c:151:5: note: previous definition is here
        NI i_4;

[cooldome]

duplicate of https://github.com/nim-lang/Nim/issues/6986

[Yardanico]

@cooldome in this case it's C, in other issue it's C++

[timotheecour]

according to https://github.com/nim-lang/Nim/issues/6986#issuecomment-368171241

The issue is not that cpp specific. Small modification and it no longer compiles neither with C nor CPP backends:

so maybe a duplicate indeed, feel free to add a label Duplicate (@Araq is there one?) and close

[dom96]

We don't mark duplicates with labels, we just close them ;)

[Araq]

The fix only affected the stdlib, the codegen still is buggy. Re-opening.

[narimiran]

The original example works in 0.19. Can this be closed?

[timotheecour]

see @araq's comment right above: "The fix only affected the stdlib, the codegen still is buggy. Re-opening."

[Clyybber]

Can we please not close valid issues (speaking in general, not just this issue)?
Forcing a limit of issues on @timotheecour isn't a great idea IMO. One should rather be grateful to timothee for reporting those.

[krux02]

@Clyybber first of all, don't say "we" when you mean "timotheecour". He was given the order to put some priorities in his almost 200 open issues he was shitting them out with very poor quality overall. Hard to read hard to understand and often just for his personal weird workflow. This took us the maintainers busy with very little gain. But instead of actually putting some effort in this task, he just took issue that have a lot of participants to ping as many people as possible about how stupid this arbitrary limit is. That is trolling.

[Clyybber]

@krux02 @timotheecour @narimiran So do we all agree that those issues should be reworked to be of better quality and match the issue template, instead of closing them as wontfix?

[krux02]

@Clyybber probably.

[krux02]

@Clyybber I just checked the example with current nim. It isn't even a problem anymore. The pseudo tag WONTFIX is a straight lie.

[Clyybber]

@krux02 Araq reopened this issue, because

The fix only affected the stdlib, the codegen still is buggy. Re-opening.