Introduces Language.ADA backed by AdaCore's Ada Language Server (ALS),
the standard LSP-compliant server for Ada — and SPARK, since both share
the .ads/.adb file extensions and ALS distinguishes SPARK by source-level
pragmas/aspects rather than by file type.
ALS is auto-downloaded from AdaCore's GitHub releases (linux-x64/arm64,
darwin-x64/arm64, win32-x64) using the LanguageServerDependencyProviderSinglePath
pattern, with SHA256 verification per-platform. Users can override the
downloaded binary by setting ls_specific_settings.ada.ls_path to a
pre-installed ada_language_server (e.g. from Alire, GNAT Studio, or the
VS Code Ada extension).
Test repo is a minimal multi-file GNAT project (default.gpr, helper.ads,
helper.adb, main.adb). Tests modelled on test_php_basic.py: ls_running,
find_definition (within/across), find_references (within/across),
find_symbol, document_symbols, hierarchical document symbols,
bare-symbol-name sanity check.
* feat(jdtls): surface Lombok-generated methods in document symbols
JDTLS' DocumentSymbolHandler filtered out every SourceMethod where
JDTUtils.isGenerated() was true, so Lombok-synthesised methods (getX/setX,
builder(), equals/hashCode/toString, withX, fluent accessors, ...) never
reached the LSP client. As a result Serena's symbol-aware tools — find_symbol,
get_symbols_overview, replace_symbol_body, insert_before_symbol,
insert_after_symbol — could not see, address or edit any Lombok-generated
member; only search_for_pattern / replace_content (text-based) worked.
Upstream introduced an opt-in preference java.symbols.includeGeneratedCode
in eclipse-jdtls/eclipse.jdt.ls#3706 (merged 2026-02-24) and surfaced it
through redhat-developer/vscode-java#4335. First vscode-java release with
the new JDTLS build is v1.53.0 (2026-02-26). Serena was pinned to v1.42.0-561,
well before the fix existed.
Changes:
- New ls_specific_settings.java.lombok_show_generated setting (default true);
forwarded to JDTLS as java.symbols.includeGeneratedCode in initialize
params. Older servers ignore the unknown preference key silently.
- Bump bundled vscode-java DEFAULT 1.42.0-561 -> 1.54.0-923 (brings JRE
21.0.10, Lombok 1.18.39 and Equinox launcher 1.7.100). INITIAL stays at
1.42.0-561, so per the per-version install-dir convention from #1438 the
new build lands in vscode-java-1.54.0-923/ while legacy vscode-java/
caches and any explicit vscode_java_version: '1.42.0-561' override keep
working.
- New VsixResourcePaths dataclass + INITIAL/DEFAULT_VSCODE_JAVA_PATHS pin
the JRE / Lombok / launcher filenames *inside* the VSIX. Without this,
bumping the archive would break users on legacy 1.42.0-561 because
resource paths inside the archive change between releases. Resolution
mirrors SHA pinning: known versions get their pinned paths; any other
version raises SolidLSPException with a pointer to upstream-jdtls mode
(which derives paths dynamically and needs no pinning).
- Drop dead 'static/vscode-java/...' placeholder in initialize params; the
real runtimes[] is overwritten below from runtime_dependency_paths
.jre_home_path, which is correct in both default-VSIX and upstream-jdtls
modes.
- Test fixtures: Lombok provided dep in test_repo/pom.xml plus
LombokModel / FluentLombokModel / DefaultGreeter covering @Data, @Builder
(toBuilder=true), @With, @Delegate, @AllArgsConstructor, @NoArgsConstructor
and @Accessors(fluent=true). Regression test in test_java_basic.py
asserts every generated-method shape lands in document symbols.
Closes#1432
- Add 'Additional Workspace Folders' section to project configuration docs
- Add cross-reference note to TypeScript LS settings section
- Include configuration example and usage notes
The TypeScript language server was initialized with a single workspace folder,
so tsserver could not discover references across sibling packages in a monorepo.
This adds an `additional_workspace_folders` setting in
`ls_specific_settings` that accepts a list of directory paths.
Each folder is registered as an LSP workspace folder during initialization,
and a representative .ts file is opened from each to trigger tsserver project
loading. This enables `find_referencing_symbols` and `request_references` to
return results from across package boundaries.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Per the LSP spec, Content-Type is optional and defaults to
application/vscode-jsonrpc; charset=utf-8 (the exact value we were
sending). Spec-compliant servers behave identically with or without it.
In practice some servers have stricter parsers. Notably, Godot's
GDScript LSP (LSPeer::handle_data in
modules/gdscript/language_server/gdscript_language_protocol.cpp)
extracts the body length via header.substr(16).to_int() and silently
drops messages that contain any header beyond Content-Length.
Sending only Content-Length is interoperable across the spec-compliant
servers we use today and unblocks Godot's LSP. Also tightens the type
signature of create_message from tuple[bytes, bytes, bytes] to
tuple[bytes, bytes] now that there is no Content-Type element.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Per the LSP spec, Content-Type is optional and defaults to
application/vscode-jsonrpc; charset=utf-8 (the exact value we were
sending). Spec-compliant servers behave identically with or without it.
In practice some servers have stricter parsers. Notably, Godot's
GDScript LSP (LSPeer::handle_data in
modules/gdscript/language_server/gdscript_language_protocol.cpp)
extracts the body length via header.substr(16).to_int() and silently
drops messages that contain any header beyond Content-Length.
Sending only Content-Length is interoperable across the spec-compliant
servers we use today and unblocks Godot's LSP. Also tightens the type
signature of create_message from tuple[bytes, bytes, bytes] to
tuple[bytes, bytes] now that there is no Content-Type element.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Apply common functionality already used in JetBrainsFindDeclarationTool
* Remove location-based tool (counteracts Serena's principle to eschew line numbers)
* Apply renaming to use "find declaration" instead of "find defining symbol"
When the Codex client sends shell work via `exec_command`, the tool name is
always `exec_command` and the actual command is under `tool_input.cmd`. The
previous `is_grep_tool` / `is_read_file_tool` checks inspected only the tool
name and therefore never fired for Codex grep/read workflows.
Add `_GREP_SHELL_COMMANDS` and `_READ_SHELL_COMMANDS` frozensets and a helper
`_get_exec_command_name()` that extracts the basename of the first token in
`cmd`. Both detection methods now use these to classify `exec_command` calls
when the client is `HookClient.CODEX`, leaving all other client paths unchanged.
Co-Authored-By: Octopus <liyuan851277048@icloud.com>
Dominik Jain