feat: #line-based navigation between source and generated files

[theodevelop]

What problem does this solve?

When working with Bison/Flex grammars, the generated C files (.tab.c, lex.yy.c) are the actual files processed by clangd for go-to-definition, find references, etc. Navigating between the source .y/.l and the generated C requires manually searching for the matching #line directive — there is no direct jump.

Proposed solution

Add two editor context menu commands:
Show in Source (generated → .y/.l): available inside generated files only (detected by their header). Reads the nearest #line N "file.y" above the cursor and jumps to that file at the correct line. No configuration required.
Show in Generated File (.y/.l → generated): available inside .y/.l files. Locates the generated file via CMake detection (already in place), then Makefile, then fallback to $filename.tab.c / lex.yy.c, then workspace-wide search. Navigates to the matching line using #line directives. Shows a clear error if the file hasn't been generated yet.

Notes

• #line paths may be relative or absolute depending on the build system — handle both
• Originated from discussion discussion: is there a good way to combine this extension with a c/c++ one (clangd?) #10

[theodevelop]

I think this or the related issue should be re-opened: Currently the generated file is opened at whatever #line directive is seen above - but it doesn't take into account the line differences.

Example:

#line 28 parser.y

#include "config.h"

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#ifdef	HAVE_STRINGS_H
#include <strings.h>
#endif

// 100 lines more
void some_func (int mode)
{
/// use Bison/Flex: Show in source here --> opens line 28, while it should open line 140
}

Originally posted by @GitMensch in #29 (comment)

[theodevelop]

Fixed in fix/show-in-source (coming in next release)
Two bugs were identified and fixed in the Show in Source command:

---

Bug 1 — Wrong target line (the issue you reported)

The command was reading the nearest #line N "file.y" directive above the cursor and jumping straight to line N in the source — ignoring how many lines below that directive the cursor actually was.

#line 28 parser.y

#include "config.h"
// ... 100 more lines ...
void some_func(int mode) {   ← cursor here (line 140 in the generated file)

The command was opening parser.y at line 28 instead of line 140 (28 + 112 offset).
Fix: The target line is now computed as sourceLine + (cursorLine − directiveLine), where directiveLine is the position of the #line directive in the generated file. The offset accounts for all the lines between the directive and the cursor.

---

Bug 2 — Unquoted filenames not detected
The original regex required double-quoted filenames (#line 28 "parser.y"). Some build systems emit directives without quotes (#line 28 parser.y), causing the directive to go completely undetected — the command would then report "No #line directive found" even when one was present.
Fix: The regex now accepts both forms: #line N "file.y" and #line N file.y.

---

What changed

• client/src/lineDirectiveUtils.ts (new) — pure helper module (isGeneratedFile, findNearestLineDirective) extracted for testability without a VS Code mock
• client/src/lineDirectiveNavigation.ts — imports from the new module, applies the offset formula
• tests/test-line-directive.ts (new) — 26 unit assertions covering quoted/unquoted filenames, cursor-on-directive (offset = 0), cursor-below-directive, multiple directives, and null edge cases