Nimblesite / Nimblesite/SharpLsp
Restore C# and F# sidecar coverage to the 95% stored threshold
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 132
- Forks
- 5
- Avg merge
- 6h 24m
- Merged PRs (30d)
- 27
Description
What
Both sidecar packages now pass the coverage gate on the ratchet's 1pp tolerance rather than by meeting the stored threshold:
| Package | Stored | Effective | Actual |
|---|---|---|---|
sharplsp-sidecar-csharp |
95% | 94% | 94.69% |
sharplsp-sidecar-fsharp |
95% | 94% | ~94.45% |
The stored thresholds were not lowered — check-coverage.mjs hard-fails if a committed threshold ever decreases, and it only ratchets upward. But actual coverage did fall below 95%, so the gate is green while the historical bar is not met.
Why it dropped
The restructure branch added roughly 2,700 lines of new C# sidecar code and ~560 lines of new F# rename/code-action code whose only tests ran through the VS Code extension host. Those tests exercise the code but generate no sidecar coverage, so from the gate's perspective the new code was untested. PR #200 closed most of the gap by driving the same paths directly through the sidecar suites, but not all of it.
What's left
C# needs roughly 16 more covered lines to reach 95%. Largest remaining gaps, all reachable in principle:
AnalyzerDiagnosticResolver.cs— error/edge branchesHeadlessOverrideSyntax.cs—ToInitAccessoris defensive: Roslyn's generator already emitsinitdirectly, so the set-to-init conversion never fires in practiceHeadlessOverrideCodeAction.cs,CodeActionResolver.cs,WorkspaceManager.cs
Note that raising the stored threshold requires actual > 96%, since the ratchet sets the new threshold to actual - 1pp and only applies it when that exceeds the current value.
Not a regression in the gate
Worth recording for whoever picks this up: the same branch also changed .NET coverage measurement from max-of-reports to union-of-reports (tools/coverage/merge-cobertura.cs). Union is the correct measurement — max-of-reports systematically undercounts, ignoring lines covered only by a test assembly whose report wasn't the maximum — but it is also more generous, so the pre-existing shortfall would read worse under the old algorithm, not better.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the sidecar coverage suites and inspect the remaining gaps in AnalyzerDiagnosticResolver.cs, HeadlessOverrideSyntax.cs, HeadlessOverrideCodeAction.cs, CodeActionResolver.cs, and WorkspaceManager.cs. Review check-coverage.mjs and tools/coverage/merge-cobertura.cs to understand the stored and effective thresholds. Done means both C# and F# actual coverage reaches at least 95% without lowering the committed thresholds.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp, fsharp
- Domain
- testing
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100