[jira] [Created] (GROOVY-12173) Left-factor parser rules to reduce lookahead on hot parse paths

["Daniel Sun (Jira)" <ji...@apache.org>]

Daniel Sun created GROOVY-12173:
-----------------------------------

             Summary: Left-factor parser rules to reduce lookahead on hot parse paths
                 Key: GROOVY-12173
                 URL: https://issues.apache.org/jira/browse/GROOVY-12173
             Project: Groovy
          Issue Type: Improvement
            Reporter: Daniel Sun


h3. Motivation

Successful parse cost in the ANTLR4 (Parrot) parser is dominated by adaptive prediction. Several grammar rules still force the simulator to explore *sibling alternatives that share a long common prefix*, or to re-run an expensive semantic predicate that was already evaluated. That inflates DFA growth and SLL work even when the input is valid.

This improvement left-factors and simplifies a small set of non-left-recursive rules so decisions commit earlier, *without* changing language semantics or the AST shapes {{AstBuilder}} relies on.

h3. Changes

*1. {{importDeclaration}} — left-factor {{annotationsOpt IMPORT}}*
** Before: two alternatives both started with {{annotationsOpt IMPORT}}, so prediction replayed the shared prefix to choose module vs ordinary import.
** After: one {{IMPORT}}, then {{MODULE qualifiedName}} vs {{STATIC? qualifiedName ...}}. Decision is effectively one token after {{IMPORT}}.

*2. {{typeNamePairs}} — left-factor {{LPAREN}} / {{RPAREN}}*
** Before: two alternatives both wrapped the list in parentheses (positional multi-assign vs GEP-20 keyed pairs).
** After: open paren once; choose {{typeNamePair}} vs {{keyedPair}} (keyed form distinguished by {{COLON}}).

*3. {{pathElement}} — left-factor {{DOT}}*
** Before: {{DOT nls NEW creator}} and {{DOT nls namePart}} were separate alternatives, both starting with {{DOT}}, so every property access paid for exploring both.
** After: {{DOT nls}} then {{NEW creator}} vs name selection. After {{DOT}}, {{NEW}} is LL(1). Non-DOT selectors ({{?.}}, {{*.}}, {{??.}}, {{.&}}, {{::}}) stay separate.

*4. {{blockStatement}} — drop redundant local-variable alternative*
** Before:
{noformat}
blockStatement
    : localVariableDeclaration
    | statement
    ;
{noformat}
** {{statement}} already includes {{localVariableDeclaration}} ({{#localVariableDeclarationStmtAlt}}). Inside a block, command-style calls such as {{foo bar}} therefore evaluated {{isInvalidLocalVariableDeclaration}} *twice* (fail on the first alt, fail again via {{statement}}).
** After: {{blockStatement : statement}} only. Observationally equivalent; halves predicate traffic on that path.
** {{AstBuilder#visitBlockStatement}} updated to visit {{statement}} only.

h3. Non-goals / deliberate non-changes

* Do *not* left-factor the three {{#relationalExprAlt}} alternatives under left-recursive {{expression}} into one subrule group. ANTLR's left-recursion rewriter only preserves operator precedence for direct {{expression OP expression}} forms; factoring the operator into a parenthesised group lets {{right=expression}} accept lower-precedence ops (e.g. {{&&}}), so {{x >= min && x <= max}} can parse as {{x >= (min && ...)}} and break type checking.
* Index vs named property args ({{indexPropertyArgs}} / {{namedPropertyArgs}}) still share {{SAFE_INDEX|LBRACK}}; merging them would reshape the CST and force a larger {{AstBuilder}} change for limited gain — left for a follow-up if measured.

h3. Compatibility

* Language surface and AST construction paths are unchanged for correct programs.
* No public API additions.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)