nimble test fails with internal error

[erhlee-bird]

Run nimble init and fill in any package details you want, making sure to create a 'bin' package.
Add a dependency.

Example nimble init file below.

# Package

version       = "0.1.0"
author        = "Eric Lee"
description   = "A new awesome nimble package"
license       = "MIT"
srcDir        = "src"
bin           = @["test"]

# Dependencies

requires "nim >= 0.17.3"
requires "jester > 0.1"

Run nimble test --verbose.

    Setting Nim stdlib prefix to /home/ebird/.local/opt/nim
    Setting Nim stdlib path to /home/ebird/.local/opt/nim/lib
  Executing task test in /home/ebird/test/test.nimble
    Setting Nim stdlib prefix to /home/ebird/.local/opt/nim
    Setting Nim stdlib path to /home/ebird/.local/opt/nim/lib
  Verifying dependencies for test@0.1.0
    Reading official package list
   Checking for jester@> 0.1
 Installing jester@> 0.1
    Reading official package list
Downloading https://github.com/dom96/jester using git
    Cloning latest tagged version: v0.2.0
    Setting Nim stdlib prefix to /home/ebird/.local/opt/nim
    Setting Nim stdlib path to /home/ebird/.local/opt/nim/lib
       Info ???(???, 0) Error: internal error: n is not nil

nimble v0.8.8 compiled at 2018-02-03 00:48:31
git hash: 0a205d38686bd257ddedcc1aab5a9e16ec753a11

[Jeff-Ciesielski]

Just ran into the same issue but didn't require adding a 'bin' directory, mine is a library.

The issue appears to go away without any external dependencies.

Installed toolchain with choosenim(stable):
Nim version 0.18.0
Nimble version v0.8.10 compiled at 2018-03-07 14:33:02

Created a package with nimble init

# Package

version       = "0.1.0"
author        = "Jeff Ciesielski"
description   = "Consistent overhead byte stuffing for Nim"
license       = "MIT"
srcDir        = "src"

# Dependencies

requires "nim >= 0.18.0"
requires "einheit >= 0.1.11"

jeff.ciesielski:nim_cobs[master !?]> nimble test --verbose
    Setting Nim stdlib prefix to 
    Setting Nim stdlib path to /home/jeff.ciesielski/.choosenim/toolchains/nim-0.18.0/lib
       Info Hint: used config file '/home/jeff.ciesielski/.choosenim/toolchains/nim-0.18.0/config/nim.cfg' [Conf]
  Executing task test in /home/jeff.ciesielski/workspace/nim_cobs/cobs.nimble
    Setting Nim stdlib prefix to 
    Setting Nim stdlib path to /home/jeff.ciesielski/.choosenim/toolchains/nim-0.18.0/lib
  Verifying dependencies for cobs@0.1.0
    Reading official package list
   Checking for einheit@>= 0.1.11
      Info: Dependency on einheit@>= 0.1.11 already satisfied
    Setting Nim stdlib prefix to 
    Setting Nim stdlib path to /home/jeff.ciesielski/.choosenim/toolchains/nim-0.18.0/lib
       Info ???(???, 0) Error: internal error: n is not nil

Edit: If I get some time later, I'll try digging around to see if I can either figure out where this is originating from or maybe put together a patch. We're using Nim at work now, so upstream contributions are fair game :D

[dom96]

If I get some time later, I'll try digging around to see if I can either figure out where this is originating from or maybe put together a patch. We're using Nim at work now, so upstream contributions are fair game :D

Yay! Happy to hear more people using Nim at work :D

Some tips on debugging this:

• You're definitely going to want to grab the Nimble repo and compile Nimble in debug (by just running nim c src/nimble).
• Running Nimble with the --debug flag might give some more messages (--debug is a step above --verbose).
• This is likely a problem in the Nim compiler sources, so you might need to dig into them. You might find that if you compile Nimble you won't be able to reproduce this issue, if that's the case then you've compiled Nimble against a newer version of the compiler source (where the issue no longer exists).

[erhlee-bird]

Thanks for the tips @dom96

I took a look again and can reproduce with upstream-built nim(devel) and nimble(master).

Just echo debugging, I found that the Nimble code stops executing with the call to graph.processModule nimscriptsupport.nim#L338

And I found an error message for "n is not nil" in Nim's compiler/sem.nim.

Will dig more later.

[Vindaar]

Just did the same as @erhlee-bird and echo debugged my way through Nimble. I'm also seeing it fail on thegraph.processModule line.
Just a few notes on where it leads and eventually fails:

• The processModule being called is defined in https://github.com/nim-lang/Nim/blob/devel/compiler/passes.nim#L176
  • From here it fails on the closePasses(graph, a) call in line https://github.com/nim-lang/Nim/blob/devel/compiler/passes.nim#L253
• closePasses then is defined in https://github.com/nim-lang/Nim/blob/devel/compiler/passes.nim#L253
• In my case, gPassesLen - 1 is 3, and iterations 0 and 1 are fine. Then in iteration 2 the call fails on:

  m = gPasses[i].close(graph, a[i], m)

• the call for close calls the proc myClose in compiler/sem.nim (as @erhlee-bird mentioned) https://github.com/nim-lang/Nim/blob/devel/compiler/sem.nim#L606

And as the internal error suggests, the check for n != nil fails, i.e. the input parameter n: PNode is not nil in iteration 2. As far as my understanding goes that implies that we'd expect the myClose proc to return nil on iteration 1 (since the return value is assigned to m in closePasses, which is the parameter that is n in myClose), but it doesn't.

I don't even remotely understand enough to fix the issue. :)

In case someone wants to reproduce the error I see:
Using current devel branch it happens if I call nimble test in the folder of https://github.com/Vindaar/nimhdf5
if I comment out my custom test task in the nimble file.

The error then occurs while checking the arraymancer.nimble file.

Hopefully that helps someone to fix this.

[erhlee-bird]

Thanks for the really detailed explanation @Vindaar

[alaviss]

Might be related to this nim-lang/Nim#8590 (comment)

[timotheecour]

should we close this? /cc @erhlee-bird @dom96 @alaviss @Jeff-Ciesielski

can't reproduce using either latest nim devel (77f836b403af0bb130368ba05c96799393b2eeb9) or even nim at 85187d4ba379b4c08f77feb032632aa47837016f right before nim-lang/Nim#9259 was merged (which closed nim-lang/Nim#9068); so it could have been fixed already at some earlier point

[dom96]

Could you reproduce it before?

[erhlee-bird]

I think we can close this.
I was able to reliably trigger this a long time ago, but cannot reproduce anymore at both commits that @timotheecour mentioned.