IL: cache C# extension methods per CCU

[auduchinok]

GetCSharpStyleIndexedExtensionMembersForTyconRef had no cache, so every open of a static class
rebuilt a MethInfo chain for each of its extension methods and re-imported their type parameters. On a
57-file project with 489 references that meant 98,986 MethInfos describing only 6,782 distinct
extension methods on 1,190 static classes.

Project	Before (MB)	After (MB)	Diff %
consoleapp	33.83	33.66	−0.18 (−0.52%)
Fantomas.Core	109.43	108.46	−0.96 (−0.88%)
Fantomas.Core.Tests	141.86	141.35	−0.51 (−0.36%)
Fantomas.Benchmarks	64.84	64.89	+0.05 (+0.07%)
FSharp.Common	297.67	265.87	−31.80 (−10.68%)
FCS	1271.08	1230.85	−40.23 (−3.16%)

[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

[T-Gro]

Review: caching C# extension methods per CCU ✅

Really nice, well-scoped optimization. I built it locally (Build.cmd -c Debug, 0 warnings/0 errors) and ran Language.ExtensionMethodTests — 28/28 passing. The design is sound and the code comments do a great job explaining the why. Approving.

Why this is correct

• Local vs imported split is the right call. Only imported classes are cached (if tcrefOfStaticClass.IsLocalRef then compute-uncached). A local static class is still gaining members while its own file is checked, so it must not be memoized — the comment nails this.
• Cache lifetime is tied to CcuData. It lives and dies with the referenced assembly's CCU, so it's naturally invalidated when the project/TcImports is rebuilt. No stale-entry risk across incremental builds.
• Shared MethInfos are safe.MethInfo for imported IL methods is effectively immutable, and framework CCUs (e.g. System.Linq.Enumerable, a huge source of these) are shared with a consistent TcGlobals via FrameworkImportsCache, so reusing them across name-resolution envs and parallel file checking is fine. ConcurrentDictionary + TryGetValue/TryAdd makes concurrent computation idempotent (double-compute at worst, never corruption).
• Priority is deliberately not cached.NextExtensionMethodPriority() is still called per open and applied outside the cached shape, preserving the original ordering semantics. The None/Some (Some/None) mapping is faithfully reproduced via (TyconRef option * MethInfo).
• Conservative on import failure. Marking importFailed and skipping the TryAdd (while still returning the partial shape) means a transient import failure won't be baked in permanently — same worst-case cost as before, no regression.
• isApplicable is checked before touching the CCU/cache, so non-extension classes pay nothing extra.
• All four CcuData construction sites are updated, and the .fsi field order matches the .fs — build confirms.

Minor / optional (non-blocking)

• ConcurrentDictionary(1, 0) uses concurrencyLevel = 1, which serializes the (rare) writes on a single lock. Reads are still lock-free, and writes happen at most once per static class, so this is fine — just flagging that the default ctor would behave near-identically if you'd rather not hardcode.
• Empty-but-applicable classes now skip NextExtensionMethodPriority() (the counter no longer advances for them). That's benign — priority is only observable when members exist — worth a mental note only.
• Typing the field as obj + :?> on read is a pragmatic way around the MethInfo-declared-later ordering, and the .fsi comment explains it well. No change needed.

The FCS (−3.16%) and FSharp.Common (−10.68%) allocation wins are excellent for essentially zero downside.