Hi — nice to see an LQL language server in Rust. A heads-up on one dependency, since the rest of lql-lsp-rust holds a strict lint bar (unsafe_code = "deny", pedantic) that this dep quietly undercuts.
crates/lql-parser (and lql-analyzer) depend on antlr-rust = "0.3.0-beta". That crate is rrevenantt/antlr4rust — last commit 2022, pinned to ANTLR 4.8, and it requires nightly Rust (its README warns about "nightly breakage"). So the LSP currently rides on an unmaintained, nightly-only runtime inside an otherwise stable, strict-lint workspace.
Two ways forward if you want off it:
- antlr4rust 0.5+ — the actively-maintained fork of that same runtime, now stable-Rust and ANTLR 4.13.2-aligned. Closest to a version bump, though the generated visitor/listener API changed.
- antlr-rust-runtime — a clean-room runtime I maintain: stable Rust, one runtime dependency (
thiserror), unsafe_code = "warn", passes the upstream ANTLR conformance descriptors, and heavily perf-profiled. Generation is metadata-first — you'd re-run the ANTLR tool on your existing Lql.g4 to emit .interp, generate Rust, and commit it (no JVM at cargo build).
Either gets you onto stable and off the 2022 crate. Both mean regenerating the parser and adapting the generated-API glue in lql-parser, so it's real work, not a swap — but for #2 I'm happy to open a PR that does the regen + wiring if it'd help. No pressure either way; mostly wanted the unmaintained/nightly dependency on your radar.
Hi — nice to see an LQL language server in Rust. A heads-up on one dependency, since the rest of
lql-lsp-rustholds a strict lint bar (unsafe_code = "deny", pedantic) that this dep quietly undercuts.crates/lql-parser(andlql-analyzer) depend onantlr-rust = "0.3.0-beta". That crate is rrevenantt/antlr4rust — last commit 2022, pinned to ANTLR 4.8, and it requires nightly Rust (its README warns about "nightly breakage"). So the LSP currently rides on an unmaintained, nightly-only runtime inside an otherwise stable, strict-lint workspace.Two ways forward if you want off it:
thiserror),unsafe_code = "warn", passes the upstream ANTLR conformance descriptors, and heavily perf-profiled. Generation is metadata-first — you'd re-run the ANTLR tool on your existingLql.g4to emit.interp, generate Rust, and commit it (no JVM atcargo build).Either gets you onto stable and off the 2022 crate. Both mean regenerating the parser and adapting the generated-API glue in
lql-parser, so it's real work, not a swap — but for #2 I'm happy to open a PR that does the regen + wiring if it'd help. No pressure either way; mostly wanted the unmaintained/nightly dependency on your radar.