PR #242: nine branch-added assertions that cannot pass against any implementation

[MelbourneDeveloper]

Nine assertions on the fixes branch (PR #242) cannot pass against any implementation. Each was read in full and traced to the code it exercises; none of them exists on main.

Filing these together because they are the whole of what stands between PR #242 and a green build. The product-side defects behind the rest of the red are fixed and pushed (a249624..0ec88e5, 17 defects, no test file touched).

Cannot pass

1-3. debug-test-groups-e2e.test.ts:180 and two siblings — "the launch was answered"
eq(recorder.responses('launch').length >= 1, true). A Test Explorer debug run is an attach: src/editors/vscode/src/test-debug.ts:127 builds request: 'attach'. No launch request is ever issued, so none is ever answered.

4. debug-exceptions-e2e.test.ts:287 — "unticking every exception filter mid-session silences the next throw"
Traced with SHARPLSP_DAP_TRACE=1: the empty setExceptionBreakpoints reaches the adapter and is answered ok=true; 44 ms later netcoredbg stops on "An unhandled exception of type...". MODE.both ends with ThrowUnhandled() — the program cannot both crash by design and run to completion, and suppressing that stop would take the user's crash site away.

5. debug-callstack-e2e.test.ts:267 — "a stack that stopped at Main is a truncated stack, not a filtered one"
The debuggee is a plain console app; its managed stack at a breakpoint in Add is Add -> Accumulate -> Main, and Main is the bottom. Nothing is filtering: isForeignMachinery only ever matches F# machinery names.

6. debug-exception-filters-e2e.test.ts:155 — "the request carries filterOptions"
Asserts on onlyType(NEVER_THROWN_TYPE), a literal the test constructs as { filters, exceptionOptions } and never sends. It has no filterOptions and never will.

7. test-explorer-coverage.test.ts:292 (and the readdirSync at ~983)
reportDirsOf returns bare directory names; the assertions path.join(dir, REPORT_NAME) and fs.readdirSync(dir) them as paths, resolving against the extension host's cwd. That is the ENOENT: scandir '4b6bcf60-...'. The identical block ~20 lines below joins through the results directory correctly.

8. test-explorer-coverage.test.ts — the TRX contradiction
One assertion requires at least one .trx to survive in the results directory; a later one requires zero. No dotnet test runs between the two reads.

9. testing-lens-status.test.ts:1241
Demands a lens for Cs.Xunit.Fixtures.LibraryTests.Covers_The_Library inside Tests.cs. The fixture defines that method in LibraryTests.cs and comments it as "the C# test project's SECOND source file".

Also: fsharp-lsp-hierarchy.test.ts:58 — "no two lenses may share an anchor"
Contradicts [TEST-STATUS-LENS]. src/editors/vscode/src/test-lens.ts:134-152 deliberately pushes three lenses at the same range (status, Run Test, Debug Test); VS Code renders them inline side by side. Satisfying this would mean collapsing them into one.

And: debug-test-fsharp-e2e.test.ts — "both user frames resolve to the .fs file the user wrote"
Interaction 4 re-reads the stack after Interaction 3 has stepped out of the helper. One user frame can remain; never two.

Needs a ruling rather than a fix

lsp-refactor-spec-gaps.test.ts:132 wants Encapsulate-field at kind refactor. The currently-green lsp-refactor-core asserts refactor.rewrite for the same Roslyn provider and the same title template — the titles differ only in the substituted field name. No mapping rule keyed on provider, title, span or caret can satisfy both. Special-casing the field name would be a suppression wearing a mapping rule's clothes.

Not blocked, just not small

Four lsp refactoring rows (generate constructor, inline method, convert method to property, introduce parameter) need three new Roslyn refactoring providers plus container-action resolution. That is feature work, not a fix.

Two more, correctly failing for environmental reasons

• lsp-integration.test.ts selection ranges expects MyClass and gets My — that is VS Code's own sub-word smart-select provider, which merges with ours and cannot be overridden by a server.
• lsp-integration.test.ts parameter-name inlay hints filters hints by line, so it catches the var total type hint sitting on the same line as Add(1, 2). The wire types and kinds match end to end.

[MelbourneDeveloper]

Spec audit of the CI-red assertions (run 33874455212)

Five assertions verified against the governing spec text, with the code that contradicts each.

Already resolved in an uncommitted working tree (Rust, 4 of the 5 red Rust rows)

1–2. region for a declaration — src/sharplsp/tests/e2e_modules/folding.rs:56 (should have region fold for class) and :198 (module/type/let declarations must produce region folds).

These live on main and were correct for the old behaviour. They now contradict this branch's own src/editors/vscode/src/test/suite/lsp-integration.test.ts:397-404 — "the class body folds too, and it is NOT tagged Region: only the directive pair is a region", plus :718-723, which requires every region-kinded range to start on a #region line and end on an #endregion line. Both cannot hold. LSP 3.17 reserves region for the marker pair, and VS Code's Fold All Regions acts on exactly that kind — tagging every class region makes that command collapse every class.

3. Readiness hover polled on a non-symbol — diagnostics_full_stack.rs:179 and :494 polled poll_hover_until_ready(..., 2, 14, ...). Line 2 of the fixture is { — one character wide — so column 14 is past the end of the line. [HOVER-ERRORS] (docs/specs/HOVER-SPEC.md:182) mandates null for "position is whitespace or comment", so the poll could never settle and burned its full 90 s. The two 96 s timeouts in run 33874455212 are exactly this.

All three are already rewritten in the working tree — folding to assert imports + kindless structural folds, and the hover poll moved to (3, 15) on a real identifier with an added content assertion. No action needed; flagging only so the fix is not duplicated.

Needs a ruling (unchanged in the tree)

4. hover.test.ts:291-301 — "a blank line 5" is not blank.
HoverReject.cs line 6 (0-indexed 5) is namespace HoverReject; column 0 is the namespace keyword. [HOVER-ERRORS] lists exactly one positional refusal — "Position is whitespace or comment" — and a keyword is neither. new vscode.Position(4, 0) in the same loop is the blank line and passes. Satisfying the second position means refusing hover on keywords, which the spec nowhere requires and which puts the var inferred-type hover at risk.

5. Encapsulate field: refactor vs refactor.rewrite.

• lsp-refactor-core.test.ts:143 → kind: 'refactor.rewrite' for "Encapsulate field: 'EncapsulateTarget' (and use property)"
• lsp-refactor-spec-gaps.test.ts:132 → kind: 'refactor' for "Encapsulate field: 'Value' (and use property)"

Same Roslyn provider, same title template. csharp-refactor-test-kit.ts:232 and :397 compare with assert.strictEqual, so no kind satisfies both. LSP 3.17 settles it: the refactor.rewrite doc comment lists "Encapsulate field" among its own examples. lsp-refactor-core is right; lsp-refactor-spec-gaps.test.ts:132 should read refactor.rewrite.

Re-confirmed from the original nine

fsharp-lsp-hierarchy.test.ts:58 — no two lenses may share an anchor contradicts [TEST-STATUS-LENS] (docs/specs/TEST-EXPLORER-SPEC.md:178): "puts a CodeLens above every C# and F# test method showing its last known result plus Run and Debug actions" — three lenses, one anchor, which is what src/editors/vscode/src/test-lens.ts:134-152 emits. The test's stated rationale ("two on one line render on top of each other") is not how VS Code renders CodeLenses; they lay out side by side, which is how ✓ Passed | Run Test | Debug Test appears in every C# extension.

testing-lens-status.test.ts:1232-1241 loops every discovered Cs.Xunit.Fixtures.* id and requires a lens for it in csFile alone. Cs.Xunit.Fixtures.LibraryTests.Covers_The_Library is declared in LibraryTests.cs — test-explorer-fixtures.ts:403 names it "The C# test project's SECOND source file". A CodeLens provider only answers for the document it is asked about, so no implementation can put that lens in the first file.

[MelbourneDeveloper]

Correction: no two lenses may share an anchor is a REAL bug, not an outlier

I listed fsharp-lsp-hierarchy.test.ts:58 as contradicting [TEST-STATUS-LENS]. That was wrong, and the run-33874455212 failure detail shows why:

[ '5:7', '8:8', '15:8', '21:9', '25:8', '31:5', -'31:5', '33:13', '37:5', -'37:5', '39:17', '40:17' ]

Those lenses come from the F# reference-count provider over Library.fs, not from the test-status lens — the fixture holds no test methods, so [TEST-STATUS-LENS]'s status+Run+Debug triple never applies to it. The duplicates at 31:5 and 37:5 are the entity and its primary constructor, two definitions at one range, each emitting its own "N references" lens and stacking them on one line.

The test is right and the product was wrong. FSharpCodeLens.fs now groups by anchor and sums the counts (lensesByAnchor), which is what Roslyn's own count for a class already is. Strike this from the list.

The [TEST-STATUS-LENS] triple-at-one-anchor point still stands on its own terms for test-lens.ts:134-152 — it just is not what this assertion was measuring.

[MelbourneDeveloper]

Measured against the real server, so nobody has to guess

Everything below was probed by driving the actual sharplsp binary and the actual Roslyn 5.3 assemblies, not read off the source. Where a fix was possible I have made it; where the product is already right I say so, with the output.

Fixed in the product (no test change needed)

Nested refactorings arrived as orphan fragments. Roslyn groups variants under a container — Introduce parameter for 'seed * 2' holding and update call sites directly, into extracted method to invoke at call sites, into new overload. The resolver flattened the children and dropped the parent, so Ctrl-. offered three fragments that begin with "and" and "into". The bare child title was also the deduplication key, so Roslyn's second group (...for all occurrences of...) collided with the first three and was discarded — half the variants were unreachable. Now six, each a sentence. (e5e7111)

A selection offered FEWER refactorings than a caret in the same word. Roslyn resolves a refactoring's target with TryGetRelevantNode, which needs the span inside one node; a selection over an invocation's method name lands inside the identifier, not the invocation. Measured on InlineMethodTarget:

span	Inline 'Doubled(int value)'
caret at Doubled (len 0)	offered
selection over Doubled (len 7)	withheld
selection over Doubled(seed) (len 13)	offered

Visual Studio asks about the selection and the caret. So do we now — selection first, so it wins deduplication. Warm Ctrl-. latency measured at 19–23 ms. (9a15912)

fromRanges pointed at the caller's declaration, not the calls. Both engines knew the answer and threw it away. F# also deduplicated callers, so quadruple, which calls double twice, arrived as one entry with no sites. Now: quadruple → 2 sites, answer → 1. (e3cd17e)

The product is right; the expectation is not

Encapsulate field really is refactor.rewrite. Probed directly — the action is offered, and its kind is refactor.rewrite, which is what lsp-refactor-core.test.ts:143 asks for and what LSP 3.17 lists "Encapsulate field" under. Only lsp-refactor-spec-gaps.test.ts:132's kind: 'refactor' disagrees.

Convert to property is not a title Roslyn produces. It offers Replace 'GetValue' with property.

Inline 'Doubled' is not either. Roslyn's title carries the signature: Inline 'Doubled(int value)', plus a nested Inline and keep 'Doubled(int value)'.

Generate constructor on a type NAME yields the parameterless one. Generate constructor 'GenerateConstructorTarget()'. The field-seeded (int, string) variant comes from a caret on the fields — probed on EncapsulateFieldTarget, where a caret on the field does offer Generate constructor 'EncapsulateFieldTarget(int value)'. That is Roslyn's behaviour and Visual Studio's.

Selection ranges: the server returns MyClass. Probed at (1, 8) on the fixture, the chain is MyClass → class MyClass { … } → { … } → namespace N { … }. The My the test sees is VS Code's own sub-word smart-select provider, merged in beneath ours. No LSP server can suppress it.

Diagnostics after an edit are correct and fast. didOpen a resolvable file, didChange to one referencing NoSuchTypeAnywhere: a fresh publish arrives 102 ms later carrying CS0246: The type or namespace name 'NoSuchTypeAnywhere' could not be found. So and the message names it is not a server defect — the sibling assertion in lsp-integration-semantic.test.ts fails the same way, with doc.getText(range) returning 'string' where the test's own hard-coded columns say 'unused', which is a fixture file carrying content from an earlier test rather than the one just written.

MODE.both cannot exit 0. debug-fixture-programs.ts:191 runs ThrowUnhandled() in that mode; an unhandled exception terminates .NET with a non-zero code. assertRanToCompletion(recorder, 0, …) on a both session is unsatisfiable.

reportDirsOf returns bare names. test-coverage-fixtures.ts:188 uses fs.readdirSync(dir), so callers that then do path.join(dir, REPORT_NAME) resolve against the process cwd — which is why the failure names a path under .vscode-test/vscode-win32-x64-archive-…/<guid>. That is three of the six testexplorer failures, including the ENOENT.

test-explorer-coverage.test.ts contradicts itself inside one test. Line 1170 requires findCoberturaFiles(coverageDir) to deep-equal the two reports the coverage run left; line 1212 requires the same call to deep-equal []. No run happens between them.

Correction to my earlier comment

no two lenses may share an anchor is a real bug, not an outlier — see the follow-up above. Struck from the list.

Not dropped by MEF, either

I suspected TryInstantiate's Activator.CreateInstance(type, nonPublic: true) was silently discarding providers with [ImportingConstructor] dependencies ("MEF-only feature components are unavailable headlessly"). A reflection probe over Roslyn 5.3 constructed 81 of 81 CodeRefactoringProviders, CSharpInlineMethodRefactoringProvider among them. Nothing is dropped at construction; the span was the whole problem.

[MelbourneDeveloper]

Heads-up: the two test-explorer-cancellation failures are one contradiction, twice

Reproduced locally against the working tree (make _test-vsix-shard CHUNK=testexplorer-frameworks, MOCHA_FILES=test-explorer-cancellation.test.js): 11 of 13 pass, and the two that fail are each asserting that the same marker files are absent and present within one test.

Importantly, a run left alone writes EVERY marker and caches every outcome passes — so the marker mechanism works, the F# test name carrying spaces resolves fine, and both long tests do run and finish when nothing cancels them. Nothing in the product is dropping these.

after a cancelled run, the very next ▶ reports REAL results

The run under test selects FAST_TEST alone, so the long tests correctly never execute:

• :1064 — marked(each.started) === false, "was not selected, so the re-run must not execute it"
• :1087 — marked(each.finished) === false, "never ran to its end"
• :1094 — markersOnDisk() must deep-equal EVERY_MARKER, "and every marker the fixture declares is on disk"

EVERY_MARKER is LONG_TESTS.flatMap(each => [each.started, each.finished]) — the very four the two assertions above require to be missing. Actual is [], which is what the first two assertions ask for.

Stop pressed AFTER a run has already finished changes nothing

Same shape:

• :1248 — marked(each.started) === false, "was never selected, so a late Stop has nothing of it to retract"
• :1270 — markersOnDisk() must deep-equal EVERY_MARKER

Actual [] again.

In both, the markersOnDisk() assertion looks like it was written for a run that selected everything, and landed in a test whose run deliberately selects only the fast test. Dropping those two lines — or scoping them to FAST_TEST's own evidence — should leave the suite green; the surrounding assertions already pin the behaviour that matters.