Nim doc fail to run for nim 1.2.0 (nim 1.0.4 is ok)

[me7]

When I run nim doc WHATEVER.nim it's error

Example

nim doc jester

Current Output

Hint: used config file 'C:\Users\ball\.choosenim\toolchains\nim-1.2.0\config\nim.cfg' [Conf]
Hint: used config file 'C:\Users\ball\.choosenim\toolchains\nim-1.2.0\config\nimdoc.cfg' [Conf]
Hint: system [Processing]
fatal.nim(49)            sysFatal
Error: unhandled exception: pathutils.nim(70, 11) `not isAbsolute(f.string)` C:\Users\ball\.choosenim\toolchains\nim-1.2.0\lib\system.html [AssertionError]

Expected Output

Run Ok and generate jester.html

Possible Solution

• use version 1.0 to generate doc

choosenim 1.0.4
nim doc jester

Additional Information

• It was working in version 1.0.4

$ nim -v
Nim Compiler Version 1.2.0 [Windows: amd64]
Compiled at 2020-04-03
Copyright (c) 2006-2020 by Andreas Rumpf

git hash: 7e83adff84be5d0c401a213eccb61e321a3fb1ff
active boot switches: -d:release

[narimiran]

I've tried to reproduce by running the exact command you provided (because when I tried it with my packages there was no problem), but it turns out that for me nim doc jester works without any problem and builds jester.html and nimdoc.out.css.

The only difference is that I'm not using choosenim, and I'm on Linux (based on C:\Users\ball\... I guess you're on Windows).

[juancarlospaco]

Cant repro.

[me7]

Yes, I'm windows user that install using choosenim.
Want to help you to resolve this because my configuration should common among windows users but rarely on core team but my knowledge is limited.

btw, seem issue is from choosenim. When I use choosenim devel (v1.3.1) it's still fail to gen doc. But if I use binary that compile by myself (choosenim d:\code\Nim), nim doc not have any problem to generate document

I'm will to help to solve the problem. if you can provide some guidance to check i'll help do it.

[timotheecour]

jester breaks nim doc

nim doc jester actually fails for a git clone'd jester for any file that imports jester, but for a different reason:

git clone  https://github.com/dom96/jester
cd jester
nim doc --warnings:off jester.nim
/private/tmp/d06/jester/jester.nim(380, 1) template/generic instantiation from here
/private/tmp/d06/jester/jester.nim(381, 24) Error: type mismatch: got <Request, utils.Settings>

which is essentially the same as the issue I had reported last year in dom96/jester#185 ; I had a fix that worked but somehow my PR got closed (see dom96/httpbeast#14)

can't reproduce your issue

as for the issue you're seeing, I can't reproduce, neither on OSX nor windows; apart from a git clone'd jester, nim doc foo works where foo is a valid path (absolute or relative)

it looks like there's a bug in choosenim though:

• with choosenim $dir: nim's config.nims is read (for nim doc and nim c etc)
  'C:\Users\timothee\git_clone\Nim\config\config.nims'
• with choosenim 1.2.0: nim's config.nims is not read (for nim doc and nim c etc), and in fact isnt' even copied over:

\ls /Users/timothee/.choosenim/toolchains//nim-1.2.0/config
nim.cfg         nimdoc.cfg      nimdoc.tex.cfg

(likewise on windows)
this probably doesn't explain your bug because Nim/config/config.nims currently doesn't contain anything relevant, but might in the future
EDIT: filed dom96/choosenim#193

[me7]

Ok, if issue cannot reproduce then it's can close.
I do have workaround for the problem and maybe nobody never have it.
Thanks for helping :)

[rockcavera]

It doesn't work here either. This is true for any neem code or package. The problem does not occur in version 1.0.0.

Example: I am inside the folder of the source code of my iputils package and I type: nim doc iputils

Output devel:

C:\Users\Jose\Desktop\projetos\iputils\nim-iputils\src>nim --version
Nim Compiler Version 1.3.1 [Windows: amd64]
Compiled at 2020-04-16
Copyright (c) 2006-2020 by Andreas Rumpf

git hash: 6914de0d8dfb14e4ebe0448c558466c9bb80d833
active boot switches: -d:release

C:\Users\Jose\Desktop\projetos\iputils\nim-iputils\src>nim doc iputils
Hint: used config file 'D:\Nim\config\nim.cfg' [Conf]
Hint: used config file 'D:\Nim\config\config.nims' [Conf]
Hint: used config file 'D:\Nim\config\nimdoc.cfg' [Conf]
Hint: system [Processing]
fatal.nim(49)            sysFatal
Error: unhandled exception: pathutils.nim(70, 11) `not isAbsolute(f.string)` D:\Nim\lib\system.html [AssertionError]

In version 1.0.0:

C:\Users\Jose\Desktop\projetos\iputils\nim-iputils\src>nim --version
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

C:\Users\Jose\Desktop\projetos\iputils\nim-iputils\src>nim doc iputils
Hint: used config file 'D:\nim-1.0.0\config\nim.cfg' [Conf]
Hint: used config file 'D:\nim-1.0.0\config\nimdoc.cfg' [Conf]
Hint: system [Processing]
Hint: widestrs [Processing]
Hint: io [Processing]
Hint: iputils [Processing]
Hint: ipv4 [Processing]
Hint: strutils [Processing]
Hint: parseutils [Processing]
Hint: math [Processing]
Hint: bitops [Processing]
Hint: macros [Processing]
Hint: algorithm [Processing]
Hint: unicode [Processing]
Hint: ipv6 [Processing]
Hint: utils [Processing]
Hint: cidr [Processing]
Hint: operation successful (28125 lines compiled; 0.819 sec total; 37.934MiB peakmem; Debug Build) [SuccessX]

