Navigate to editor lines from compiler diagnostics

Who is affected

Candidates debugging C, C++ or Java code after Run tests reports compilation errors. The output already shows editor-relative line numbers, but candidates must manually locate each line in the editor. With several diagnostics, this means repeatedly switching between the output and the code.

Desired outcome

Make candidate-code source locations such as <source>:2:17 in the existing compilation-error output keyboard- and mouse-operable. Activating a location focuses the editor, places the caret at the beginning of the corresponding line, and scrolls that line into view using the existing active-line highlight. Each location in a multi-diagnostic result can be activated independently.

Present workaround

Read the reported line number, then manually scroll through the editor to find it.

Observed behavior

I tested Marquee Letter Tiles (marquee-letter-tiles) on codetrial 0.1.0 (c44768f), macOS 15.6.1 and Google Chrome 155.0.8059.85 (arm64). For example, running this C code displays two errors with valid editor-relative locations, but neither location provides navigation:

bool canSpellFromTiles(char* message, char* tiles) {
    int first = missing_one;
    int second = missing_two;
    return true;
}

<source>:2:17: error: use of undeclared identifier 'missing_one'
    2 |     int first = missing_one;
      |                 ^
<source>:3:18: error: use of undeclared identifier 'missing_two'
    3 |     int second = missing_two;
      |                  ^
2 errors generated.

Equivalent C++ and Java tests also display both errors. Inserting three blank lines before the first failing statement shifts both reported locations by three in each language. This proposal adds navigation to those existing locations; it does not change how many diagnostics the compiler produces.

Scope and implementation direction

• Support C, C++ and Java compilation diagnostics in the current Test results panel. Navigate to the line start, even when a column is available.
• Reuse the editor-line mapping and harness distinction in web/compiler-explorer.js; do not apply the offset again. Harness locations, external-header locations and invalid or out-of-range positions stay plain text.
• web/render.js::resultsMarkup currently renders escaped diagnostic text in a <pre>. Preserve the complete text, order and excerpts, while making only verified candidate-source locations operable. Compiler text must remain escaped.
• web/interview.js::runTests already captures code and language snapshots. Use the snapshot associated with the displayed result to guard navigation, and reuse the editor's selection, highlighting and scroll synchronization. Navigation must not dispatch a code-input event.
• If the current code or language differs from that run's snapshot, refuse navigation and show a brief message such as "Code or language has changed. Run tests again to navigate to this location." This also applies to edits made while the run is pending; it does not introduce a general stale-results feature.
• Keep navigation metadata local to the browser. Preserve the diagnostic text sent to Jim and leave test judging, scoring and interview contracts unchanged.
• Python, JavaScript, runtime stack traces, column navigation and a separate Problems panel are outside this first version.

Acceptance criteria and tests

1. Both source locations in the C example can be activated separately and move the caret to the correct editor line. Automated coverage includes multiple C/C++/Java diagnostics and Java diagnostics without columns.
2. Each location can be reached and activated with the keyboard and has an accessible name identifying the target line. Activation focuses the editor and makes the target visible with synchronized syntax and line-number layers.
3. Harness positions, external-header positions, malformed or out-of-range locations and unsupported messages remain non-navigable. Diagnostic text containing HTML special characters is displayed safely.
4. If code or language differs from the associated run snapshot, activation shows the rerun message without moving the caret. Tests cover edits during a pending run and subsequent runs replacing older results.
5. Navigation leaves code and undo/redo content history unchanged and does not publish a code edit. The full diagnostic output remains available after rendering or rerendering.

Add focused parser/rendering tests and browser interaction tests for these behaviors, retain the existing remapping regression coverage, and manually check a second problem with a different harness.

Related work

#217 and PR #272 correct compiler line numbers and distinguish harness diagnostics. This proposal builds on that behavior by adding editor navigation. I searched open and closed issues and PRs for clickable diagnostics, error navigation, go to line and related navigation terms on 2026-10-25 and did not find a directly matching proposal in the returned results.