Slice source text instead of copying it line by line for outlining

[xperiandri]

Description

The editor's block structure built the sourceLines array for Structure.getOutliningRanges by calling ToString() on every line, allocating a fresh string for the whole file on each outlining pass, that is once per keystroke.

The scanner now takes ReadOnlyMemory<char>[] and sits behind two entry points:

• getOutliningRanges keeps its public string[] signature and maps to memory, so FSharp.Compiler.Service consumers are unaffected;
• getOutliningRangesFromLineSlices is internal and takes the slices the caller already holds. The editor slices the materialized source text once through a new SourceText.GetLinesAsMemory() helper and calls this one.

Inside the scanner, comment detection trims and classifies lines over spans instead of building trimmed strings, and comment groups track line numbers only, since only the first and last lines of a group are ever read back to compute the fold's columns.

ReadOnlySpanCharExtensions in illib mirrors the existing ordinal String helpers so span call sites read the same way.

No public API change: the surface-area baseline is untouched.

Fixes # (no issue)

Checklist

• Test cases added: the existing StructureTests (39 cases) exercise every fold kind through the shared scanner, reached via the public entry point.
• Performance benchmarks added in case of performance changes: posted as a comment below. One outlining pass over a 13.6k-line file drops from 5.3 ms / 4.4 MB to 0.9 ms / 1.0 MB.
• Release notes entry updated: docs/release-notes/.FSharp.Compiler.Service/11.0.100.md (Improved) and docs/release-notes/.VisualStudio/18.vNext.md.

🤖 Generated with Claude Code

[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
`vsintegration/src`	docs/release-notes/.VisualStudio/18.vNext.md

[xperiandri]

Benchmark

BenchmarkDotNet, both versions of the changed code copied verbatim into a standalone harness (the compiler-internal helpers they use are internal, so the harness redefines the two one-line StartsWithOrdinal shims). before is ServiceStructure.fs at a29233c, after is this branch. The ScopeRange/range construction is stubbed identically on both sides so it does not skew the comparison, and [<GlobalSetup>] asserts both scanners find byte-identical comment blocks before any measurement runs.

Inputs are two real files from this repo: ServiceStructure.fs (1,107 lines) and CheckExpressions.fs (13,653 lines).

BenchmarkDotNet v0.15.4, Windows 11 (10.0.26200.9278)
AMD Ryzen 9 5980HS, 1 CPU, 16 logical and 8 physical cores
.NET SDK 10.0.400, .NET 10.0.11, X64 RyuJIT x86-64-v3

Step	File	Before	After	Time	Alloc before	Alloc after
Build line array	ServiceStructure.fs	15.6 us	3.5 us	4.4x	122 KB	17 KB
Comment scan	ServiceStructure.fs	77.9 us	43.3 us	1.8x	180 KB	54 KB
Build + scan	ServiceStructure.fs	124.3 us	53.8 us	2.3x	302 KB	71 KB
Build line array	CheckExpressions.fs	1,923 us	102 us	18.8x	1,753 KB	213 KB
Comment scan	CheckExpressions.fs	1,364 us	444 us	3.1x	2,645 KB	780 KB
Build + scan	CheckExpressions.fs	5,328 us	930 us	5.7x	4,399 KB	993 KB

"Build + scan" is what one outlining pass pays outside the AST walk, and the editor pays it per keystroke. On the large file that is 4.4 MB of garbage per pass before, 1.0 MB after, a 77% reduction; on the small file 76%.

Where the allocations went:

• Line array. ToString() per line copied every line of the file. Slicing the already-materialized text allocates only the array of ReadOnlyMemory<char> structs. What is left in the "after" column is that array.
• Comment scan. TrimStart() per line allocated a trimmed copy of every line just to test two prefixes; the span version trims in place. Comment groups also stored (int * string) tuples per line, now int only.

Variance is high on the multi-modal rows (the harness reports bimodal distributions on the scan benchmarks, and the full-pass rows carry a wide StdDev), so treat the time ratios as order-of-magnitude rather than precise. The allocation numbers are exact and are the substance of the change.

Two caveats worth stating plainly:

• Measured on .NET 10. FSharp.Compiler.Service ships netstandard2.0, and the editor caller runs on .NET Framework 4.7.2, where ReadOnlyMemory/ReadOnlySpan come from the System.Memory package. No ArrayPool is involved on this path, so the relative picture should hold, but I have not measured the desktop runtime.
• BenchmarkDotNet's header prints [Host] ... DEBUG. That is the known false positive for F# Release builds; DebuggableAttribute.IsJITOptimizerDisabled on the harness assembly is false.

[T-Gro]

🤖🕵️ Keep the public string[] getOutliningRanges entry point. Add a separately named internal memory-based entry for the editor and share the scanner implementation.

[xperiandri]

Done in ac31157505.

getOutliningRanges keeps its string[] parameter and maps to memory; getOutliningRangesFromLineSlices is internal and takes the slices, and BlockStructureService calls that one. Both go through the same scanner — the wrapper is one line.

Two things fall out of this, both good: the surface-area baseline and the StructureTests call sites go back to exactly what they were on main, and the release note moves from Breaking Changes to Improved. PR description updated accordingly.

Build clean, StructureTests 42/42 through the public entry point.

[github-actions]

🔍 Tooling Safety Check — Affects-Design-Time
Affects-Design-Time: Changes outlining services used by Visual Studio.

Generated by PR Tooling Safety Check · gpt56 3.1M · ◷