Quick way to access 'terminal rule'?

[HPCguy]

Hi,

I have a chain of rules that I don't want to 'follow' to get to the 'terminal rule'. Is there a method to return the terminal rule?

For example, I don't want to follow this chain, checking for Nil rules at every step along the way:

ctx -> expression() -> conditionalExpression() -> logicalOrExpression() -> logicalAndExpression() -> equalityExpression() -> relationalExpression() -> additiveExpression() -> multiplicativeExpression() -> exponentExpression() -> unaryExpression() -> functionExpression().

I would rather have: ctx.getTerminalRule() that returns the context of the ultimate rule that is actually matched, in this case, functionExpression.

BTW My use case is an attempt to optimize an expressionStatement. I want to discard any expressionStatements that do not have side effects. Based on the way I've defined my language, only assignmentExpressions and functionExpressions can have side effects. The rule for assignmentExpression is 'close' to my rule for expressionStatement in my grammar, but I don't want to have to 'dive' to check for functionExpression.

In code, my check and discard action would look something like this:

def exitExpressionStatement(self, ctx:MyParser.ExpressionStatementContext):
actualRule = ctx.getTerminalRule().getRuleIndex()
if not (actualRule == MyParser.RULE_assignmentExpression or
actualRule == MyParser.RULE_functionExpression):
ParseTreeRemove(ctx)

Thanks.

[KvanTTT]

You can access the first and the last terminal rules (actually tokens) by using start and end fields respectively. Anyway, you can use caching if you need to access terminal rules multiple times.

[HPCguy]

Thanks for responding.

Unfortunately, tokens don't give me enough context for which rule was the one actually matched, at least not without a lot of work, as far as I know.

There is a very specific token pattern somewhere between 'start' and 'end' within a span of 'k' lookahead which contains the specific token(s) that caused the 'terminal rule' to be matched. There can be a load of lexer tokens near the 'end' token (e.g. an integer list) that really are irrelevant and 'deeper' than the ' fundamental matching tokens' that actually trigger/appear in the 'terminal rule' that the parser selects.

My gripe is that the parser knows exactly where the 'matching terminal rule' is, whereas for me, digging through the parse tree is potentially a major amount of work to find that rule. When I have dozens of such patterns to match with complex criteria, it seems like it shouldn't be that hard, especially given that the parser can just hand me the getTerminalRule() that is 'obvious' to the parser.