[timotheecour]

really hard to investigate a bug that I can't reproduce;

• more context needed; https://github.com/goldenreign/nim-iputils doesn't have a src folder, where is the code? ideally if you can minimize (eg using as few files as possible) that would help a lot

in the same folder, what's the output for:

• dir
• nim doc iputils.nim
• nim doc C:\Users\Jose\Desktop\projetos\iputils\nim-iputils\src\iputils.nim
• nim c iputils
• nim c C:\Users\Jose\Desktop\projetos\iputils\nim-iputils\src\iputils.nim

[timotheecour]

I think I figured it out! from looking at ur example, that regression seems to happen when nim is installed in some drive eg D:\ and nim doc foo is called with foo being on another drive (eg C:\)

note that the bug (or some other related bug) might be pre-existing to the regression, and the regression would only be a symptom. But the root cause should be fixable.

[rockcavera]

really hard to investigate a bug that I can't reproduce;

• more context needed; https://github.com/goldenreign/nim-iputils doesn't have a src folder, where is the code? ideally if you can minimize (eg using as few files as possible) that would help a lot

in the same folder, what's the output for:

• dir
• nim doc iputils.nim
• nim doc C:\Users\Jose\Desktop\projetos\iputils\nim-iputils\src\iputils.nim
• nim c iputils
• nim c C:\Users\Jose\Desktop\projetos\iputils\nim-iputils\src\iputils.nim

The link to the iputils package I used is this one: https://github.com/rockcavera/nim-iputils

I think I figured it out! from looking at ur example, that regression seems to happen when nim is installed in some drive eg D:\ and nim doc foo is called with foo being on another drive (eg C:\)

note that the bug (or some other related bug) might be pre-existing to the regression, and the regression would only be a symptom. But the root cause should be fixable.

That's right! I just tested here. My Nim is installed in D:, when I do nim doc iputils which is in C:\ the error occurs. But if I play iputils for D:\ it works normally. However, it is a regression, as in version 1.0.0 it works normally.

[khchen]

I encountered the same issue. And then I found where is the bug.
In docgen.nim:

proc presentationPath*(conf: ConfigRef, file: AbsoluteFile, isTitle = false): RelativeFile =
  # omit...
  template bail() =
    result = relativeTo(file, conf.projectPath)

I change it to:

  template bail() =
    echo "relativeTo(", file, ", ", conf.projectPath, ") = ", relativeTo(file, conf.projectPath)
    result = relativeTo(file, conf.projectPath)

The output:

relativeTo(C:\Users\user\.nimble\pkgs\winim-3.3.3\winim\lean.nim, D:\nim) = C:\Users\user\.nimble\pkgs\winim-3.3.3\winim\lean.nim
fatal.nim(49)            sysFatal
Error: unhandled exception: pathutils.nim(70, 11) `not isAbsolute(f.string)` C:\Users\user\.nimble\pkgs\winim-3.3.3\winim\lean.html [AssertionError]

It is obviously, the following code assume presentationPath() will only return the relative path. However, it sometimes return absolute path if it cannot get the relative path.

[timotheecour]

import os
proc main()=
  let a = r"C:\Users\user\.nimble\pkgs\winim-3.3.3\winim\lean.nim"
  let b = r"D:\nim"
  echo isRelativeTo(a, b)
  echo relativePath(a, b)
static: main()

nim c --os:windows $timn_D/tests/nim/all/t10606.nim
true
C:\Users\user\.nimble\pkgs\winim-3.3.3\winim\lean.nim

has a bug indeed when drives differ on windows.
correct behavior should be:

• isRelativeTo should return false

• relativePath should throw
  (also need to check pathutils.relativeTo)

• and then we have the windows horror of “C:2\” in a windows path string mean? https://superuser.com/questions/796379/what-does-c2-in-a-windows-path-string-mean

• and UNC paths, \\.\UNC\LOCALHOST\c$\temp\test-file.txt"

• and also C:tempdir\tmp.txt is probably incorrectly handled in stdlib, apparently, this represents a relative path in windows... https://superuser.com/a/1148718/295075

# "C:tempdir\tmp.txt" refers to a file in a subdirectory to the current directory on drive C.
import os
proc main()=
  echo r"C:tempdir\tmp.txt".isAbsolute
static: main()

@khchen I'm not a windows user so it may be easier for you, if you feel like contributing some bug fixes for windows?

I wonder if it's possible to invent a more arbitrarily complex system than window's path handling.

sources

• indeed: https://docs.microsoft.com/en-us/dotnet/standard/io/file-path-formats
  C:Projects\apilibrary\apilibrary.sln | A relative path from the current directory of the C: drive.

• https://desktop.arcgis.com/en/arcmap/10.3/tools/supplement/pathnames-explained-absolute-relative-unc-and-url.htm

Relative paths cannot span disk drives. That is, if the root directory is on drive D, you cannot use relative paths to navigate to a directory on drive E

[me7]

@khchen @timotheecour Thanks for find the root cause and explain in detail.
But the think what I'm not understand is why v1.0 not have a problem but v1.2 have?
Can we just fix it by using code from v1.0?

[timotheecour]

bug fixes can introduce regressions for use cases that weren't being tested. If you use code from 1.0 you'll undo the bugfixes.
The only way is to dig in the code and fix it; do you think you can help with a PR? I don't expect this to be hard at all, and I can help if needed.