Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Store diagnostics in the database #689

Merged
merged 10 commits into from
Dec 22, 2023
Merged

Conversation

alcarney
Copy link
Member

@alcarney alcarney commented Nov 27, 2023

  • Instead of pushing the diagnostics to the parent language server with each build result, captured diagnostics are now saved to the sphinx-agent's database.
  • For clients that don't support the pull diagnostics model (introduced in LSP v3.17), the server uses textDocument/publishDiagnostics as before.
  • For the clients that do support the pull model, the language server now implements the textDocument/diagnostic and workspace/diagnostic methods.

The `Esbonio` object, accessible via the `esbonio` field on the Sphinx
application object provides a single entry point from which we can
expose all our integrations with the parent language server.

This should also make it easy for extensions to detect when they are
running within `esbonio` and enable any additional integrations.

As well as exposing the database, this object now also holds our
logging handler.
Rather than push diagnostics to the parent language server on each
build result, the new `diagnostics` Sphinx extension saves them to the
database instead.
Rather than look for diagnostics in the sphinx agent's build result we
now read them from the agent's database, using the end of the build as
a trigger.

Once passed to the server, we call `sync_diagnostics()` to publish
them to the client.
If the client supports the pull model of diagnostics introduced in LSP
v3.17 the call to `sync_diagnostics()` is now a no-op
For client's that support it, the language server is now able to
report the diagnostics associated with the given text document
For client's that support it, the language server is now able to
report the diagnostics reported for the workspace
`gather_results` combines the results returned from all registered
language features into a single list.

While no longer necessary for diagnostic support (it was used in a
previous implementation attempt). The `gather_results` function will
be used for future methods so we may as well add it now it's been written.
- Only run tests for a single builder.
- Create a fresh client for each test case
@alcarney alcarney merged commit 4a5124d into swyddfa:develop Dec 22, 2023
12 of 13 checks passed
@alcarney alcarney deleted the diagnostics branch December 22, 2023 19:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant