hover

Use hover for the type, signature, or documentation supplied by the language server at exact source occurrences or registered handles. It is the cheapest check before calling an API: the exact signature and documented contract, without reading any file.

Use when

You need resolved information for identifiers visible in source.
You need hover information for complete canonical handle groups.

Do not use when

The target is not an actual source occurrence; generated annotations are not valid targets.
You need a definition body or references; use jump, extract, or show_usage.

Request

{"file":"/workspace/project/src/lib.rs","symbols":[["UserService",42]],"workspace_root":"/workspace/project"}

Parameters

Field	Required	Default / bounds
`file`	source form	Path; `file_path` is accepted as an alias.
`symbols`	source form	Entries are `[symbol_name, line]`; line is a 1-based integer.
`handles`	handle form	Registered handles; mutually exclusive with source fields.
`workspace_root`	no	Only needed when multiple workspaces are active.

What it returns

Language-server hover information for each target, resolved independently. Source requests can batch related identifiers from one file.

Example

Real output — hovering into_parts at its call site:

### into_parts

context_engine::daemon::control::RegisteredConnector

pub(crate) fn into_parts(self) -> (ConnectorId, String, SocketAddr, ConnectorLease)

Transfers all connector-owned values without exposing protocol fields.

Signature, owning type, and the documented contract — for the exact occurrence, not a same-named lookalike.

Common mistakes

Quoting line numbers or using zero-based lines.
Targeting generated type annotations instead of source identifiers.
Using a source target when a previously discovered handle is the intended canonical group.

jump navigates to the definition when the tooltip is not enough.
extract reads a full body or documentation view by handle.
line_context returns the containing item instead of one identifier.

On this page