fsc.exe exited with code -1073741571 (StackOverflowException with big literal list) VS2019 Preview 3

[marklam]

Creating a large list in a source literal breaks the compiler

Repro steps

Compile the following code:

module TestData

let expectedValues = 
    [
        1 
        1 
        1 
        1 
        1 

continue this for another 400 lines

        1 
    ]

TestData.zip

Expected behavior

A large (and boring) list is created

Actual behavior

The compiler terminates

Known workarounds

Create the list programmatically

Related information

Provide any related information

Microsoft Visual Studio Community 2019 Preview
Version 16.0.0 Preview 3.0
VisualStudio.16.Preview/16.0.0-pre.3.0+28608.199
Microsoft .NET Framework
Version 4.7.03190
Installed Version: Community
...
Visual F# Tools 10.4 for F# 4.6   16.0.0.0.  Commit Hash: b5c01b8cc65af6381d2dd558ee63a4aa9e0e98d5.
Microsoft Visual F# Tools 10.4 for F# 4.6

[TIHan]

Can confirm. This is a pretty bad one.

[nilekirk]

This also happens in preview 3 for huge if .. elif .. else, more than 196 it seems.

Repro

let isThisReallyOne n =
    if n = 1 then true
    elif n = 1 then true
    elif n = 1 then true
    ... more than 196 of these, including if and else
    else false

This is a regression, since it works in VS2017.

[cartermp]

@dsyme any ideas?

[dsyme]

I don't know of anything specific that would have caused this

[cartermp]

cc @KevinRansom @brettfo looks like we have some investigative work to do here

[dsyme]

The problem is similar to #6222 - fsc.exe is now a 64-bit process, and hence consuming more stack.

Adding

    <PlatformTarget Condition=" '$(TargetDotnetProfile)'!='coreclr'">x86</PlatformTarget>
    <PlatformTarget Condition=" '$(TargetDotnetProfile)'=='coreclr'">AnyCPU</PlatformTarget>

fixes the problem and restores compat. Would be interesting to know the coreclr compiler's behaviour here.

The general problem is that the input sizes accepted in various dimensions are determined partly by available process stack - they are not precisely specified nor do we test to precise numbers and fail above those numbers). Instead historically we've been able to remove these limits when we've encountered them by moving more stack to the heap for certain operations (e.g. collecting free variables down long chains of let) through standard continuation coding techniques in the compiler.

I suppose we should

1. move back to a 32-bit fsc.exe for compat
2. make the compiler handle arbitrary-sized input (subject to heap not stack) for the above.
3. work on at least having exact current size limits under test so we know when we blow them.

[cartermp]

Gotcha, so in terms of the immediate problem #6223 resolves it, but we likely need to do work to make it solved better?

[dsyme]

@cartermp Applying the same fix as #6223 (but to fsc.exe) resolves it. #6223 only dealt with fsi.exe