[Repo Assist] Fix uint32 underflow in semantic token length for multiline ranges

[github-actions]

🤖 This PR was created by Repo Assist, an automated AI assistant.

Closes #1407

Root Cause

When FCS returns a SemanticClassificationItem whose range spans multiple lines (e.g. a multiline string literal or verbatim string), the token length computation in encodeSemanticHighlightRanges (LspHelpers.fs) was:

let tokenLen = uint32 (range.End.Character - range.Start.Character)

For a multiline range, End.Character (position on the last line) may be less than Start.Character (position on the first line). Since both are uint32, the subtraction underflows — e.g. 4 - 10 = 4294967290 when interpreted as uint32 (which is -6 in int32). Some LSP clients (notably Neovim) treat this as a token of ~4 GB length and freeze or crash.

The issue was first identified in #1407, with a good root-cause analysis in the comments by @onion108 and @TheAngryByrd.

Fix

Two-layer defence:

1. scrubRanges (Commands.fs): Filter out any SemanticClassificationItem whose FCS range spans more than one line, since the LSP semantic token protocol requires each entry to be contained within a single line. This is the primary fix.

2. encodeSemanticHighlightRanges (LspHelpers.fs): Add a guard that clamps tokenLen to 0u for any remaining multiline or inverted ranges that somehow escape scrubRanges. This is belt-and-suspenders.

Trade-offs

• Multiline tokens (e.g. multiline strings, multiline comments) will no longer receive semantic highlighting. This is visible as a minor cosmetic regression — they'd fall back to syntax-based highlighting — but it's far better than the current behaviour of freezing the editor.
• A follow-up improvement would be to split multiline tokens into per-line entries (as the LSP spec allows), but that requires access to the source text to compute per-line lengths and is a larger change.

Test Status

✅ Build passed: dotnet build FsAutoComplete.sln -c Release — 0 warnings, 0 errors.

The existing test suite doesn't appear to have a test specifically for multiline semantic token ranges. A dedicated unit test for encodeSemanticHighlightRanges with a multiline range would be a good follow-up.

Generated by Repo Assist

To install this workflow, run gh aw add githubnext/agentics/workflows/repo-assist.md@0d6e8cf9db90470cd5477c6a40b350fd9f9e1422. View source at https://github.com/githubnext/agentics/tree/0d6e8cf9db90470cd5477c6a40b350fd9f9e1422/workflows/repo-assist.md.

[github-actions]

✅ Pull request created: #1449

[Krzysztof-Cieslak]

/pr-fix

[github-actions]

✅ Commit pushed: 6cf2544

[github-actions]

Fix: Fantomas Formatting

The CI was failing on the "Check format" step (dotnet fantomas --check build.fsx src) across all build matrix entries.

Root Cause

In src/FsAutoComplete/LspHelpers.fs, the new multi-line tokenLen if-else binding was missing a blank line before the next let tokenTy = ... binding. This is inconsistent with the existing pattern in the same function where lineDelta and charDelta (also multi-line if-else bindings) are both followed by blank lines before the next let binding. Fantomas enforces blank lines between multi-line let bindings.

Fix Applied

Added the missing blank line after the tokenLen if-else expression in LspHelpers.fs:

    let tokenLen =
      if range.End.Line > range.Start.Line || range.End.Character < range.Start.Character then
        0u
      else
        uint32 (range.End.Character - range.Start.Character)
                                                            ← blank line added here
    let tokenTy = uint32 ty

The Commands.fs changes (comment between pipeline operators and the filter step) did not require formatting changes.

Generated by PR Fix for issue #1449

To install this workflow, run gh aw add githubnext/agentics/workflows/pr-fix.md@ee50a3b7d1d3eb4a8c409ac9409fd61c9a66b0f5. View source at https://github.com/githubnext/agentics/tree/ee50a3b7d1d3eb4a8c409ac9409fd61c9a66b0f5/workflows/pr-fix.md.

Warning

⚠️ Firewall blocked 2 domains

The following domains were blocked by the firewall during workflow execution:

• api.nuget.org
• dc.services.visualstudio.com

[Krzysztof-Cieslak]

/repo-assist add test cases for the PR

[github-actions]

✅ Commit pushed: 60ae8bb

[github-actions]

🤖 This is an automated response from Repo Assist.

I've added test cases to the PR branch. Here's what was added:

New unit tests — LspHelpersTests.fs

Six focused unit tests for encodeSemanticHighlightRanges that directly target the uint32 underflow regression:

Test	What it verifies
empty input returns None	baseline behaviour
single normal single-line range	correct 5-element encoding (lineDelta, charDelta, tokenLen, …)
multiline range (End.Line > Start.Line)	tokenLen is clamped to 0u, not the old ~4294967290u underflow value
inverted single-line range (End.Char < Start.Char)	same clamping guard
multiline range + valid range	subsequent token delta encoding is not corrupted
sequence of single-line tokens	correct relative deltas throughout

All 6 unit tests pass locally.

Integration test — HighlightingTests.fs

Added a regression test that requests semantic tokens for Script.fsx (which now includes a multiline triple-quoted string) and asserts that every decoded token length is below a sanity threshold (1000u). If the fix were reverted, the multiline string token would produce a length of ~4294967290u, which would trip this assertion.

Supporting change — Program.fs

Wired up LspHelpersTests.allTests and UtilsTests.allTests (the latter was compiled but not previously included in any test run) into generalTests.

Generated by Repo Assist for issue #1449

To install this workflow, run gh aw add githubnext/agentics/workflows/repo-assist.md@828ac109efb43990f59475cbfce90ede5546586c. View source at https://github.com/githubnext/agentics/tree/828ac109efb43990f59475cbfce90ede5546586c/workflows/repo-assist.md.