[ANTRL Community] why don't you incorporate this project into the Antlr repository?

[MiottoNicola]

Good morning,
why don't you incorporate this project into the Antlr repository?
The Antlr Rust crate is a wonderful project, and I think it's important to expand this repository to include the Antlr community.

[tinovyatkin]

Thanks @MiottoNicola — that genuinely means a lot, and sorry for the slow reply.

On "why not incorporate it into the ANTLR repository" — it turns out that's mostly not how ANTLR does runtimes anymore, and independence is by design rather than a lesser status. Two things:

1. Independent per-runtime repos are the established model. ANTLR's own targets already live in their own repositories — e.g. antlr/antlr-php-runtime. And in the antlr4rust upstreaming discussion, Ken Domino (antlr4rust/antlr4#24) is candid that Terence Parr "has no appetite for adding more 'official' targets" to the monolithic antlr/antlr4 repo, because every target multiplies the release burden (one big jar, then build+release each runtime). So a standalone runtime isn't waiting outside the tent — standalone is the current shape of an ANTLR runtime. Because this repo is permissively licensed (BSD-3, same pattern as ANTLR's own runtimes), it's already usable as part of the community offering today — no incorporation step required to adopt it.

2. We built it for a specific performance target and want to keep iterating fast. This runtime came out of our mehen project, which needs to parse large enterprise-grade codebases quickly. We couldn't find an existing Rust runtime that hit the performance bar we needed, so we wrote one — and a lot of the value is in the freedom to iterate hard on efficiency (gen-time-compiled lexer DFAs, shared decision DFAs across parses, an owned parse tree, etc.). Keeping it in its own repo lets us move at that velocity rather than at the cadence of a monorepo release train.

None of that rules out closer collaboration with the broader ANTLR-Rust effort down the line — but for now, independent + permissively licensed + fast-moving is a feature, not a gap. Thanks again for the kind words and for opening the issue!

[MiottoNicola]

Thank you @tinovyatkin for your reply.
I understand your statements and the choices you have made.
I am using your crate in a personal Rust project, but I am having trouble with case-insensitivity; it does not seem to be recognized. Could it be that the Rust crate does not mirror the official ANTLR runtime?

[tinovyatkin]

Thanks @MiottoNicola — glad it's in use, and happy to dig in.

Quick data point from our side: the modern grammar option options { caseInsensitive = true; } does work here. ANTLR bakes the case handling into the serialized ATN at generation time, and our metadata-first runtime consumes that faithfully — I just confirmed a generated lexer tokenizes MATCH, match, and MaTcH to the same keyword token (no runtime case-folding needed on our end).

So it likely comes down to how your grammar expresses case-insensitivity. Two things worth checking:

1. Is caseInsensitive = true; actually set in the grammar's options { ... } (lexer or combined), and was the parser regenerated after adding it? The option only takes effect through a fresh antlr4 → antlr4-rust-gen run.
2. Does your grammar instead rely on the older runtime-side CaseChangingCharStream pattern (pre-4.10)? We don't currently provide an equivalent case-folding CharStream, so grammars written that way wouldn't get case-insensitivity from us — that would be a real gap on our side to track.

Could you open a new issue with a minimal repro — the relevant grammar snippet (the rule + its options), how you generate the parser, and a short input that's matched case-sensitively when you expect otherwise? With that I can tell quickly whether it's a usage fix or a genuine missing feature, and turn it around properly. Thanks for flagging it!