Parsing Error: Chained method calls in assignment incorrectly split into multiple statements

[K1nG11]

Bug Description:

The Lua parser incorrectly parses chained method calls when they appear on the right-hand side (RHS) of an assignment statement. Instead of creating a single Abstract Syntax Tree (AST) node representing the entire chained call as the value of the assignment, the parser prematurely terminates the expression.

Specifically, for a statement like:
local result = hmac.setBlockSize(v.blockSize).setDigest(v.digest).setKey(v.key).init().update(v.message).finish().asHex();

The current parser behavior results in an AST where:

1. The LocalAssign node for result only receives hmac.setBlockSize (as an Index node) as its value.
2. The arguments for the initial call (e.g., (v.blockSize)) and all subsequent chained calls (e.g., .setDigest(v.digest)...) are detached and incorrectly parsed as a new, separate statement. This subsequent statement itself is often malformed, for instance, treating the arguments of the first call as the object for the second call in the chain.

This misparsing leads to an incorrect AST structure, and consequently, any code regenerated from this AST will be syntactically incorrect and different from the original source code. The root cause appears to be in the ANTLR grammar (LuaParser.g4) definitions for expressions (exp), prefix expressions (prefixexp), and function calls (functioncall), where the parser does not correctly prioritize or consume the full function call chain as a single expression unit within the explist of an assignment.

[AbigailBrady]

I independently found this bug today with just this example code

local where = get("x"):owner()

this parses to a LocalAssign and a Call at the top level, which should instead be a LocalAssign with an Invoke as the values arg.

bisection appears to indicate that this is a regression caused by the rework to the grammar or parser in October 2024. the revision 6ce8ba8 works as expected; several intermediate revisions throw on python symbol naming issues but then 2fdff3e shows the bug.

[AbigailBrady]

got another example which I thought I would mention because it involves calling the return value of a function, which neither K1ngG11's sample or mine did.

   ttl = stat.display_attr("title")(plr)

this parses as an Assign and a Call at the top level, as if it were

   ttl = stat.display_attr
   "title"(plr)

this was introduced in the same changes as i noted in my first comment.