MethodAccessException for type-private member call from inner-rec in a `type C with member ...` augmentation under --realsig+

[T-Gro]

Closures generated for an inner let rec inside a method defined in a
type C with member ... augmentation are emitted as a sibling of C inside
the module class, not as a nested type of C. Under --realsig+, a source
private member of C becomes IL private (type-scoped), so the sibling
closure cannot reach it and the CLR raises MethodAccessException at first
invocation. Under --realsig- the same private compiles to IL assembly,
which is reachable from the sibling, so the bug is invisible.

Repro

module M
type Holder<'T>() =
 static let mutable backing = 0
 static member Init v = backing <- v
 static member private SecretMethod() = backing + 1

type Holder<'T> with
 member _.Run() =
 let rec h n = if n = 0 then Holder<'T>.SecretMethod() else h (n - 1)
 h 5

[<EntryPoint>]
let main _ =
 Holder<int>.Init 41
 if Holder<int>().Run() = 42 then 0 else 1

fsc --realsig+ --optimize+ -r:FSharp.Core.dll repro.fs
dotnet repro.dll

Unhandled exception. System.MethodAccessException:
 Attempt by method 'M+h@8<T>.Invoke(Int32)' to access method
 'M+Holder`1<T>.SecretMethod()' failed.

IL shape (--realsig+, shortened)

.class public sealed M // module class
 .class nested public Holder`1<T>
 .method private static int32 SecretMethod() // IL private (type-scoped)
 .method public instance int32 Run()

 .class nested assembly h@8<T> // SIBLING of Holder, not nested in it
 .method public virtual instance int32 Invoke(int32 n)
 call int32 class M/Holder`1<!T>::SecretMethod() // crosses IL private boundary

