[Bug]: Building a .NET Core Function SDK 8.0.201 on a MAC with M1 chip

[HeHubo]

[Bug]: Building a .NET Core Function SDK 8.0.201 on a MAC with M1 chip

[jaredpar]

That seems like something we should fix. There are limits that are hard to fix with nested exprs but chained statements like this should be oka.y

[jaredpar]

Wondering if there is an estimated timeline on this?

A fix for this is likely to show up in the VS 17.11 / .NET SDK 8.0.300 timeframe.

https://github.com/tModLoader/tModLoader/actions/runs/8023721868

How do you get the source for that file?

We've also observed that Visual Studio based Build / Debugging does not trigger this issue compared to dotnet build

That is a little surprising. The original bug filed here was due to compiling on Mac. The stack size on a Mac is significantly smaller than Windows / Linux hence hitting stack limitations in the compiler is more common there. The same stack size applies to msbuild and dotnet build on Windows. Having one crash and one not suggests the code was already right on the edge of the Windows limit but a subtle change in the new compiler pushed it over the limit.

[jaredpar]

Unfortunately on .NET 8 and earlier the default stack size on Mac machines is much smaller than Windows / Linux. That means the compiler, which is naturally recursive in places, can run into limitations on Mac that it doesn't hit on other OS. That appears to be what is happening here.

If possible would you be able to share the file in question here? I want to see if there is a particular pattern that we could recommend the function team change to make it harder to hit this issue.

Note: in .NET 9 the situation should improve as the runtime team took steps to normalize stack space across OS

[HeHubo]

The problem is that I can't tell exactly which file or files are causing this error. Only a reduction of the files in the function project brings success. Perhaps the problem could also come from the fact that our function has between 300 and 400 APIs. I am not aware of any complex code that could cause this stack overflow.

[jaredpar]

@HeHubo based on the screen shot it's from a generated file called GeneratedFunctionExecutor.g.cs. I'm not 100% sure what is producing that but the file will either be in one of two places:

1. Inside the obj directory, maybe in obj\Debug.
2. If a source generator file then passing -p:EmitCompilerGeneratedFiles=true on the command line will put the file in the obj directory

If this is code you can share out I'm happy to take a quick look at it and just find the file for you. If you need to share privately can file a VS Feedback issue, post the link here and we can get it going from that point.

[HeHubo]

After I setting the EmitCompilerGeneratedFiles property in the project file, the build creates the file with the error.

Here is the file:
GeneratedFunctionExecutor.g.cs.zip

[jaredpar]

@cston looking at the generated code here, i'm not seeing the usual candidates for why the compiler hits stack limits. There is a very long chain of else if in an async method but I'd be surprised if that caused deep stack recursion.

[cston]

It looks like the parser will fail if there are too many else if cases.

For instance, the following results in error CS8078: An expression is too long or complex to compile beyond a certain number of cases, even with earlier builds of the compiler.

class Program
{
    static void F(int i)
    {
        if (i == 0) { }
        else if (i == 0) { }
        else if (i == 0) { }
        else if (i == 0) { }
        /* ... */
    }
}

[cston]

An else if statement is represented as an if statement nested in the enclosing else. To remove the limit on the number of else if cases, we'll need to update the parser and also update binding and lowering to handle arbitrarily deeply nested IfStatementSyntax.

[Solxanich]

Also experiencing this chained else if on tModLoader project.
Wondering if there is an estimated timeline on this?

We had to forcefully downgrade to SDK 8.0.102 for our project to build in CI, so we do have a workaround, but it sounds like this could show up again if cross a magic number of chain length.
tModLoader/tModLoader@0eb2a4c

Erroring build:
https://github.com/tModLoader/tModLoader/actions/runs/8023721868

Referenced line is ~75% way through an else if chain spanning 8000+ lines / 600+ else-if.

We've also observed that Visual Studio based Build / Debugging does not trigger this issue compared to dotnet build. Not sure what exactly is different, but may be useful?

[Mirsario]

A fix for this is likely to show up in the VS 17.11 / .NET SDK 8.0.300 timeframe.

Great to hear!

How do you get the source for that file?

The actual source file causing us the error comes from a game modding project, which, while open source in patch form, we aren't allowed to publicly distribute the source files for. I can provide the source-code privately via email if you would like.
Or, if by chance you happen to own a Steam Windows copy of Terraria - the basic instructions for using our development setup tool (decompiler + patcher) are here.

Since we operate on patches, it's not very ideal for us to introduce new ones to split up functions into smaller parts, but we may do that in this case, as it seems like it's only one function that is failing to compile. That comes to my surprise however, as a lot of the game's logic happens to be unbelievably large else-if chains, and so yes, our project has most likely always been close to the compiler's limits. 🙃

[jaredpar]

I can provide the source-code privately via email if you would like.

You can send to [email protected] or open a VS feedback ticket, upload there and post a link in this issue. Either works for me.

[cston]

To support arbitrary length chains of else if statements, we'll need to update various visitors in the compiler that walk syntax or bound nodes to avoid recursion for nested if statements. The set of visitors includes:

• LanguageParser
• Binder
• LocalBinderFactory
• LocalRewriter
• Optimizer
• AbstractFlowAnalysis
• CSharpOperationFactory