Reduce the amount of stack space needed for parsing embedded statements

[CyrusNajmabadi]

This is an alternative approach to #41589 (which is more contentious in the scope of hte change).

This only gets us about 50% of hte improvement of that change (65 frames instead of around 130). But it should also be much easier to get in immediately.

[CyrusNajmabadi]

Tagging @RikkiGibson @jcouv @cston Thanks!

[cston]

This only gets us about 50% of ...

As @RikkiGibson suggested in #41589, if [MethodImpl(MethodImplOptions.AggressiveInlining)] is added to ParseEmbeddedStatement, it should be possible to get the full benefit with this change.

[cston]

LGTM, thanks.

[CyrusNajmabadi]

As @RikkiGibson suggested in #41589, if [MethodImpl(MethodImplOptions.AggressiveInlining)] is added to ParseEmbeddedStatement, it should be possible to get the full benefit with this change.

Ok. Let me try that!

[RikkiGibson]

does this now get us basically the same benefit as #41589?

[ghost]

Auto-approval

[cston]

LGTM, thanks!

[ghost]

Auto-approval

[RikkiGibson]

Seems like a spurious failure in debug_32

Microsoft.CodeAnalysis.Editor.UnitTests.Diagnostics.GenerateMethod.GenerateMethodCrossLanguageTests.GenerateMethodUsingTypeConstraint_InstantiatedGenerics

System.AggregateException : One or more errors occurred.\r\n---- System.InvalidOperationException : WaitAndGetResult cannot be called from a thread pool thread.

[CyrusNajmabadi]

Seems like a spurious failure in debug_32

Looks like it. What's the right thing to do here? Open an issue and ignore the failure as a dupe of that?

[RikkiGibson]

Opened an issue to track the flaky test

[CyrusNajmabadi]

Thanks!