The nim compiler doesn't report the error lines properly after 65535 lines

Example

for i in `seq 1 70000`; do echo "echo 1" >> gg.nim; done
echo "let x: int = \"a\"" >> gg.nim
nim c -r gg.nim

Current Output

.../gg.nim(655535, 14) Error: type mismatch: got <string> but expected 'int'

Expected Output

.../gg.nim(70001, 14) Error: type mismatch: got <string> but expected 'int'

$ nim -v
Nim Compiler Version 1.2.0

But is this REALLY an issue? I would not consider files with more than 65535 lines (the previous limit was 32767 with int16 but it was changed to uint16) to be useful

[alehander92]

this should be specified and an error message for that should be printed

[alehander92]

this can be a problem for autogenerated libs e.g. parsers or something

This came up for us when we generated a big file and no, we don't want to split it because we don't have to do that in any other language, just like we don't have to workaround the case-insensitivity issues either.

[Clyybber]

I think the best course of action here is to render the line number as ??? or >65535. Changing the size of the lineinfo number would hurt performance and probably memory usage. I suggest using include or consuming AST via macros or something.
And I suppose you want to catch errors before the nim layer anyways if what you are working on is a language that compiles to Nim (is it?).

I think the best course of action here is to render the line number as ??? or >65535.

That would be still useless.

Changing the size of the lineinfo number would hurt performance and probably memory usage.

We are talking about a few bytes here. This is just pico-optimization.

if what you are working on is a language that compiles to Nim (is it?).

Not really.

I still think that >65535 lines of code is a pretty okay limit for 99.99%, and otherwise you can always just use include :)

This came up for us when we generated a big file and no, we don't want to split it because we don't have to do that in any other language, just like we don't have to workaround the case-insensitivity issues either.

not sure which "case-insensitivity" issues you're talking about here, but this issue isn't about that, so okay :)

EDIT: Also I hope you know that if you combine different "pico-optimizations" you get real performance impact :)

I still think that >65535 lines of code is a pretty okay limit for 99.99%, and otherwise you can always just use include :)

It's a pointless limit because you might spare like 16 bits mid-compilation(with uint32).

not sure which "case-insensitivity" issues you're talking about here, but this issue isn't about that, so okay :)

Nim identifiers are case-insensitive and ignore underscores - really bad for C compatibility.

EDIT: Also I hope you know that if you combine different "pico-optimizations" you get real performance impact :)

I also hope you know that it is not even worth to be called an optimization because it just wastes developer time. With the introduction of the include statements and their references we will still need to increase the compiler's memory usage.

[disruptek]

I generate files with >100k lines of real code. The key word here is “generate”. I don’t care what the error message says in the event of an error.

Also, the design responsible for this problem of tracking line numbers absolutely is silly and embarrassing, not least because it has real bearing on other design in the compiler (eg. IC).

[alehander92]

trialism those 16 bits are part of each Node object: so they are much more than 16 bits , 16 * all the node objects : I think there is a miscommunication here, this isn't a single value!

[Araq]

How exactly are you not wasting your developer time by creating such large files?

How exactly are you not wasting your developer time by creating such large files?

Sometimes we need to generate code and sometimes those source files are really big and are either hard to split up or there would be too much splits.

[Araq]

Yes, I understand, but compile-times are important too, so usually it matters to generate less code for reasons having nothing to do with Nim's line cap quirk. Maybe your generated code can generate procs or templates or something, code compression techniques usually work fine. The Nim compiler itself is only about 80_000 lines of code fwiw (not counting the stdlib it uses).

[timotheecour]

@trialism you can as suggested above split your generated code in several includes. This should not affect CT performance.

# module large
include large_split0
include large_split1
include large_split2
...

but most likely you should be able to make better use of macros/templates to avoid generating so much code.