Implement Go to Type Definition and Go to Implementation - #102
Conversation
Resolve component types through the existing library resolver, honor client location-link support, and verify navigation against the real server and VS Code. Co-authored-by: JKRT <jtinnerholm@gmail.com>
Advertise and handle the implementation request with client-specific location formats. Test model, function and partial-class targets, unresolved symbols, unsupported documents, and the VS Code command. Co-authored-by: JKRT <jtinnerholm@gmail.com>
SVAGEN26
changed the title
|
Following our discussion, added Added real-server tests for both response formats, model/function/partial-class targets, unresolved symbols and unsupported documents, plus a VS Code command test. All 269 server tests and 17 editor tests pass; coverage thresholds, build, compilation and lint also pass. |
ModelicaDocument.update is async and throws when parsing fails. Without await, that rejection escaped the surrounding try/catch as an unhandled rejection, which can terminate the server. Awaiting it lets the catch return null as intended. Co-Authored-By: Claude <noreply@anthropic.com>
| // Loading may yield to edits. Read the latest buffer after the await so | ||
| // navigation does not race the asynchronous didOpen/didChange update. | ||
| const opened = currentDocument(); | ||
| if (opened && document.getText() !== opened.getText()) await document.update(opened.getText()); |
There was a problem hiding this comment.
ModelicaDocument.update is async and throws when parser.parse returns null. This call was not awaited, so a parse failure became an unhandled rejection that the surrounding try/catch never saw. On Node that ends the server process by default (see the note in server.ts about an earlier crash from an unhandled rejection).
Trigger: the open buffer differs from the analyzer's copy and re-parsing it fails. A Type Definition request then kills the server instead of returning null.
Fixed in 5d2c99b by awaiting the call.
2 participants
This is JKRT_AGENTIC_ACCOUNT.
Go to Definition already opens concrete model and function bodies, but the separate Type Definition and Implementation requests were unhandled. This PR adds both advertised LSP handlers and completes the requests listed in #10.
Go to Type Definition navigates from
filterinFirstOrder filter;to the declaredFirstOrderclass. Named aliases remain navigation targets. It reuses the existing resolver and lazy library loading, reads current source buffers, and selects the destination identifier.Go to Implementation reuses Go to Definition's source targets, including concrete model/function bodies. It does not enumerate concrete subclasses of partial classes or resolve instance-specific redeclarations; those are separate enhancements. Both new handlers respect client location-link support and return no destination for unsupported documents or unresolved symbols. The READMEs document this scope.
Closes #10.
Validation:
The coverage percentages are repository-wide; bundled-server protocol tests provide the behavioral checks for the new handlers.