TypeMismatchDiagnosticExtendedData: fix expected type calculation

[DedSec256]

TypeMismatchDiagnosticExtendedData provides additional data for FSharpDiagnostic that the IDE needs to suggest appropriate quick fixes, such as replacing the expected type with the actual one.
It can be created from an ErrorFromAddingTypeEquation exception, which contains the expected and actual types:

fsharp/src/Compiler/Checking/ConstraintSolver.fsi

Lines 154 to 160 in 616530c

	exception ErrorFromAddingTypeEquation of
	tcGlobals: TcGlobals *
	displayEnv: DisplayEnv *
	expectedTy: TType *
	actualTy: TType *
	error: exn *
	range: range

Unfortunately, what is referred to here as the “expected” type is not always the real “expected” type.

For example, in the following case:

"" + 1

The SolveTypeEqualsTypeWithReport function will create an ErrorFromAddingTypeEquation exception where, after type resolution, the expected type will equal the actual type — both being int:

fsharp/src/Compiler/Checking/ConstraintSolver.fs

Lines 3182 to 3187 in 616530c

	and SolveTypeEqualsTypeWithReport (csenv: ConstraintSolverEnv) ndeep m trace cxsln expectedTy actualTy =
	TryD
	(fun () -> SolveTypeEqualsTypeKeepAbbrevsWithCxsln csenv ndeep m trace cxsln expectedTy actualTy)
	(function
	| AbortForFailedMemberConstraintResolution as err -> ErrorD err
	| res -> ErrorD (ErrorFromAddingTypeEquation(csenv.g, csenv.DisplayEnv, expectedTy, actualTy, res, m)))

This, although unexpected from the point of view of naming, is a valid workflow for solving the type equation for the generic + operator.

As a result, TypeMismatchDiagnosticExtendedData will also contain int instead of string as the expected type.

The good news is that, to clarify the error in type resolution, ErrorFromAddingTypeEquation contains a nested exception, ConstraintSolverTypesNotInEqualityRelation, which also contains two TType values that can be treated as the expected and actual types:

fsharp/src/Compiler/Checking/ConstraintSolver.fs

Line 219 in 616530c

exception ConstraintSolverTypesNotInEqualityRelation of displayEnv: DisplayEnv * TType * TType * range * range * ContextInfo

Unfortunately, this structure also does not guarantee which TType corresponds to the actual type and which to the expected one. This depends on the order in which they are passed in one of many different calls to the type-checking logic.

Despite this, FCS still needs to correctly identify the expected and actual types to produce an accurate type mismatch error. This logic is implemented here:

fsharp/src/Compiler/Driver/CompilerDiagnostics.fs

Lines 660 to 664 in 616530c

	type Exception with
	member exn.Output(os: StringBuilder, suggestNames) =
	match exn with

This PR implements this logic when creating TypeMismatchDiagnosticExtendedData to correctly identify the expected and actual types.

[github-actions]

❗ Release notes required

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/10.0.100.md

[edgarfgp]

Should this PR fix #18849 ?

[auduchinok]

@edgarfgp No, why? 🙂

[edgarfgp]

Just out of curiosity. If not I might give it a try once I finish my open PR's :)

[auduchinok]

@DedSec256 This is very good work, thanks!