Missing argument compiles without error and throws CLR error during runtime

[kdurkin77]

If we leave out an argument by mistake the compiler doesn't error and we can even run the code, but on runtime it crashes

This code compiles successfully when it shouldn't:
let x = doesnt.exist(, nor.this.either, also.nope)

This code does not compile successfully as it shouldn't:
let x = doesnt.exist(nope, nor.this.either, also.nope)

Repro steps

1. Open fs file in Visual Studio Code
   MissingArgumentShouldNotCompile.zip
2. See no errors
3. Try to run and see a CLR error and crash

Expected behavior
The code should not compile

Actual behavior
The code compiles

Known workarounds
None

Related information
Seen in both Visual Studio Code 1.82.0 and Visual Studio 2022 17.7.3 (both up to date)

[kerams]

Almost certainly a regression in recovery. The binding is ignored completely, so I guess FSI is trying to evaluate something that does not produce any code?

No parsing error is raised despite the presence of SynExpr.ArbitraryAfterError.

[vzarytovskii]

Huh, @auduchinok, does this ring a bell?

[kdurkin77]

Also, this has happened in a full VS fsproj as well as the fsi like in the example

[vzarytovskii]

Introduced in #15227
@auduchinok FYI

Bisect script used:

dotnet build FSharp.Compiler.Service.sln -c Release
.\artifacts\bin\fsi\Release\net7.0\fsi.exe ..\reg15955.fsx

@echo off
if %ERRORLEVEL% EQU -1073741819 (
   echo Failure Reason Given is %errorlevel%
   exit /b 1
) else (
   echo Success
   exit /b 0
)

reg15955.fsx:

let x = doesnt.exist(, nor.this.either, also.nope)

git bisect start
git bisect bad e1131e2
git bisect good 124ca6bd0257ac8c594abe0390befd0d039d7f13
git bisect run ./bisect.cmd

[smoothdeveloper]

@vzarytovskii @auduchinok, should there be a list of AST nodes that are known to not be allowed to "pass" to the code generation part?

I see ArbitraryAfterError is present in many of the test cases baselines, maybe an invariant check before transforming to the typed AST, that would be checked and kept in the context during type checking and later stages.

This contextual flag would then be used to prevent code generation.

Would that be a good approach to prevent similar mishaps?

Also, the infrastructure that runs those parser recovery tests could generate the IL baseline files, expecting them to be empty, and make the test to fail if not.