I grabbed the TypeScript and converted that directly to C++ so it's a very faithful translation of the original TypeScript. This'll make it easy to maintain and keep in-sync.
Two concerns:
1) In the antlr TS runtime, RuleStartState has a property isPrecedenceRule and in the C++ runtime there is not. Inspecting what the value of that property is though, it appears to me to be identical at all times to C++'s isLeftRecursiveRule so this code is currently just using that to get the right value. See lines 574 and 739. I'm not familiar enough with ANTLR's internals to understand what the indended difference is between those, so some guidance on that is needed.
2) It's working as expected in my testing, but I didn't spend time on understanding the TS unit tests and replicating those.
Lastly, I have made one addition which is also in this PR which is to add the ability for an external caller to cancel collecting candidates, and the collection to time itself out if it's taking too long. Both are opt-in and just short circuit to returning the incomplete candidate results. This is a pretty trivial addition in complexity (it's not aiming to be perfectly immediate), but useful in practice where the results are no longer needed (say because the user's input text has changed already and the results will therefore be stale).
I grabbed the TypeScript and converted that directly to C++ so it's a very faithful translation of the original TypeScript. This'll make it easy to maintain and keep in-sync.
Two concerns:
1) In the antlr TS runtime,
RuleStartState
has a propertyisPrecedenceRule
and in the C++ runtime there is not. Inspecting what the value of that property is though, it appears to me to be identical at all times to C++'sisLeftRecursiveRule
so this code is currently just using that to get the right value. See lines 574 and 739. I'm not familiar enough with ANTLR's internals to understand what the indended difference is between those, so some guidance on that is needed.2) It's working as expected in my testing, but I didn't spend time on understanding the TS unit tests and replicating those.
Lastly, I have made one addition which is also in this PR which is to add the ability for an external caller to cancel collecting candidates, and the collection to time itself out if it's taking too long. Both are opt-in and just short circuit to returning the incomplete candidate results. This is a pretty trivial addition in complexity (it's not aiming to be perfectly immediate), but useful in practice where the results are no longer needed (say because the user's input text has changed already and the results will therefore be stale).