lsp_core
lsp_core::Analysis Document-level analysis: parse-and-check diagnostics, Markdown hover for the symbol under the caret (falling back to an inferred type), go-to-definition, inlay hints, and the canonical format edit. Resolution is delegated to `model`; this maps the result into LSP shapes.
Parent
Inbound
- call lsp_core::LspCore · definition
- call lsp_core::LspCore · formatEdit
- call lsp_core::LspCore · hover
Outbound
- call → model::Model · check
Scenarios
Resolution is delegated to the model, not re-implemented.
- given a cursor feature — hover, definition, references, completion
- when the symbol under the caret must be resolved
- then resolution runs through model's resolver against the workspace and externals
- and this crate only maps the resolved answer into the LSP shape
Hover shows the `///` summary of the symbol under the caret.
- given the caret resting on a declared node, data type, or member
- when hover runs
- then the symbol's kind and FQN, or its member signature, is shown
- and its `///` summary is appended under the title
An unresolved caret on a local binding falls back to its inferred type.
- given the caret resting on a local binding rather than a declaration
- when hover finds no declared symbol there
- then the binding's inferred type is shown as `name: Type`
- but an expression that cannot be typed yields no hover
Resolution survives a partial parse by working at the token level.
- given a document that does not fully parse
- when the caret rests on an identifier in a well-formed region
- then resolution still tokenizes and resolves that identifier
- but a caret on whitespace, punctuation, or an unknown name yields nothing
Whole-document format produces an edit, or nothing on a parse error.
- given a document buffer
- when a format edit is requested
- then a parseable document yields one whole-document edit to canonical form
- but an unparseable document yields no edit
lsp_core::Complete Completion: the candidates offered at a byte offset, resolved across the workspace and its externals. A `.`/`::` boundary drives member and path completion.
Parent
lsp_core::CompletionItem One completion candidate: the inserted label, the integer LSP `CompletionItemKind`, and detail text.
lsp_core::Convert Position conversion: the single home for mapping between byte offsets and UTF-16 line/character positions, so every handler agrees on coordinates.
Parent
Scenarios
Spans map to UTF-16 positions consistently across every handler.
- given a byte span in a document
- when it is converted for the editor
- then it maps to a UTF-16 line/character range
- and every handler shares this one conversion, so coordinates always agree
lsp_core::DefTarget A go-to-definition target: the FQN of the module the definition lives in and the byte span of the definition within that module's source. The consuming edge maps `fqn` to a file URI and converts `span` to an editor range against *that* file's text — `lsp_core` returns the byte span, not a `Range`, because it does not hold the target module's source to convert against.
lsp_core::Diagnostic One diagnostic mapped to LSP shape: its range, severity, message, optional code, and the code's article URL (`codeDescription`, the editor's clickable link — empty when the code carries no article). Converted from the parser/checker's byte-span diagnostics; the code and its URL pass through unchanged.
lsp_core::Hover Markdown hover content the editor renders in a tooltip.
lsp_core::LspCore `crates/pseudoscript-lsp-core`. The single home for language intelligence as transport-neutral handlers — the same logic the stdio server and the browser wasm both call.
Parent
Inbound
- call lsp::Server · hover
- call lsp::Server · definition
- call lsp::Server · formatEdit
Outbound
- from → lsp::Option
- call → lsp_core::Analysis · definition
- call → lsp_core::Analysis · formatEdit
- call → lsp_core::Analysis · hover
Scenarios
One implementation answers from current text, transport-free.
- given a buffer's current text and a caret position
- when a language query runs
- then the answer is computed as a pure text-plus-position function
- but no transport, async runtime, or tower-lsp is involved — both edges share it
lsp_core::Position A zero-based caret position: line and UTF-16 character offset within the line. This and the shapes below model the standalone `lsp_types` vocabulary the crate returns (pinned to the version tower-lsp re-exports, wasm-safe), so the server edge passes values through with no conversion.
lsp_core::Range A half-open text range between two positions.
Inbound
- from lsp::Server
lsp_core::Refs References and rename: every occurrence of the symbol under the caret across the workspace, the document highlights for it, and the workspace-wide rename edits.
Parent
Scenarios
Rename rewrites every occurrence of one definition across the workspace.
- given the caret on a renameable symbol
- when rename runs
- then every identifier resolving to the same definition is collected
- and each occurrence is rewritten across all files that reference it
- but a `::` module qualifier is never treated as an occurrence
lsp_core::Semantic Semantic tokens: AST-aware highlighting that colours each token by its declared role, plus the legend the editor binds.
Parent
Scenarios
Semantic tokens colour identifiers by their declared role.
- given a parsed module
- when full semantic tokens are requested
- then each identifier is coloured by its role — node, data, callable, parameter
- and keywords, docs, and literals are coloured too
- but overlapping, multi-line, or zero-width spans are dropped before encoding
lsp_core::Symbols Document and workspace structure: the outline symbols, the foldable ranges, and the workspace-wide symbol query.
Parent
lsp_core::TextEdit A text edit: replace `range` with `newText`. Formatting and rename return these.