Add XTC Language Support: LSP server, IntelliJ plugin, and VS Code extension

[lagergren]

Summary

XTC language tooling infrastructure with IDE support and high-quality parsing.

Tree-sitter Grammar

• 100% coverage on all 692 XTC test files with only 49 GLR conflicts
• External scanner (Kotlin DSL → C) for template strings ($"text {expr}", $|multiline|) and TODO freeform text
• Zig cross-compilation builds native libraries for all 5 platforms from any dev machine:
  • darwin-arm64, darwin-x64, linux-x64, linux-arm64, windows-x64
• Pre-built libraries committed to source control (no Zig download in CI)
• JVM integration via jtreesitter using Java's Foreign Function & Memory API

LSP Server

• Pluggable adapter architecture: MockXtcCompilerAdapter (regex, for testing) → TreeSitterAdapter (syntax-level) → future CompilerAdapter (semantic)
• Switch adapters via -Plsp.adapter=treesitter
• Comprehensive logging with parse times, query execution, symbol resolution

IDE Plugins

• IntelliJ: New Project wizard, run configurations (--module, --method, --args), TextMate highlighting, LSP via lsp4ij
• VS Code: Extension skeleton with TextMate grammar

Other

• xtc init command: New launcher command for initializing XTC projects with --dir option
• DSL generators: TextMate, Vim, Emacs, Sublime Text, tree-sitter - all from single XtcLanguage.kt model
• Gradle plugin: Added --module, --method, --args options to runXtc task

Build Infrastructure

• includeBuildLang flag controls lang build inclusion (disabled by default for CI stability)
• Configuration cache compatible throughout
• ktlint added to lang Kotlin projects

Status: Alpha - This code is unsupported and under active development. APIs may change without notice.

Test plan

• Tree-sitter grammar parses 100% of XTC corpus (692 files)
• Native libraries build for all 5 platforms via Zig
• Build works with includeBuildLang=false (master compatibility)
• Configuration cache compatibility verified
• runIntellijPlugin depends on publishLocal for proper sandbox IDE testing

[ggleyzer]

I wonder if we could move the "lang" module into its own repo (e.g. "xtclang/lsp")? It seems that would make everything a bit cleaner...

[angelozerr]

It is super news for LSP4IJ !

When your plugin will be available please add it to the lsp4j readme https://github.com/redhat-developer/lsp4ij?tab=readme-ov-file#who-is-using-lsp4ij

And if you like LSP4IJ please add a review in Jetbrains marketplace to help us to promote LSP4IJ

Thanks!

[lagergren]

I wonder if we could move the "lang" module into its own repo (e.g. "xtclang/lsp")? It seems that would make everything a bit cleaner...

It is a composite build. There is virtually nothing outside the lang repo that were are referring to in any other place, except for the version catalog. I also heavily depend on project independent build logic, the javatools, and various other things that I access from lang but not in the other way around. I see no "cleaner" way to do it that would not inline both new and modified gradle work. I also want to be able to do stuff line run intellij on the current code base. It certainly not in the way for anyone, and if you don't even want to resolve the build against it, you can, just like manualTests, replace the attach and include flags in gradle.properties to ignore the gradle project. So I would very much like to get these changes in ASAP, without having to risk the rather complicated dependencies towards the rest of the XDK for now. The build structure for lang was very hard to get working, and I would appreciate it if we could work more incrementally with that. I need this code base to continue, and I am heavily relying on our common build logic for version control against what the XDK is built on. As fast as a I understand it, this seems to be best practice.

[cpurdy]

1. I like the changes to the README, particularly moving massive chunks into their own specific "read more" files. I was going to suggest something like this, so I'm glad to see you beat me to it.
2. I like the changes to the .gitignore file.
3. gradle.properties "TODO: LSP do not check in true/true here. Used for dev" -- can you verify that you actually want this in the commit?
4. DockerTest.x -- was this change intentional? (Trailing whitespace only.) The only thing that worries me if it wasn't intentional is that you let the reviewer (me) find this.
5. Initializer tool -- I have no issues with having support for tools, including Gradle/Maven, as long as developers using Ecstasy have zero required dependencies on those tools. My big concern here is that the Initializer stuff seems a bit brittle, but I guess we'll find out over time if that concern is real.
6. javatools-utils/build.gradle.kts -- I think I found where that trailing whitespace in DockerTest.x came from!
7. javatools-utils/README.md -- never mind, it probably came from here 🤣
8. Lazy/Suppiers -- These look fine, but were unnecessary as part of this overall change. I understand the desire to "upgrade" things as you go, and it's a good desire. It's something that we also try to do consistently. But work on building consensus in advance, though, i.e. involve others in the process up front. In this case, you replaced thread safe (via idempotency) code with thread safe (via a different mechanism) code. The upside of the change is unlikely to be realized in this particular change set, but I can see opportunities for benefits down the road, which is exactly why getting more buy-in (and thus awareness) is such an important part of the process! I would like you to do a walk through of this functionality on a team call to get others up to speed!
9. lang/README.md -- Very good overall. We try not to refer to "XTC" ... Ecstasy is the language name, and xtclang is also usable, referring to the "language project" I guess.
10. vscode extension -- Hard for me to provide much feedback. I've read through everything, but this is not my area of expertise. Again, I worry about some brittleness, but I also accept that tool integration is likely where we will be forced to deal with brittleness no matter how clever we are.
11. IntelliJ plugin -- Similar summary as for vscode, in that I am not an expert on the IDE integration, and I am worried about brittleness. But the README is well done and we're still in a learning phase, so I am comfortable with the content in that context.

Next up I plan to go through the LSP Server and DSL sub-projects. I've simply run out of hours today. Overall, this is a huge effort, and I am looking forward to seeing it in action!