Publish NavigableContainer's cases

[xperiandri]

NavigateTo.GetNavigableItems returns items a consumer can read but not rebuild: the signature seals
NavigableContainer and hides its File and Container cases. That is enough to display a result, and not
enough to carry one out of the process that produced it. Visual Studio's Navigate To is to keep each file's
navigable items on disk between sessions, as Roslyn keeps its syntax index, and reading them back means
constructing containers.

The change

• NavigableContainer publishes File of fileName: string and Container of info: NavigableContainerInfo. Its
  members Type, FullName and Name are unchanged.

• Container carried a three-element tuple, containerType * nameParts * parent. Published as it was, the tuple
  would be fixed into the API, so it becomes a record with named fields first:
  NavigableContainerInfo { ContainerType; NameParts; Parent }.

• The record is a [<Struct>]. A struct record lies inside the case exactly as the tuple's fields did — one
  allocation per container — where a reference record adds an object per container and an indirection on every
  access. Building a file and three nested containers a million times (x64, .NET 11, fsi --optimize+):

  Container payload	bytes per chain
  tuple (before)	144
  [<Struct>] record	144
  reference record	216

  A struct union is not an option: Parent is recursive.

The change is additive: the surface-area baseline only gains lines. NavigableContainer keeps its structural
equality and comparison, which the struct record derives as well.

SurfaceAreaTest passes against the updated FSharp.Compiler.Service.SurfaceArea.netstandard20.bsl. The
consumer, a persistent cache for Navigate To in FSharp.Editor, is a separate PR that builds on this one.

🤖 Generated with Claude Code

[github-actions]

✅ Release notes checked

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
`src/Compiler`	docs/release-notes/.FSharp.Compiler.Service/11.0.200.md

[T-Gro]

🤖 🕵️ AI review — verify independently.

[T-Gro]

🤖 🕵️ [P2] Ordered-container comparisons now box each NavigableContainerInfo — 120 bytes per comparison at depth three, versus 0 with the previous representation.

open System
open System.Collections.Generic
open FSharp.Compiler.EditorServices

let chain file =
    [1..3] |> List.fold (fun parent _ ->
        NavigableContainer.Container {
            ContainerType = NavigableContainerType.Module
            NameParts = ["M"]
            Parent = parent
        }) (NavigableContainer.File file)

let a, b = chain "a.fs", chain "b.fs"
let comparer = Comparer<NavigableContainer>.Default
for _ in 1..10000 do comparer.Compare(a, b) |> ignore

let allocated =
    let before = GC.GetAllocatedBytesForCurrentThread()
    for _ in 1..100000 do comparer.Compare(a, b) |> ignore
    GC.GetAllocatedBytesForCurrentThread() - before
printfn "%d bytes" allocated // 12000000 bytes

[xperiandri]

The allocation is real and the cause is not the struct record itself: F#'s structural comparison for the union reaches its field through generic comparison, which boxes a struct payload. Implementing IComparable<NavigableContainerInfo> would not remove it either, since generic comparison boxes to IComparable before it ever sees a typed implementation.

What it costs in practice is nothing, because nothing orders these. NavigateTo.GetNavigableItems returns an array in traversal order; the editor reads a container only for FullName and Name, and the ordering Navigate To does is over the strings ComputeSecondarySort builds, never over items or containers. The 12 MB in the repro comes from calling Comparer<NavigableContainer>.Default directly, which no caller does — the comparison exists only because the type is structurally comparable by default.

That leaves two honest ways to make it zero again, and they trade against what this PR is for:

1. [<NoComparison>] on the container. Ordering containers is meaningless anyway, and this is the change that removes the cost outright — but CompareTo is in the surface-area baseline today, so it is a breaking change for anyone who took the default.
2. Fields back on the case - Container of containerType: NavigableContainerType * nameParts: string list * parent: NavigableContainer. One allocation, no boxing, fields still named in a match. What goes is info.NameParts outside a match, and NavigableContainerInfo as a type to pass around.

I would rather not leave a documented allocation in a published API on the strength of "no one calls it", so I will take one of the two. Leaning to 2, since it keeps the comparison the baseline already promises.

[github-actions]

🔍 Tooling Safety Check — Affects-Design-Time
Affects-Design-Time: Changes FCS or Visual Studio editor behavior.

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

[Copilot]

Copilot review overview

🟡 Changes recommended

Remove the duplicate adjacent release-note entry.

Review effort: Lite
Findings: 1

Open (1)

• Remove duplicate release-note entry · New

What changed in this PR

Publishes NavigableContainer cases and introduces a named struct payload for reconstructing persisted Navigate To results.

Changes:

• Exposes File and Container cases.
• Adds NavigableContainerInfo.
• Updates implementation, API baseline, and release notes.

File	Description
tests/​FSharp.Compiler.Service.Tests/​FSharp.Compiler.Service.SurfaceArea.netstandard20.bsl	Updates the API baseline.
src/​Compiler/​Service/​ServiceNavigation.fsi	Publishes the new API declarations.
src/​Compiler/​Service/​ServiceNavigation.fs	Updates container representation and construction.
docs/​release-notes/​.FSharp.Compiler.Service/​11.0.100.md	Documents the API change.

[xperiandri]

Fixed in 5aaa231309: the unlinked copy is gone. Linking the note added a second line instead of editing the first.

The surviving entry also moved out of 11.0.100, which shipped while this PR was in review, into 11.0.200 — the version main now collects notes in.