Large, single-file sources of F# get the line number and debug-stepping totally wrong

If your source file is sufficiently large (essentially, over 2^16 or 64k lines long) the line number used when source stepping, or the curlies that you on syntax errors, are reported on totally wrong lines (essentially, current line minus 2¹⁶).

This may not happen often in practice, but if it happens, it is highly confusing. I suggest to either raise a compile error “source file to large, maximum of 65535 lines reached, consider splitting your source in multiple source files” or to allow a integer instead of a short for the line number counter. I don’t think it is a limitation of .NET or Visual Studio, large auto-generated source files in C# do not exhibit this problem.

A practical issue with this is specifically autogenerated files, for instance, we use a Dynamics CRM mapping which generates a single file of 350k lines for the entity mappings using Microsoft tooling. Converting that to F# is currently not an option.

Since the auto-created function names use line numbers to identify them, this has the effect that line numbers on such functions point to the wrong location. I have not tried whether this could confuse the compiler in creating such names.

This was also reported on StackOverflow with a screenshot.

See how the debugger stops at a blank line, how the selection is wrong, and how the code-coverage tools report non-existing lines as hit:

A by-product of this behavior is that setting a breakpoint with F9 will actually set it on the non-existing line, as if no breakpoint was set on the actual code.

Note, surprisingly, __LINE__ stores the correct line information.

---

PS: previously, and in some comments, this entry also showed an example that, next to the wrong line numbers being reported, also crashed Visual Studio. I have now moved that into a separate bug entry: #779.

[cartermp]

Fixed in #4476

[abelbraaksma]

Fantastic! Thanks!