Nim: Need a better line number / error message for Generic Instantantion Error with inheritance

[rayman22201]

This appears to be an interaction between Generics and inheritance.
The error message points to the instantiation of the first instance of the subclass, but the error should occur inside the type definition of the subclass. Otherwise it's not easy to determine where the actual error occurred. Especially in more complex programs.

Example

type
  GenericParentType[T] = ref object of RootObj
  GenericChildType[T] = ref object of GenericParentType # missing the [T]
    val: T

var instance : GenericChildType[int] = nil

Current Output

Hint: used config file '/nim/config/nim.cfg' [Conf]
Hint: system [Processing]
Hint: in [Processing]
in.nim(7, 32) Error: cannot instantiate: 'GenericParentType'

Expected Output

Hint: used config file '/nim/config/nim.cfg' [Conf]
Hint: system [Processing]
Hint: in [Processing]
in.nim(3, 32) Error: cannot instantiate: 'GenericParentType' inside type definition of 'GenericChildType'

idk if "instantiate" is the correct term in a type definition context, but it is consistent.

Additional Information

Nim Playground - Nim v0.19.0
Nim develop as of commit: 2039dad2736909a9d2091b137eeab4293b508e12

This example is simplified from this forum post:
https://forum.nim-lang.org/t/4566

[timotheecour]

Nim Playground - Nim v0.9.0

IMO all bug reports should either use latest devel, or, at least show behavior of latest devel

[rayman22201]

Nim Playground - Nim v0.9.0

IMO all bug reports should either use latest devel, or, at least show behavior of latest devel

That's absurd. Not everyone has access to the latest devel or can get access to it. Many users will be using particular release versions, especially as the language matures. users may not have the expertise, or have access to the necessary environment, or the time to build the latest devel to test a bug. It's not their responsibility to download and test with "latest devel". I don't compile and run the latest devel linux kernel if I think I have a kernel bug, or recompile gcc from source if I think I have a compiler bug there.

It is of course the prerogative of the core team to prioritize bugs how they see fit, possibly even to close the issue, but it's absurd to outright reject bug reports because the user can not confirm on devel.

That being said. I have just verified the same behavior with the latest git head.

[timotheecour]

That's absurd

we have > 1300 open bugs and limited resources to fixing them; if a bug is already fixed in devel, that's something worth mentioning that saves time for whoever's gonna look at that bug report
Likewise, using minimized examples (rather than a large complex code or even it doesn't work in my private code) is more effort for the bug writer, but saves time for everyone else.

I don't compile and run the latest devel linux kernel if I think I have a kernel bug, or recompile gcc from source if I think I have a compiler bug there

except it's really easy and fast in nim to get devel (or nightly); git pull --ff-only && ./koch boot -d:release takes much less time than writing your bug report

btw it's not that uncommon requirement for projects with lots of issues and few ppl who regularly contribute bug fixes, eg:

• new issue template for https://github.com/Homebrew/homebrew-core/issues/new?template=Reproducible-Bug-Report.md shows:

. - [ ] ran `brew update` and can still reproduce the problem?

• likewise with tmux new issues: when opening a new tmux issue it points to https://raw.githubusercontent.com/tmux/tmux/master/CONTRIBUTING which shows:

Please do not report bugs (crashes, incorrect behaviour) without reproducing on a tmux built from the latest code in Git.

so maybe what we're missing here is: nim update to make existing process even easier than git pull --ff-only && ./koch boot -d:release

[nc-x]

we have > 1300 open bugs and limited resources to fixing them; if a bug is already fixed in devel, that's something worth mentioning that saves time for whoever's gonna look at that bug report

Agreed.

But Users should not be expected to be using Devel branch because the released version is the one that is supposed to be stable and they are supposed to use them. Asking everyone to use devel before opening an issue would lead to people just saying meh and not opening any issue at all.

Also if good reproducible code is provided in the bug report, it just takes 20-30 seconds to try it out on Devel, if you have it installed.

git pull --ff-only && ./koch boot -d:release

What if the user is not using nim built from git? You can't expect people to use some other workflow just for opening an issue. It is too much friction.

new issue template for https://github.com/Homebrew/homebrew-core/issues/new?template=Reproducible-Bug-Report.md shows:
. - [ ] ran brew update and can still reproduce the problem?

Does brew update update to latest stable or latest git commit? I don't use Mac so IDK, but if it updates to latest git head, then it would be enough reason for me to not use brew at all.

so maybe what we're missing here is: nim update to make existing process even easier than git pull --ff-only && ./koch boot -d:release

That's what choosenim is for. And again, people should not be expected to be using choosenim. Everyone has their own workflow, plus choosenim doesn't even work great (yet) on windows.

[mratsim]

I'm fine with a reasonably recent devel (like past month) or the latest release/backports.

Not supporting the latest release is a bad signal.

That said, Nim v0.9.0 was like several years ago, do you mean 0.19.0?

[rayman22201]

That said, Nim v0.9.0 was like several years ago, do you mean 0.19.0?

Yes @mratsim that was a typo! Should be 0.19.0. Sorry. That's what the playground is currently on. Version number is fixed in the original post now.