Fail to compile a file twice under Windows (v1.0 bug).

nim-lang / Nim

Nim is a statically typed compiled systems programming language. It combines successful concepts from mature languages like Python, Ada and Modula. Its design focuses on efficiency, expressiveness, and elegance (in that order of priority).

https://nim-lang.org

Other

16.58k stars 1.47k forks source link

Fail to compile a file twice under Windows (v1.0 bug). #12242

Closed khchen closed 5 years ago

khchen commented 5 years ago

The problem code bug.nim (yes, only one line):

import wNim

Compile by "nim c bug" or "nim c -f bug", it works.

Hint:  [Link]
Hint: operation successful (146616 lines compiled; 5.701 sec total; 212.258MiB peakmem; Debug Build) [SuccessX]

Try it again immediately (without "-f"):

oserr.nim(94)            raiseOSError
Error: unhandled exception: The filename, directory name, or volume label syntax is incorrect.
 [OSError]

I notice there is a file named "@m..@s..@s..@sC" in the nimcache folder. If I delete all other files, the error still occurred. Conversely, if I just delete "@m..@s..@s..@sC", the compilation succeeds.

Additional Information


$ nim -v
Nim Compiler Version 1.0.0 [Windows: amd64]
Compiled at 2019-09-23
Copyright (c) 2006-2019 by Andreas Rumpf

git hash: f7a8fc46c0012033917582eb740dc0343c093e35
active boot switches: -d:release```

kraptor commented 5 years ago

I was able to reproduce the same behavior: first time works, second time breaks (except if -f to force building everything from scratch).

I tested the deletion of the file @khchen noticed in the nimcache: @m..@s..@s..@s..@sC and then build proceeds correctly (whithout -f).

Note the file is an empty stale file.

During compilation, on my side, I also noticed the following (I don't know if this is related of not):

CC: ../../../../C:/Users/kr/.nimble/pkgs/nimgl-#1.0/nimgl/private/logo.nim
CC: ../../../../C:/Users/kr/.nimble/pkgs/nimgl-#1.0/nimgl/glfw.nim
CC: ../../../../C:/Users/kr/.nimble/pkgs/nimgl-#1.0/nimgl/opengl.nim
CC: ../../../../C:/Users/kr/.nimble/pkgs/nimgl-#1.0/nimgl/imgui.nim
CC: ../../../../C:/Users/kr/.nimble/pkgs/nimgl-#1.0/nimgl/imgui/impl_opengl.nim
CC: ../../../../C:/Users/kr/.nimble/pkgs/nimgl-#1.0/nimgl/imgui/impl_glfw.nim

Which seems odd, I don't think windows resolves correctly these files...

kraptor commented 5 years ago

I just tried cpp backend, and I confirm the same behavior.

kraptor commented 5 years ago

I've been reviewing commit history. May this be related?

https://github.com/nim-lang/Nim/commit/fd634434192bf071e11ab9710711723130adf46a

I'm bisecting now to check...

kraptor commented 5 years ago

Ok, I (think) I found the culprit here: https://github.com/nim-lang/Nim/pull/12149

I have no idea how to fix this, but that merge is the one that triggers the issue. May someone else confirm?

kraptor commented 5 years ago

Issue is triggered when compiler creates files in nimcache from a different windows drive, it seems. In my case, compiler + nimcache is in C: but project is in D:, thus creating an invalid relative path...

kraptor commented 5 years ago

Did a search in discord channel, it seems that someone else got to the same conclusion:

<demotomohiro> I guess fakePackageName proc in compiler/packagehandling.nim making invalid path because relativeTo proc doesnt work when input paths have different drive letter.

kcvinker commented 4 years ago

Somebody, please tell the work around for this problem. I have the same problem here. But when my VS code shows this osErr, i can compile via CMD.

narimiran commented 4 years ago

Somebody, please tell the work around for this problem.

Update to Nim v1.0.2