Re: Possible compiler bug?

2018-02-22 Thread twetzel59
Looks like this has happened before. [Here is the issue](https://github.com/nim-lang/Nim/issues/6927).

Re: Possible compiler bug?

2018-02-19 Thread mratsim
Yes, once Nim checked your code it should never crash in GCC/Clang. Compiler should also never crash during compilation (Red text with "Internal Error") You can report it in the Github issue.

Possible compiler bug?

2018-02-19 Thread StasB
Hello! This bug is quite easy to reproduce: proc test(a: int, b: int = a) = echo a, b test(5) I do get a compiler error, but from gcc. I imagine that's not supposed to happen. It happens both in 0.17.2 and the devel version.

Re: possible compiler bug with generics?

2017-10-28 Thread wizzardx
Or at least, I think that's probably a fundamental underlying model. There's a lot of higher level clever things that Nim does before getting to separate C files, I think separate .c units is just an optimisation not a restriction, but that it did to some extent shape how the Nim compiler logic

Re: possible compiler bug with generics?

2017-10-28 Thread wizzardx
I checked things a bit. I _think_ it's an artifact of Nim code compiling each nim file into a separate .c file. After that point the regular C toolchain takes over. c gets compiled to .so, and then .so files get compiled to the final binary. Anyhow, at the .so level, there's some symbols

Re: possible compiler bug with generics?

2017-10-28 Thread mratsim
Actually I think there is a difference between how types and procs are treated, I don't know if this is intentional. This compiles: types.nim type Foo* = distinct int proc toFoo*(x: int): Foo = Foo(x) lib.nim import types proc

Re: possible compiler bug with generics?

2017-10-28 Thread jangko
@wizzardx is correct, this is normal Nim behaviour. Nim generic proc is instantiated at _callsite_. The above example, Bar is instantiated at bug.nim not at lib.nim, and at that time, the scope where the Bar is instantiated have no information about Foo symbol.

Re: possible compiler bug with generics?

2017-10-28 Thread wizzardx
I think that's just normal Nim behavior, right? If module A imports module B, and module B imports module C, then module A won't automatically see everything that B imported that was able to let B compile? You could probably solve the probly by either: 1\. Import types.nim in bug.nim, to

Re: possible compiler bug with generics?

2017-10-27 Thread jackmott
Ok I figured it out, not sure if bug or user error: proc BufferData in File A which imports opengl, which defines GLenum, used by BufferData File B calls BufferData, but does not import opengl, and I get an error about the type defined in opengl. If I add the opengl import to File B, it

Re: possible compiler bug with generics?

2017-10-27 Thread mratsim
Can you post a minimum working example with all types declared. We can't reproduce your issue because: * BufferTarget is undeclared * BufferDataUsage is undeclared * glBufferData is undeclared * GLenum is undeclared * GLsizeiptr is undeclared Alternatively post an example with Nim

possible compiler bug with generics?

2017-10-27 Thread jackmott
I have this function: proc BufferData*[T](target:BufferTarget, data:openarray[T], usage:BufferDataUsage) {.inline.} = glBufferData(target.GLenum,data.len*T.sizeof().GLsizeiptr,data.unsafeAddr,usage.GLenum) It works fine if I pass it a seq[float32]. If I pass it a