Use trackErrors ce instead of ++ custom operator

[edgarfgp]

While contributing I always find confusing using custom operators.

In this PR my goal is to replace the usage of

val (++): res: OperationResult<'T> -> f: ('T -> OperationResult<'b>) -> OperationResult<'b>`

with

trackErrors {
    ....
}

[edgarfgp]

I am not entirely sure how to convert the last one.

TryD (fun () -> SolveTypeSubsumesType csenv 0 m NoTrace None reqdObjTy availObjTy ++ (fun () -> ResultD true))
                 (fun _err -> ResultD false)

https://github.com/dotnet/fsharp/blob/0514e881c2e03b2c004504b8b21432aa4a01c7bc/src/Compiler/Checking/ConstraintSolver.fs#L3769C94-L3769C100

Update: This is now done

[vzarytovskii]

That's good, we can probably remove the (++) if it's not used anywhere. I find its usage confusing and not useful. Thanks for rewriting it.

[edgarfgp]

That's good, we can probably remove the (++) if it's not used anywhere. I find its usage confusing and not useful. Thanks for rewriting it.

(++) is now only used in DiagnosticsLogger TrackErrorsBuilder and in some of its helper functions. So I guess We can rewrite it and remove the usage of the custom operator In a separate PR ?

Update: See

fsharp/src/Compiler/Facilities/DiagnosticsLogger.fs

Line 694 in 16fa9a5

type TrackErrorsBuilder() =

[psfinaki]

Thanks for this.

As for removing (++) completely - as usual, I'd prefer a separate PR but not opposed to having it here either :)

[kerams]

I'm looking back at this, there are a bunch of do! CompleteD. Isn't that essentially a no-op?

[edgarfgp]

I'm looking back at this, there are a bunch of do! CompleteD. Isn't that essentially a no-op?

Do you mean that these can go outside of the trackErrors ce ?

[kerams]

Does it do anything? It seems to me it could be replaced with () and some branches could be eliminated altogether.

[edgarfgp]

Does it do anything? It seems to me it could be replaced with () and some branches could be eliminated altogether.

Yeah that's a good point. On this PR I wanted to just replace the ++ operator, But I think it can be optimized in follow-up PR