Elvis/vscode extension

[ezekielelvis]

[WIP]This pull request introduces significant improvements to the VS Code extension for XTC, focusing on enhanced debugging support, improved task and command integration, and better developer experience through configuration and documentation updates. The main changes are the addition of a Debug Adapter Protocol (DAP) integration, new commands and tasks for running and managing XTC modules, and updates to build scripts and configuration files to support these features.

Debugging and Task Integration

• Added a new Debug Adapter Protocol (DAP) integration, including a XtcDebugAdapterDescriptorFactory and XtcDebugConfigurationProvider in debug-adapter.ts, enabling users to debug XTC modules directly from VS Code. This includes logic to find the Java executable, launch the DAP server JAR, and provide debug configuration defaults.
• Introduced a new task provider and command registrations in commands.ts, allowing users to run XTC modules, create new projects, and show language server output directly from the command palette.
• Updated package.json to declare new commands (xtc.runModule, xtc.restartServer, xtc.showServerOutput), a custom XTC task type, and a new debugger type (xtc) with configuration snippets and attributes for module debugging. [1] [2] [3]

Build and Launch Configuration

• Updated the build.gradle.kts build script to copy the DAP server JAR into the extension's server directory, and ensured that both the LSP and DAP servers are included in packaging and assembly tasks. The VS Code launch command now opens the test fixtures folder for easier testing. [1] [2] [3] [4]
• Added and updated VS Code workspace configuration files (.vscode/launch.json, .vscode/tasks.json) to support extension development, building, and debugging workflows for both the root and extension subfolders. [1] [2] [3] [4]
• Updated .gitignore to exclude .vscode-test/ from version control.

Documentation and Developer Experience

• Enhanced the README.md with clearer setup instructions, improved project structure documentation, and step-by-step guides for building, running, and testing the extension locally. [1] [2] [3] [4] [5] [6]

These changes collectively make the XTC VS Code extension much more robust and user-friendly, especially for debugging and automation workflows.

[ggleyzer]

I'm really out of my depth here and would completely defer to Markus.

My only comment is: this PR seems to be an indicator that it wasn't the best idea to keep the plugin as a part of the xvm repo. May be we should start a new "plugin" repo using this PR?

[lagergren]

I'm really out of my depth here and would completely defer to Markus.

My only comment is: this PR seems to be an indicator that it wasn't the best idea to keep the plugin as a part of the xvm repo. May be we should start a new "plugin" repo using this PR?

There is nothing in the PR after updates that leaks out of lang, and as we have talked a lot about there is a migration plan to standalone implementation when I have finished the type adapter work, and there is a good reason that this lives under lang until that integration path is finished.

I am still in deployment hell but I will try to review tonight or tomorrow. Now, however, it looks safe, in that it doesn't bleed out state into the rest of the code and lives self contained under lang just like the intellij plugin and the lsp server that both use. The only concern I have is about the node dependency potentially being resolved even if we are not creating a vscode-plugin build, and that, like the intellij toolkit, also is a very large download/install (although cached of course):

[lagergren]

There is an issue with the CI / build and test trying to resolve the libs.versions.toml gradle plugin but fails. Not sure why, but I think that it needs to live only under lang an only when the vscode plugin is being built.

[lagergren]

Where:
Build file '/home/runner/work/xvm/xvm/lang/vscode-extension/build.gradle.kts' line: 5

• What went wrong:
  31 actionable tasks: 11 executed, 2 from cache, 18 up-to-date
  Script compilation error:

  Line 5: alias(libs.plugins.langNodeGradle)
  ^ Unresolved reference 'langNodeGradle'.

1 error

[lagergren]

The issue is that one of x files no longer parse equivalently between the lsp parser and the Java parser. This is likely an issue in treesitter caused by someone changing parser behavior or grammar in master, but not in the treesitter grammar template. It hasn't got anything to do with your branch. If you want, add the falling file to the skip list documented as a known outage and we can approve this for merge.

The treesitter grammar validation tests only run for a branch that changes stuff in the Lang tree. This means that I think the test would fail if running in master itself. I am on the road most of the day, but if you can confirm thst validateTreeSitter grammar fails in master too with Lang attached, then the theory is confirmed. You can check the commit.yml to see how to run the validation test, or you could just trigger a GitHub workflow on master with workflow dispatch (manually) with the "test lang" boxes checked and it should do it automatically for you.

I will take a look in a few hours when I return to civilization.

[lagergren]

Why the tree-sitter validation went red on this PR but is green on master

Short version: this isn't a tooling or grammar regression — it's two new XTC syntax patterns that were added to the manualTests corpus between May 6 and May 17 and that the tree-sitter grammar never had test cases for. The path-filter gate in .github/workflows/commit.yml (dorny/paths-filter on lang/**) hid both of them from master CI because the PRs that introduced them only touched manualTests/ and javatools/.

Date	Commit	Test addition
2026-05-06	0120712a1 Fix NameExpression code production for parameterized virtual child classes	generics.x:27 — Type t2 = Base<Int>.Child2<String>; (value-position virtual-child type with generic args)
2026-05-17	91f6d7d96 Fix a compiler exception (#463)	annos.x:141 — annotation PreComputed(...) into Predicate { ... } inside a method body (local annotation declaration)

Both PRs were compiler bugfixes that added a single new line of XTC to verify the fix. Because neither touched lang/**, the tree-sitter validation step on master was skipped (path-filter conclusion: lang=false). On this PR, the lang/vscode-extension/** changes trip the same filter (lang=true), so the validation step runs — and surfaces both pre-existing latent failures.

The skip lists (treeSitterParseSkipList.parked.txt, treeSitterParseSkipList.intentional.txt) and the grammar template itself were unchanged between PR #452 (May 1, last grammar work) and the May 6 / May 17 corpus additions. The comment in parked.txt claiming "generics.x parses cleanly now — removed from this list" is incidentally misleading: git log -S "manualTests/src/main/x/generics.x" -- treeSitterParseSkipList.parked.txt returns empty, so generics.x was never actually in any skip list.

Fix in this PR: two grammar template edits — annotation_declaration added to _statement, and member_type (with-type-arguments form at prec.left(MAX_PRECEDENCE_PLUS_3)) added to _expression. Local test now reports 881 passed, 0 failed (was 879 / 2).

Suggested follow-up (not in this PR): the path-filter for the tree-sitter step in commit.yml could also include manualTests/**/*.x so that new corpus shapes get grammar-checked on master, not just on PRs that happen to touch lang/**. That would have caught both regressions at the source.

Fixed.