GeezerVison

For a + b + c, the parser first finds a, then calls the rule again to get a + b, then again to get (a + b) + c. It puts each partial result in the parse cache so the next call can pick it up. That works, but it adds rule calls, cache lookups and cache updates to something that is really just a loop.

This adds an (operator_loop) flag to the six arithmetic and bitwise rules. The generated code parses a, keeps the current expression in a local variable, and loops over + b and + c. Each step builds the next AST node directly. It only puts the finished expression in the cache, so all that bookkeeping between steps goes away.

This also helps when there is no operator. Even a plain name passes through these rules, and the general parser still has to check whether it can grow the expression. The loop can just see that the next token isn't an operator and return.

The grammar and AST actions stay the same apart from the flag, and the existing error rules are still there.

The table compares parsing with and without these loops. Both builds include pending changes that reduce allocations, skip grammar choices using the next token, make stack checks and cache updates cheaper, and handle simple one-token expressions directly.

The timings include tokenization, building the AST and cleanup, without compiling bytecode or running the files.

• Issue: Speed up the parser #153568