Question: Why can't I compile when a Source Code Filter file has more than 32.748 chars in a single line?
I have chart from draw.io inlined with HTML in one of my *.tmpl files (to-be nimf). This has worked in 0.19.*, but breaks in 0.20.0. The problem is, when the length of a single line is equal to or longer than 32.749 chars. When breaking the line into multiple lines it compiles fine.
After finding the error above, I also discovered, that a string had a maximum of 32.752:
The 32.752 chars is corresponding to the char-length + newline chars in my *.tmpl file. Is 32.752 the maximum length of a string?
The compiling breaks even though the line is commented out (#).
Try this Play Nim xi
Error messages in the *.tmpl file
I have a gist which can be used to test it. It has a tmpl code with 32.750 chars (https://gist.github.com/ThomasTJdev/404866d90ee0bdcec2a0da8dc97c4c87)
The original inline HTML code was 511.102 chars and breaks the compiling with the following error message (a single string >= 32.754):
/Users/travis/build/nim-lang/nightlies/nim/e7471cebae2a404f3e4239f199f5a0c422484aac/lib/system/fatal.nim(48) sysFatal
Error: unhandled exception: value out of range: -1 [RangeError]
When I resize the size to exactly 32.749 chars I get the following error message (a single string = 32.753):
/Users/travis/build/nim-lang/nightlies/nim/e7471cebae2a404f3e4239f199f5a0c422484aac/lib/system/fatal.nim(39) sysFatal
Error: unhandled exception: over- or underflow [OverflowError]
Resizing to 32.748 chars it compiles fine (a single string <= 32.752).
This appears to actually not be a new bug, but an old one. The difference is that the compiler currently has overflow and range checks enabled.
The underlying problem is that line and column information for error reporting in the lexer is represented as 16-bit integers in order to save space (as that information is used internally in every lexer token). This could run into overflow issues before, they just were ignored.
A temp fix would be to make the relevant fields in TLineInfo in compiler/lineinfos.nim 32-bit integers, but that would up memory consumption unnecessarily for most projects. An alternative solution would be to use saturation arithmetic on line and column numbers, i.e. the values would cap at uint16.high or int16.high and to add information to error messages to note that column/line information is off.