盲源步进之谜，或 F# 如何在大型源文件上表现不稳定
The mystery of blind source stepping, or how F# behaves erratically on large source files
我正在测试我是否可以依赖 __LINE__ 始终 return 正确的值并创建了一个包含很多行的大型源文件。
在某些时候，内联函数名称（其名称类似于 fun@7564-1，其中 7564 是行号）再次从零开始计数。
经过一些研究，我注意到：
- 如果您的源代码到达第 65536 行，任何错误、消息、堆栈跟踪都从零开始计数
__LINE__ 仍然是 return 正确的值- 内联函数的修饰名再次从零开始
- 编译时错误下划线完全不相关
- 通过调试逐步完成完全不相关的行
- 在实际行上设置断点将其设置在 "blind" 行上
- 调试期间变量的工具提示仍然显示正确的值，"blind" 处没有工具提示出现。
为了说明，一堆换行符和正在调试的方法超过了第 65535 行，我设法获得了盲源步进体验：
这个216边界是故意的还是无意的？它是 F# 或 CLR 或 PDB 格式人为强加的限制吗？
注意 (1)：我只在 Windows 7 和 2012 上使用 F# 4.0、.NET 4.5 和 VS 2015 测试了这个。
注意 (2)：我怀疑这个边界会经常被击中，除非可能是自动生成的源文件（在 C# 中我有一些超过这个边界的自动生成的文件）。
- 我尝试过使用大文件进行重现，这在我的机器上也很奇怪。
- 在 GitHub 存储库中，Don Syme has replied and asked something about your source code。这可能是当前 Visual F# 工具的限制。
这似乎是 confirmed bug in Visual F#, the bug report has a full repro solution for download。
大型 lambda 或入口点上有一个 related issue on large source files throwing WhosebugException in Debug build, and another related issue also throwing an SOE，但在任何构建中。
我正在测试我是否可以依赖 __LINE__ 始终 return 正确的值并创建了一个包含很多行的大型源文件。
在某些时候，内联函数名称（其名称类似于 fun@7564-1，其中 7564 是行号）再次从零开始计数。
经过一些研究，我注意到：
- 如果您的源代码到达第 65536 行，任何错误、消息、堆栈跟踪都从零开始计数
__LINE__仍然是 return 正确的值- 内联函数的修饰名再次从零开始
- 编译时错误下划线完全不相关
- 通过调试逐步完成完全不相关的行
- 在实际行上设置断点将其设置在 "blind" 行上
- 调试期间变量的工具提示仍然显示正确的值，"blind" 处没有工具提示出现。
为了说明，一堆换行符和正在调试的方法超过了第 65535 行，我设法获得了盲源步进体验：
这个216边界是故意的还是无意的？它是 F# 或 CLR 或 PDB 格式人为强加的限制吗？
注意 (1)：我只在 Windows 7 和 2012 上使用 F# 4.0、.NET 4.5 和 VS 2015 测试了这个。
注意 (2)：我怀疑这个边界会经常被击中，除非可能是自动生成的源文件（在 C# 中我有一些超过这个边界的自动生成的文件）。
- 我尝试过使用大文件进行重现，这在我的机器上也很奇怪。
- 在 GitHub 存储库中，Don Syme has replied and asked something about your source code。这可能是当前 Visual F# 工具的限制。
这似乎是 confirmed bug in Visual F#, the bug report has a full repro solution for download。
大型 lambda 或入口点上有一个 related issue on large source files throwing WhosebugException in Debug build, and another related issue also throwing an SOE，但在任何构建中。