Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Path in error message has ..\..\..\..\..\ prefix since 0.19.0 #9556

Closed
ghost opened this issue Oct 29, 2018 · 10 comments
Closed

Path in error message has ..\..\..\..\..\ prefix since 0.19.0 #9556

ghost opened this issue Oct 29, 2018 · 10 comments

Comments

@ghost
Copy link

@ghost ghost commented Oct 29, 2018

I noticed this a few weeks ago and never saw it before. Here is an example:

type A* = object
  b: var A
  c: string

echo A()

(code is from here )

Errors on devel (windows) and I think also at least on 0.19.0 with

filename.nim(5, 7) template/generic instantiation of `$` from here
..\..\..\..\..\C:\Program Files\Nim\lib\system.nim(2661, 15) Error: generic instantiation too nested

I'm pretty sure some time ago the paths to filename were normal (@narimiran confirmed it's same/similar on linux, started not so long ago).
(I run the compilation from vscode if that makes a difference).

Code producing the new path too:
#9488 (comment)
#9420 (comment)

@narimiran
Copy link
Member

@narimiran narimiran commented Oct 29, 2018

Here is the linux version, using choosenim:

  • using devel:
filename.nim(5, 7) template/generic instantiation of `$` from here
../../../../../.choosenim/toolchains/nim-#devel/lib/system.nim(2661, 15) Error: generic instantiation too nested
  • using stable:
filename.nim(5, 7) template/generic instantiation from here
../../../../../.choosenim/toolchains/nim-0.19.0/lib/system.nim(2536, 15) Error: generic instantiation too nested

@ghost
Copy link
Author

@ghost ghost commented Oct 29, 2018

The original code crashes on nim 0.18.0 windows so I couldn't test it.
This one works on version 0.18.0 and produces a path without prefix there.
On 0.19.0 stable and later (devel) the path is for this example with prefix (not good anymore).

@ghost ghost changed the title Path in error message has ..\..\..\..\..\ prefix since some time Path in error message has ..\..\..\..\..\ prefix since 0.19.0 Oct 29, 2018
@ghost
Copy link
Author

@ghost ghost commented Nov 1, 2018

Here is a minimal example showing where the prefix path appears:

echo 1

compile with nim c --verbosity:3 file.nim using nim 0.19.0

@Araq
Copy link
Member

@Araq Araq commented Nov 2, 2018

Cannot reproduce this. How do you setup your paths?

@ghost
Copy link
Author

@ghost ghost commented Nov 2, 2018

I have windows 7 x64 with and tested it with nim 0.18.0 and 0.19.0 and gcc 8.1.0 (gcc (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0) and gcc 8.2.0 (gcc (Rev3, Built by MSYS2 project) 8.2.0) all x64.

nim is installed to: C:\Program Files\Nim\bin\nim.exe
mingw gcc to C:\Program Files\mingw64\bin\gcc.exe
msys gcc to C:\msys64\mingw64\bin\gcc.exe

when testing the 4 combinations both 0.18.0 show normal paths and both 0.19.0 have the prefix with the example from here.

It seems to change the path prefix dependent on the location of file.nim starting with 0.19.0

@Araq
Copy link
Member

@Araq Araq commented Nov 2, 2018

But where is your file.nim located?

@narimiran
Copy link
Member

@narimiran narimiran commented Nov 2, 2018

But where is your file.nim located?

It doesn't matter where (well, the number of ../ changes, depending on the location of file.nim), the error always print the path to system.nim starting from the location of the file.

@ghost
Copy link
Author

@ghost ghost commented Nov 2, 2018

at C:\file.nim I get Program Files\Nim\lib\system.nim
at C:\Users\-\file.nim I get ..\..\Program Files\Nim\lib\system.nim
and so on. Before 0.19.0 it was different.
With 0.18.0 I get:
at C:\file.nim I get lib\system.nim
at C:\Users\-\file.nim I get lib\system.nim

The new output results in harder to read paths.

@nc-x nc-x mentioned this issue Nov 2, 2018
@Araq Araq closed this in 7a15d2d Nov 2, 2018
narimiran added a commit that referenced this issue Nov 3, 2018
(cherry picked from commit 7a15d2d)
@narimiran
Copy link
Member

@narimiran narimiran commented Nov 3, 2018

This is marked as fixed, but I've tried to run it with the latest devel (Compiled at 2018-11-03) and I still get:

filename.nim(5, 7) template/generic instantiation of `$` from here
../../../../.choosenim/toolchains/nim-#devel/lib/system.nim(2673, 15) Error: generic instantiation too nested

@narimiran narimiran reopened this Nov 3, 2018
@nc-x
Copy link
Contributor

@nc-x nc-x commented Nov 3, 2018

narimiran added a commit to narimiran/Nim that referenced this issue Jan 24, 2019
The old logic wasn't very useful because
`relPath` is almost always shorter than `absPath`,
e.g. `../../../../../` is shorter than `C:\Program Files`.

This way allows the usage of a relative path for
at most two levels deep, e.g. `../../relPath`,
otherwise the absolute path is used.
@narimiran narimiran closed this in 251b014 Jan 24, 2019
narimiran added a commit that referenced this issue Jan 25, 2019
ThomasTJdev added a commit to ThomasTJdev/Nim that referenced this issue Jan 27, 2019
The old logic wasn't very useful because
`relPath` is almost always shorter than `absPath`,
e.g. `../../../../../` is shorter than `C:\Program Files`.

This way allows the usage of a relative path for
at most two levels deep, e.g. `../../relPath`,
otherwise the absolute path is used.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants