Seal FSharpFunc / FSharpTypeFunc implementers to benefit from devirt 🎉

[NinoFloris]

As Andy Ayers has started the herculean task https://github.com/dotnet/coreclr/issues/9908 to get to full CLR devirt he has already merged the first pieces.

Specifically interesting is dotnet/coreclr#9230 which is about devirtualizing calls when the runtimetype at the callsite can be determined exactly (newobj) or if the runtimetype is a sealed subtype / the called method is sealed.

The compiler currently outputs FSharpFunc / FSharpTypeFunc (among others) classes without sealing them while I know of no reason it could not seal those.

This would bring F# function invocation performance up quite a notch (as a non virtual call they'll subsequently become inlining targets as well) and has widespread positive performance impact I presume.

[dsyme]

We should do this (and should always have done it)

See https://github.com/Microsoft/visualfsharp/compare/master...dsyme:clo?expand=1 for what I think is the implementation. Can someone take this and update any necessary tests?

[vasily-kirichenko]

@dsyme #3031

[vasily-kirichenko]

It's implemented in #3031, @cartermp close this issue please.

[cartermp]

👍 Thanks @vasily-kirichenko

[NinoFloris]

Thanks all

[TIHan]

Did we actually test the performance impact of this?

[dsyme]

Did we actually test the performance impact of this?

No (on CLRs as available at the time we would have expected no change)