Graph-based type-checking: compilation failure causes type-checking to crash.

[safesparrow]

This code is wrong:

fsharp/src/Compiler/Driver/GraphChecking/GraphProcessing.fs

Lines 95 to 101 in 948f8b2

	let setExn newExn =
	lock exn (fun () ->
	match exn with
	| Some _ -> ()
	| None -> exn <- newExn
	localCts.Cancel())

We lock on the exn object before we ever set it.

This was spotted in a CI run with experimental features on, producing this error:

    Microsoft (R) F# Compiler version 12.7.0.0 for F# 7.0
    Copyright (c) Microsoft Corporation. All Rights Reserved.
    --------------------------------------------------------------------------------------------------------
    |Phase name                          |Elapsed |Duration| WS(MB)|  GC0  |  GC1  |  GC2  |Handles|Threads|
    |------------------------------------|--------|--------|-------|-------|-------|-------|-------|-------|
    |Import mscorlib+FSharp.Core         |  0.2039|  0.1939|     93|      0|      0|      0|    274|     12|
    |Parse inputs                        |  0.8067|  0.5954|    246|      1|      0|      0|    305|     17|
    |Import non-system references        |  0.8087|  0.0007|    246|      0|      0|      0|    305|     17|
    Unhandled exception. System.ArgumentNullException: Value cannot be null.
       at System.Threading.Monitor.ReliableEnter(Object obj, Boolean& lockTaken)
       at FSharp.Compiler.GraphChecking.GraphProcessing.setExn@95[Item](CancellationTokenSource localCts, FSharpRef`1 exn, FSharpOption`1 newExn) in D:\a\_work\1\s\src\Compiler\Driver\GraphChecking\GraphProcessing.fs:line 96
       at FSharp.Compiler.GraphChecking.GraphProcessing.queueNode@115-3.Invoke(FSharpChoice`2 res) in D:\a\_work\1\s\src\Compiler\Driver\GraphChecking\GraphProcessing.fs:line 117
       at Microsoft.FSharp.Control.AsyncPrimitives.CallThenInvokeNoHijackCheck[a,b](AsyncActivation`1 ctxt, b result1, FSharpFunc`2 userCode) in D:\a\_work\1\s\src\FSharp.Core\async.fs:line 528
       at Microsoft.FSharp.Control.Trampoline.Execute(FSharpFunc`2 firstAction) in D:\a\_work\1\s\src\FSharp.Core\async.fs:line 112
    --- End of stack trace from previous location ---
       at Microsoft.FSharp.Control.AsyncPrimitives.Start@1174-1.Invoke(ExceptionDispatchInfo edi) in D:\a\_work\1\s\src\FSharp.Core\async.fs:line 1174
       at Microsoft.FSharp.Control.Trampoline.Execute(FSharpFunc`2 firstAction) in D:\a\_work\1\s\src\FSharp.Core\async.fs:line 112
       at <StartupCode$FSharp-Core>.$Async.clo@193-15.Invoke(Object o) in D:\a\_work\1\s\src\FSharp.Core\async.fs:line 195
       at System.Threading.QueueUserWorkItemCallback.Execute()
       at System.Threading.ThreadPoolWorkQueue.Dispatch()
       at System.Threading.PortableThreadPool.WorkerThread.WorkerThreadStart()
    Errors
        D:\a\_work\1\s\.dotnet\sdk\8.0.100-preview.5.23303.2\FSharp\Microsoft.FSharp.Targets(331,9): error MSB6006: "dotnet.exe" exited with code 57005. [D:\a\_work\1\s\src\FSharp.Core\FSharp.Core.fsproj]

It's a bit surprising this wasn't caught earlier - it seems that the graph-based type-checking does not handle type-checking failures well.