`NullReferenceException` breaks IDE syntax coloring on unlinked placeholder entities (e.g. broken code mid-edit)

[xperiandri]

Succinct description:
NullReferenceException (NRE) in TypedTree during semantic classification crashes entire document coloring in F# IDE/LSP/VS Code/VS.

Root cause: Mid-edit broken/unresolved symbols → null entity_modul_type / Entity (unlinked placeholders). Derefs like entity_modul_type.Force() / entity.DisplayName → NRE → full pipeline crash.

Fix ready in staged changes: Defensive null-guards + comments in TypedTree.Construct.NewModified*, FreeVars etc. Partial classification survives.
See detailed doc, #20269.

Repro steps

1. VS/VS Code: New F# file (*.fs).

type Foo =  // Delete 'type' → unresolved
  member x.Bar = ()

2. Save → trigger typecheck/classification (edit/save).
3. Observe: Entire file loses semantic colors (keywords gray, no blue types/keywords).

Pre-fix: NRE in VS Output (F#) / VS Code DevTools Console (LSP).

Expected behavior

Partial/resilient classification:

• Valid code: Full semantic colors (blue types, green keywords).
• Broken symbol: Isolated error (gray/underline), rest intact.

Actual behavior

NRE propagates:

TypedTree.fs / TypedTreeOps.Remapping.fs → entity_modul_type.Force() → NRE  
↑  
LanguageService.fs → DocumentCache.fs → classification crash  
↓  
LSP: semanticTokens/full → empty → no colors for whole file

UX: Plain syntax-only text mid-edit.

Known workarounds

• Fix broken symbol immediately.
• Restart IDE / Reload VS Code window (Ctrl+Shift+P > "Developer: Reload Window").
• Disable semantic highlighting (VS Code: fsharp.semanticHighlighting.enabled: false).

Related information

• OS: Windows (tested; likely cross-platform).
• .NET Runtime: net9.0 (F# compiler).
• Editing Tools:
  • Visual Studio 17.12+ (F# workload).
  • VS Code + F# extension (LSP).

Staged fix files (git diff --staged):

M src/Compiler/TypedTree/TypedTree.fs          // Null-guards + comments
M src/Compiler/TypedTree/TypedTree.fsi         // Sigs
M src/Compiler/TypedTree/TypedTreeOps.Remapping.fs
M src/Compiler/Utilities/lib.fs
M vsintegration/src/FSharp.Editor/*            // LS/cache resilience

Validation: ./build.sh -c Release --testcoreclr clean. IDE resilient.
Commit: Fix NRE in TypedTree: resilient IDE classification (#20269)

[xperiandri]

The root cause is a missing null guard around placeholder/unlinked type-info objects produced while the file is in a broken mid-edit state. In the typed-tree remapping path, entity_modul_type can be null for a placeholder entity, and the code was doing a blind dereference (.Value / Force()) while remapping type constructors. The same pattern can surface elsewhere when a partially-constructed or unlinked TyconAugmentation/Entity is present: a single bad symbol is treated as fatal, so a classification pass aborts the whole file instead of degrading gracefully.

The fix is to treat those placeholder entities as absent rather than crashing: remap code now checks for null TyconAugmentation and entity_modul_type, and the classification pipeline keeps going with the remaining valid symbols. In other words, the issue is not that semantic coloring cannot handle broken code; it is that a placeholder entity was incorrectly assumed to be fully linked, and that assumption was allowed to escape as a NullReferenceException.

The right behavior is resilient classification: broken/unresolved symbols should be isolated, not crash the entire file. This matches the intended semantics of the editor pipeline: partial classification should survive mid-edit code and continue coloring the rest of the document.

[xperiandri]

Please provide a succinct description of the issue.

Succinct description:

NullReferenceException in TypedTree during semantic classification crashes the entire document coloring pipeline when an unlinked placeholder entity is encountered while the file is mid-edit or otherwise broken. A single bad symbol must not wipe out classification for the whole file.

The issue occurs when a placeholder entity (for example, an unresolved or partially constructed type) is still present in the typed tree, but the remapping/classification code assumes it is fully linked. In that situation, dereferencing entity_modul_type / TyconAugmentation or similar fields can throw NullReferenceException, which then aborts classification for the entire document.

Repro steps

1. Open a new or existing F# file and intentionally break a type declaration while editing, for example:

type Foo =  // remove the `type` keyword or otherwise leave the file incomplete
  member x.Bar = ()

2. Save the file or trigger background typechecking / semantic classification.
3. Observe that the IDE loses semantic coloring for the whole file, not just the broken symbol.

Expected behavior

The compiler and IDE should degrade gracefully: the broken or unresolved symbol should be isolated, while valid code elsewhere in the file should retain semantic highlighting and classification.

In other words, a single placeholder entity from incomplete or broken code must not crash classification for the entire document.

Actual behavior

A NullReferenceException is thrown in the typed-tree remapping/classification path. The crash aborts the semantic-coloring pipeline, so the whole file loses its colors and the editor ends up in a syntax-only state until the error is fixed or the IDE is reloaded.

Known workarounds

• Fix the broken code immediately.
• Restart the IDE or reload the editor window.
• Disable semantic highlighting in the editor if needed.

Related information

• Operating system: Windows
• .NET Runtime kind: .NET 10 / compiler runtime used by the repo build
• Editing Tools: Visual Studio 2026 (18.10.0-insiders)