The Nextflow language server does not scan the workspace when it says it does.
`LanguageService.initialize` -- which the "Initializing" progress notification we
wait for wraps -- only marks the workspace as unscanned and clears the AST cache.
The scan itself happens in `LanguageService.update0`, behind a 1s debounce, and
only on a round that finds no pending file change; a round that does find one
re-defers it via `updateLater`. The first `didOpen` of a session therefore pushes
the scan out by at least one further round, so a references request issued right
after it sees an AST cache holding nothing but the file it just opened and answers
with an empty list.
Force the scan rather than waiting for it. `completion` is one of the two requests
that call `updateNow` before consulting their provider, and
`DebouncingExecutor.executeNow` cancels the pending debounce and runs the update
synchronously on the request thread, so the response is not sent until that round
has finished. Two rounds suffice whatever the workspace size: the first drains the
pending file changes -- which is what re-defers the scan -- and the second finds
nothing pending, so it compiles the whole workspace before replying.
Polling the workspace symbol index instead would be unsound: `LanguageService.symbol`
neither awaits the update nor holds the monitor that `update` synchronises on. On a
generated 1050-file workspace, polling it made the server raise
`java.util.ConcurrentModificationException` from inside the scan, non-deterministically
(6, 3 and 0 times across three runs).
The existing cross-file reference test did not catch the empty results because the
`language_server` fixture is module-scoped: earlier tests in the class had already
opened main.nf and forced the server to compile it, so the assertion passed for a
reason that does not hold in a real session. Run alone, it failed. The added test
starts its own server and opens nothing but the defining file.
Verified on the 1050-file workspace, where the symbol has exactly 100 references:
without the fix 0 are found, with it all 100, in 2.5s.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Metals serves one build per workspace folder, and Serena sends only the
repository root. Where the builds live below the root, Metals falls back to
its own search (BuildTools.searchForBuildTool), which looks one level down
and takes the *first* match — so in a monorepo every build but that one is
served with no build target, and cross-file references silently come back
empty.
Detect the build roots instead and send them all, one Metals service each.
`ls_specific_settings.scala.project_roots` names them explicitly where the
detection guesses wrong, `project_root_scan_depth` bounds the search.
The configured `ls_workspace_folders` are not usable for this: they are about
what SolidLSP indexes and are shared by every language server of a project, so
in a polyglot monorepo no single value suits both Metals and, say, tsserver.
Where the repository root is itself a build root, nothing changes.
The Nextflow language server schedules a debounced (1s) AST update on every
didOpen/didChange, and LanguageService.references is the only request that does
not await it -- documentSymbol, codeLens, documentLink and semanticTokensFull
all do. A references request issued inside that window races the recompile of
the file it asks about and can return an empty list, which is what the macOS CI
runner hit. Send a documentSymbol request for the same file first, which blocks
server-side until the pending update has been applied.
Also compare reference paths using the platform separator in the tests, since
relativePath is OS-native and the hardcoded forward slashes failed on Windows.
* scala: answer Metals' build-import prompt
Metals asks, via window/showMessageRequest, whether to import a workspace it
has not seen before. Serena registered no handler, so the request came back
`method 'window/showMessageRequest' not handled on client` and Metals logged
"Unexpected error initializing server" and gave up. No build server, no build
target, and every cross-file query answered by the fallback presentation
compiler — which cannot see past the file it is given.
A client cannot decline the question instead: Metals' `disableShowMessageRequest`
is server-side configuration, and its no-op fallback answers "Not now", which
imports nothing either. Answering is the only route to a build.
So answer the three prompts that lead to a build server, and dismiss anything
else with `null` — a prompt we do not recognise is one whose consequences we
cannot judge, and two of Metals' others offer to kill a process and to open a
window. "Don't show again" is never chosen; Metals persists that in the
project's own state.
Since answering yes lets Metals run the project's build tool,
`ls_specific_settings.scala.auto_import_build: false` declines instead.
* scala: name the build-tool choice as a gap, and test the setting
`Messages.ChooseBuildTool` ("Multiple build definitions found. Which would
you like to use?") offers the build tools' own executable names, and precedes
the import prompt wherever a workspace holds more than one kind of build. It
is dismissed like anything else unrecognised, so such a workspace is still
not imported — a deliberate choice, since picking one is a guess of a
different order, but one the comment and the setup guide should admit to
rather than claim every prompt on the path is answered.
Also: cover the route from `ls_specific_settings` to `auto_import_build`,
which nothing exercised, and correct the `ImportBuildChanges` message in the
fixtures, which had the notification variant's trailing full stop rather than
the request's own text.
* feat(kotlin): update language server to 262.9593.0
Note: download URL structure differs depending on version
---------
Co-authored-by: Dominik Jain <dominik.jain@oraios-ai.de>
Add a Deno language server backed by the Deno CLI's built-in `deno lsp`,
serving TypeScript/JavaScript in Deno projects. Unlike the plain
typescript-language-server it understands Deno module resolution
(npm:/jsr:/https: imports) and the `Deno.*` global namespace.
It is experimental and must be selected explicitly via
`language_servers: [deno]`; it overlaps the TypeScript server on file
extensions, so it is not auto-detected. Requires the `deno` CLI on PATH.
Tests run in CI: the `deno` marker joins the other-langs batch, which now
installs Deno via denoland/setup-deno. Off-CI and wherever the CLI is
absent they skip through the central conftest guard, following the existing
pattern for toolchain-gated language servers. Hover is covered explicitly,
including hover on a `Deno.*` global, which is the capability this server
adds over the TypeScript one.
SolidLanguageServer.create previously defaulted timeout=None, so Request
waits were unbounded. Test construction never set a timeout; a wedged
language server (intermittent ccls hang during indexing) could stall CI
until the job cap.
Default create to DEFAULT_LS_REQUEST_TIMEOUT (300s). Explicit timeout=None
still opts out. Project continues to pass ls_timeout from tool_timeout.
Resolves#1717
Co-authored-by: Dominik Jain <dominik.jain@oraios-ai.de>
The tray manager creates the shared NSApplication so that pystray can
attach its status item to it, but it never sets an activation policy.
The default is NSApplicationActivationPolicyRegular, which makes the
process a regular app: a Python icon appears in the Dock and in the
app switcher even though the tray manager has no windows.
Set NSApplicationActivationPolicyAccessory instead, which is the
policy intended for menu-bar-only agents. Only the status item remains
visible.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- Tools that explicitly target a single file (`create_text_file`, `read_file`, `replace_content`) no longer
consider ignored paths in general, i.e. all files can be accessed.
When a path is explicitly accessed, we should not try to prevent it; the agent is assumed to have a good reason
for doing so.
- Tools that traverse a subtree of the project (`list_dir`, `find_file`, `search_for_pattern`) now all have an
option `skip_ignored_files` (whether to skip ignored sub-paths).
Note that if the base path is itself ignored, ignored paths cannot be considered.
Resolves#1805
`workspace/inlayHints/refresh` (plural) is not a method in the LSP
specification — the refresh request is `workspace/inlayHint/refresh`.
The handler could therefore never be invoked, so the request it was
meant to absorb would still be answered with `MethodNotFound`.
The Kotlin language server client advertises `refreshSupport` for
codeLens, semanticTokens, inlineValue, inlayHint and diagnostics, but
registered no handler for the corresponding `workspace/*/refresh`
requests.
When the server sends one, `LanguageServerProcess._request_handler`
finds no handler and replies with `MethodNotFound`. The Kotlin LSP
treats that error as fatal and terminates, which surfaces as
`LanguageServerTerminatedException` and kills any in-flight tool call.
Register no-op handlers for all five advertised capabilities, mirroring
what `svelte_language_server` already does.
Erlang LS identifies functions, types and parameterised macros as
`name/arity`, but `/` separates the components of a Serena name path, so
`create_user/4` was parsed as "symbol `4` nested inside `create_user`" and
could never match -- not even via the name path Serena itself reported for
the symbol. Browsing still worked, but find_referencing_symbols,
replace_symbol_body and insert_after_symbol were unusable on Erlang
functions.
Normalize the name to `create_user#4` instead. `#` cannot occur in an
unquoted Erlang atom, so it can never collide with a real name, unlike `@`.
The arity is kept rather than stripped because it is part of a function's
identity in Erlang: create_order/3 and create_order/2 are different
functions and may coexist in one module.
Also document the "no `/` in symbol names" rule on _normalize_symbol_name,
which is what the next backend for such a language needs to know.
* Add DownloadedDependency abstraction to facilitate handling of downloaded
and hash-verified dependencies.
In CI, missing hashes raise an exception.
For users, unverified downloads log a warning.
* Add DownloadedDependencyHashDatabase which manages a URL-keyed database
of sha256 hashes. It can be conveniently updated incrementally through a
script (src/solidlsp/resources/downloaded_dependency_hashes.json),
provided that language server implementations provide DownloadedDependency
instances statically
Applied in EclipseJDTLS:
* Replace the untyped nested-dict runtime dependency descriptors with DownloadedDependency instances
* Move the JDTLS version-pinning constants into DependencyProvider
* Replace the platform dependency dicts with the VSCodeJavaConfig dataclass
Utils:
* Add FileUtils.ArchiveType to type archive types that were previously plain str
* Add is_running_in_ci() to ls_utils
Updated memory on adding a language server accordingly.
Instead of sending only the didOpen notification if the file is not already open,
the method now ensures that the language server has the (current) contents of the file,
sending the didChange notification in cases where the file is already open but has changed
on disk. This better reflects the actual intention of calling the method.
This affects the Vue and Svelte language servers, which unlike all other server implementations,
kept files open, which could result in the servers reporting stale information in the
absence of update notifications (external file changes).
