Third-party plugin development is deprecated, we remove everything redundant for a monorepo-only usage of the SDK:
- Support for non-local plugin dependencies is removed (Marketplace resolution)
- Dock resolution by version is removed
- Gradle integration for sources of non-Gradle friendly jars is removed (Ivy repositories)
- Convenient vendor resolution from Marketplace is removed
- Support for odd/different plugin project layouts is removed
GitOrigin-RevId: 27cbdeb81cdebc1760825c0d1fb797af1a549729
LSP allows the client to provide a filesystem watcher to the server, to
simplify server's implementation and to remove duplication of work,
since clients often require such watchers anyway.
Air's implementation is based on the FSD's WatchApi. This means there
are some differences to the VS Code watchers, for example, our
implementation will never emit "Created" event, because this isn't
exposed in the WatchApi. Conversely, WatchApi may emit a "Rescan" event
which doesn't have an appropriate equivalent in the VS Code (hence, LSP)
watcher interface.
Other than that, the implementation tries to follow the VS Code
behaviour in most cases (e.g. using recursive watchers if pattern
contains "**" or "/" and non-recursive otherwise), so the
recommendations on the use of the LSP watcher API are roughly the same
as for VS Code.
Space-RevId: 1ad774f7425f86e11aab4e64e62e96453bfc864a
GitOrigin-RevId: 5a1abadc8f18deb06b71625ab2add0f0b6f030a7
Caffeine cache does not guarantee recent items being available. Store latest completion session as is in db instead.
GitOrigin-RevId: b0c942db8d2737469ed957b901dc810570d6cef6
We now have two dedicated loggers to handle logs sent by the server to
the client.
fleet.workspace.lsp.LSPServer logger is for general logging that a
server may wish to perform. Incoming log messages will be mapped to our
own log levels (ERROR, WARN, DEBUG, etc.) and only printed if the logger
config is set to print messages at that level.
fleet.workspace.lsp.LSPServerTrace logger is for tracing. The LSP
specification identifies these two types of logging as distinct, making
this logger specifically for debugging purposes.
The f.w.l.LSPServer logger's source is "window/logMessage"
notifications, as for f.w.l.LSPServerTrace, it receives the log entries
with the "$/logTrace" notification.
GitOrigin-RevId: 41c038424ae15a22725b8d7c2c738bbaf0c953df
When implementing readUTF8Line, it wasn't taken into account that the
`readBuffer` getter is not guaranteed to return the exact same buffer
state between accesses, even if `awaitContent` wasn't called.
The specific implementation of ByteChannel from ktor tried to fill the
buffer on access whenever it happens to be exhausted and some data was
available in the "flush" buffer.
This could lead to more data being read in the line reader loop than
expected, resulting in an invalid payload and broken framing in the LSP
protocol framing.
Now we read sequentially byte after byte. The new implementation is an
almost verbatim copy of the readUTF8LineTo method from the ktor utils.
GitOrigin-RevId: fe0cd982e94be15c6281462aa9c360d7472512dd
Most of the used conditional features (i.e. the features that require a
capability check) are now implemented as dynamic features, meaning they
can be registered through the `registerCapability` request while the
client is running.
The capability check is replaced by a feature registration check
instead.
GitOrigin-RevId: 0601feb9f5f14c58a8b30c66bae65940e53166c6
Until now they were carrying a JsonElement and required passing a
serialiser on every use, which was slightly inconvenient.
GitOrigin-RevId: 603744e8a22573e56b0f16502e926ba0c9d8e5f1
This commit contains only regenerated build.gradle.kts files after adding all required modules to ios target. Since it doesn't contain the actuals for ios, fleet won't compile from this revision
GitOrigin-RevId: aed8a8ef07578abb984bc79f3cbf1b6755196520
The `lsp.protocol` module now doesn't depend on ktor.
All code that was depending on it was pushed in the module users.
GitOrigin-RevId: f065946f470ab9d13c457a0623267c2cb55dd0e5
We want to remove ktor dependency from the lsp.protocol module as it
conflicts with other uses.
The module has a single usage of ktor, its i/o utils types:
ByteReadChannel and ByteWriteChannel.
These are now replaced by requivalent interfaces. In this patch, ktor
dependency is still present and implements the aforementioned interfaces
in this same module, but the goal is to move the implementation into
module consumers.
GitOrigin-RevId: 62681cd01c54b00cab7e17682fe6858db01d4186
Progress reporting during initialisation has a time-based debounce: the
sending coroutine (working concurrently with the passed-in block) is
waiting 100ms after sending a progress update, before proceeding with
the next update.
When the block returns, the sending coroutine is immediately cancelled,
robbing it of a chance to wake up and deliver the end progress message,
that the block requests at the very end. This caused the never-ending
progress displaying in Air.
The "withProgress" function has been fixed to always send begin/end
message out of bound and only debounce intermediate progress updates.
Since the end message may be a subject for customisation, depending on
the execution path taken, to enforce the begin/end contract on progress,
the signature was updated: the function now takes the begin progress
title, and the block is now required to return "WorkDoneProgress.End"
instance that will be sent to the client.
To keep the code simple, the function no longer returns a generic T. It
can be added back, if necessary, however, currently it only has one
usage that expects Unit.
GitOrigin-RevId: ea8b390cb7bca4c894c5c2b75e304b71eaf03481
This patchset adds dynamic capability registration.
Dynamic capabilities are implemented in a form of dynamic features, by
conforming to the `DynamicFeature` interface (and its corresponding
`Descriptor`).
Symmetrically, one can create "static" features by conforming to the
`StaticFeature` interface. This is mostly mimicking the vscode model.
As an example, two features were implemented:
`LSPPublishDiagnosticFeature` which is a "static" feature, and
`LSPDiagnosticFeature`, which is an example of a "dynamic" feature.
Dynamic features can be "activated" by registering them. The
registration can happen upon server initialisation, if the server
responds to the initialised request with registration data in its
capabilities. If not, the server may later invoke the
`"registerCapability"` method to register a dynamic feature.
Dynamic features can be later "deactivated" if the server invokes the
`"unregisterCapability"` method with the corresponding registration id.
This is the starting point for converting more features to allow their
dynamic registration, which is a requirement for some servers.
GitOrigin-RevId: 5ad44219ed08546ab200d7b210d8176c5d45bf8b
We'd only pull markup (such as inlay hints, code lenses, etc.) in
response to the "workspace/*/refresh" notifications, which is what
rust-analyzer sends on every document change, but that's not how it is
supposed to work. By the spec, those notifications should occur whenever
a project-wide change was detected by the server that may have affected
all documents' markup.
The expected behaviour is that the client (Air) requests the changes for
all the markup whenever it thinks it's convenient and warranted. This
translates into requests on any document change.
It wasn't necessary with rust-analyzer, since the original way worked,
but we didn't get any live updates to inlay hints and others when using
different language servers, such as typescript LSP server.
In addition, a dignostic pull was added with the same kind of trigger
(on every document change). This is necessary to support kotlin LSP,
which doesn't ever send textDocument/publishDiagnostic notification.
GitOrigin-RevId: 5df5c2981336fe0fba1cb5e04c6883deef2e9bd6
Bartek Pacia
Titouan Bion
Leonid Shalupov
Ludwig Valda Vasquez
Georgii Ustinov
Mikhail Filippov
Andrey Zaytsev
Nikolay Rykunov
Gregory.Shrago
Rustam Sadykov
Sergei Sysoev
Alexander Zolotov
pavel.mikhailovskii