test(fsharp): expect Foo.add qualified name after npm grammar bump (#1162)

The WASM tree-sitter-fsharp signature grammar was upgraded from v0.1.0
to v0.3.0 in adcaf40. v0.3.0 emits `module_defn` for nested
`module Foo = ...` blocks (v0.1.0 emitted ERROR nodes), so the existing
qualification logic now fires for the WASM engine too — `val` symbols
get the parent module prefix in both engines.

The signature test still expected the pre-bump behaviour (bare `add`),
which made it fail in CI where the grammar bump landed. Update the
assertion to lock in engine parity:
  - assert the qualified `Foo.add` function and the outer `Foo` module
  - assert the unqualified `add` is NOT emitted, so any future
    regression where the walker drops the enclosing module is caught

Also refresh the `module_defn` comment in src/extractors/fsharp.ts —
it still claimed the WASM grammar emitted ERROR nodes for this
construct, which became stale after the v0.3.0 bump.

Author: carlos-alm

src/extractors/fsharp.ts

@@ -51,11 +51,10 @@ function walkFSharpNode(
       break;
     case 'module_defn':
       // Nested signature module (`module Foo = ...`) in `.fsi` files,
-      // produced by the cargo 0.3.0 grammar. The WASM 0.1.0 signature
-      // grammar currently emits ERROR nodes for this construct, so it
-      // never reaches this branch there (tracked in #1161). When it
-      // does fire, accumulate the dotted module path so nested `val`
-      // declarations are qualified as `Outer.Inner.foo`.
+      // emitted by both the WASM (npm ionide tarball v0.3.0) and cargo
+      // v0.3.0 tree-sitter-fsharp signature grammars. Accumulate the
+      // dotted module path so nested `val` declarations are qualified
+      // as `Outer.Inner.foo` in parity with the native engine.
       nextModule = handleModuleDefn(node, ctx, currentModule);
       break;
     case 'function_declaration_left':

tests/parsers/fsharp-signature.test.ts

@@ -42,16 +42,21 @@ describe('F# signature (.fsi) parser', () => {
   });
 
   it('extracts val declarations nested inside a module signature', () => {
-    // The WASM tree-sitter-fsharp signature grammar (currently v0.3.0) does
-    // NOT yet produce a `module_defn` for `module Foo = ...` — it emits
-    // ERROR nodes and the `val` declarations float to the top level (so
-    // they're indexed as `add`, not `Foo.add`). The cargo 0.3.0 grammar
-    // parses it correctly and the Rust extractor qualifies as `Foo.add`.
-    // The WASM grammar fix is tracked under #1161; once the signature
-    // grammar emits `module_defn` for nested modules, this assertion
-    // should be updated to expect `Foo.add` to match the native engine.
+    // Both the WASM (npm ionide tarball v0.3.0) and the cargo v0.3.0
+    // tree-sitter-fsharp signature grammars emit `module_defn` for
+    // `module Foo = ...`, so `val` declarations nested inside are
+    // qualified with the module path (`Foo.add`) in both engines. The
+    // outer `module Foo` is also indexed as a `module` definition.
     const { symbols } = parseFSi(`module Foo =\n  val add : int -> int\n`);
     expect(symbols.definitions).toContainEqual(
+      expect.objectContaining({ name: 'Foo', kind: 'module' }),
+    );
+    expect(symbols.definitions).toContainEqual(
+      expect.objectContaining({ name: 'Foo.add', kind: 'function' }),
+    );
+    // The unqualified name must NOT appear — that would mean the walker
+    // failed to thread the enclosing module through to `handleValueDefinition`.
+    expect(symbols.definitions).not.toContainEqual(
       expect.objectContaining({ name: 'add', kind: 'function' }),
     );
   });