Implement direct delegates

[kerams]

Description

Implements fsharp/fslang-suggestions#1083, fixes #11898. RFC.

Test cases should cover everything mentioned in the language suggestion.

Checklist

• Test cases added
• Performance benchmarks added in case of performance changes
• Release notes entry updated:

[github-actions]

❗ Release notes required

You can open this PR in browser to add release notes: open in github.dev

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/11.0.100.md
LanguageFeatures.fsi	docs/release-notes/.Language/preview.md

[kerams]

Ready for another pass, think I addressed everything. (But alternatives and unresolved questions in the RFC need answers still:))

[smoothdeveloper]

Add an opt-out compiler flag (default on) alongside the language feature.

I think this is not needed anymore, Tomas has added a msbuild way as well as compiler flag to disable specific language features:

--disableLanguageFeature:DirectDelegateConstruction

or

 <ItemGroup>
  <DisabledLanguageFeatures Include="DirectDelegateConstruction" />
</ItemGroup>

You may want to check it picks up as is to allow selectively disabling the feature.

[T-Gro]

Since the use cases are known in the RFC and often framework-integrated, it would be great to have some smoke tests for this integration.

(ASP.NET routing/minimal APIs, dependency-injection containers, mocking libraries, serializers, and logging/diagnostics that print the bound method name. With F# they see Invoke on a closure rather than the intended method, which breaks or degrades these scenarios..)

Either going via "Regression tests" suite and referencing a separate repo and building it with the fresh compiler.
Or picking a few cases and doing an .fsx test with #load of a few chosen libraries?

[abonie]

@kerams Are you planning to address this one? Or otherwise is it ready to merge from your standpoint?

[T-Gro]

Direct delegate to a static method on a value type boxes the ref-type first arg as the declaring struct → garbage / AccessViolationException

open System
[<Struct>]
type V =
    static member Pick (s: string, n: int) = s.Length + n

let make () = Func<int,int>(fun n -> V.Pick("abc", n))
// preview:  make().Invoke 10  ->  93584954   (expected 13)

let bad () = Func<int>(fun () -> Int32.Parse "41")
// preview:  bad().Invoke()    ->  System.AccessViolationException

Feature off / main: both correct. The emitted IL boxes the string as the struct:

ldstr   "abc"
box     P/V          // string reinterpreted as a boxed V
ldftn   int32 P/V::Pick(string, int32)
newobj  Func`2<int32,int32>::.ctor(object, native int)

Root cause: the closed-delegate emission boxes whenever targetMspec.DeclaringType.Boxity.IsAsValue (IlxGen.fs ~7703–7707). That is correct for a value-type instance receiver, but here the leading arg is the static method's first parameter — already a reference (guaranteed by staticLeadingArgIsRefType), so it must not be boxed.

Fix: only box when the receiver is a genuine value-type instance receiver (takesInstanceArg), not for the static closed-first-arg form. This path is currently untested — a struct-static positive test would have caught it.

[T-Gro]

🤖🕵️

Fixed in 8e5f373 — verified: make().Invoke 10 = 13 and bad().Invoke() = 41 (no AccessViolationException), and the erroneous box V is gone from the emitted IL. The added struct-static positive test covers it. Thanks!

[github-actions]

🔍 Tooling Safety Check — Affects-Compiler-Output
Affects-Compiler-Output: implements direct delegates codegen

Generated by PR Tooling Safety Check · opus46 12.1M · ◷