Moving Run() from the augmentation into the primary type body emits
h@8<T> as class nested ... Holder1/h@8(nested insideHolder`) and the
program runs cleanly.

Reproduces on (all --realsig+; --realsig- clean)

net8.0 (sdk 8.0.422), net9.0 (sdk 9.0.301, 9.0.315),
net10.0 (sdk 10.0.101, 10.0.109, 10.0.204, 10.0.300).

Notes

Not specific to TLR. Independent of --optimize. The closure-class
placement uses the module's cloc rather than the augmented type's cloc
in IlxGen.fs. Tangentially related to #19882 — that PR's TLR private-ref
guard prevents the inner-rec from being lifted to a module static under
--realsig+, so the fallback path (this closure) is what trips here.

[T-Gro]

Two reach extensions and a corrected error-code analysis, all verified on shipped sdk\10.0.204\FSharp\fsc.dll under --realsig+ --optimize+ (net10.0 / runtime 10.0.9).

1. No inner let rec is required

A task { } / async { } body in an augmentation that references a type-private member directly still throws. The CE state machine itself is the mis-placed module sibling.

module M
open System.Threading.Tasks
type C() =
 static let mutable backing = 0
 static member Set v = backing <- v
 static member private Secret() = backing + 1
type C with
 member _.Run() : Task<int> = task { return C.Secret() }
[<EntryPoint>]
let main _ =
 C.Set 41
 (C().Run()).Result |> printfn "r=%d"
 0

System.MethodAccessException: Attempt by method
 'M+Run@8.MoveNext()' to access method 'M+C.Secret()' failed.

async behaves the same (frame Run@N.Invoke(Unit)). Real-world surface is every task / async written as an extension/augmentation member touching a private member, not only recursive helpers.

2. Reproduction is gated by F# optimizer inlining

With a trivial body the optimizer inlines the private member at the call site and the closure no longer references it, so the program runs clean. Mark the private member [<NoCompilerInlining>] (or give it a non-trivial body like the OG's backing + 1) and the crash returns:

type C() =
 [<NoCompilerInlining>]
 static member private Secret() = 1
type C with
 member _.Run() =
 let rec h n acc = if n = 0 then acc else h (n-1) (acc + C.Secret())
 h 5 0
[<EntryPoint>]
let main _ = (C().Run() = 5) |> function true -> 0 | _ -> 2

System.MethodAccessException: Attempt by method 'NCI+h@7.Invoke(Int32, Int32)'
 to access method 'NCI+C.Secret()' failed.

IL of the trivial-no-attribute case shows the call site has been eliminated entirely — Secret is emitted but never called from h@7. So minimum-repro hunts that strip the body to a constant will hide the bug, and optimized production code with the right shape is silently latent — the bug surfaces only when the private member is non-inlinable enough (naturally or via [<NoCompilerInlining>]) to survive --optimize+.

3. Where the bug actually lives

src/Compiler/CodeGen/IlxGen.fs:7218:

let ilCloTypeRef = NestedTypeRefForCompLoc eenv.cloc cloName

NestedTypeRefForCompLoc nests the closure under whatever eenv.cloc happens to be when codegen enters the method body. For regular type members, GenTypeDef pushes the type's name onto eenv.cloc via AddEnclosingToEnv before generating the member, so closures correctly nest under the type. For intrinsic augmentations (type C with member ... in the same module as C), the binding is processed through the module-binding path, so eenv.cloc stays at the module — and the closures land as siblings of C.

Regular member, same body — closure correctly nested:

.class public sealed Reg
 .class nested public C
 .class nested assembly h@4 extends OptimizedClosures/FSharpFunc`3<...> // safe
 .method instance int32 Run() …

Intrinsic augmentation — closure as module sibling:

.class public sealed N
 .class nested public C
 .method private static int32 Secret() … // IL private under realsig+
 .method instance int32 Run() … // augmentation method, correctly placed in C
 .class nested assembly h@7 extends OptimizedClosures/FSharpFunc`3<...> // sibling of C — bug

Note the method Run itself is correctly emitted inside C. Only the closure it creates lands wrong. Cross-module / cross-namespace extension members are unaffected — F# already rejects them at source with csMemberIsNotAccessible2 ("not accessible … may only be accessed from within the declaring type"), so they never reach codegen.

4. Proposed fix

In IlxGen.fs, when entering codegen for a member binding whose ApparentEnclosingEntity is a class/struct but eenv.cloc does not already reflect that type (the intrinsic-augmentation case), push the apparent enclosing type's compile location onto eenv.cloc before generating the method body. Concretely, in GenMethodForBinding (around eenvUnderMethLambdaTypars, IlxGen.fs:9545):

let eenvForMeth =
 match v.MemberInfo with
 | Some _ when not v.IsExtensionMember ->
 match v.ApparentEnclosingEntity with
 | Parent tcref when not tcref.IsModuleOrNamespace
 && cloc-does-not-already-end-in tcref.CompiledName ->
 AddEnclosingToEnv eenv eenv.cloc.Enclosing tcref.CompiledName None
 | _ -> eenv
 | _ -> eenv

After this push, NestedTypeRefForCompLoc eenv.cloc cloName at IlxGen.fs:7218 produces N/C/h@7 instead of N/h@7, matching the regular-member layout. The method itself is unaffected because its placement uses mspec, not eenv.cloc. State-machine classes (task / async), splice closures from quotations, and let rec lifts all go through the same NestedTypeRefForCompLoc eenv.cloc path, so a single fix covers every host shape above.

5. Belt-and-braces source-level mitigation

If the codegen fix is deferred, a complementary source-level diagnostic could refuse the unsafe shape at compile time. The existing csMemberIsNotAccessible2 message text already says "Private members may only be accessed from within the declaring type" — exactly what's violated when a sibling-nested closure under --realsig+ calls an IL-private member. Firing a specific new diagnostic (its own error number, not the catch-all 193 / not the overload-failure 491) when an intrinsic-augmentation body captures a private member of the declaring type into any lambda / CE / quotation under --realsig+ would turn the silent runtime crash into a compile error with no codegen risk.

Note on previously referenced error numbers

Earlier revision of this comment cited FS0193 and FS0491 as existing F# guards. That was wrong: FS0193 is the catch-all default at src/Compiler/Driver/CompilerDiagnostics.fs:353, and FS0491 is csMemberIsNotAccessible2, raised from overload resolution at ConstraintSolver.fs:3359. Neither is a check for "private member captured into a lambda". An instance member private this.Secret called from let f () = this.Secret() inside another member of the same class compiles cleanly today.