[BUG] The parser's rules for a functioncall are too loose

[9382]

The parser involved with the Vmify step does not parse the same way as original lua does, leading to cases where incorrect code can be compiled

Take the following code:

local a = 1
(function()
	print("hey")
end)();

Under regular lua, a will be assigned to 1 and the anonymous function would then be ran. Under the parser used here, the function is incorrectly considered as being a call argument to the constant 1
This can be proven by asking for local a = 1() to be obfuscated. This should produce an error (the valid code would be (1)()), but instead prometheus successfully runs without any complaints

Per the Lua 5.1 EBNF, these are the conditions for a function call:

• functioncall ::= prefixexp args | prefixexp ':' Name args
• prefixexp ::= var | functioncall | '(' exp ')'

The constant 1 by itself doesn't meet this condition (it would need to be (1)), and as such shouldn't be parsed as a function call

Interestingly, the case of local a = {}() is already correctly handled, and will produce a parser error just like regular lua would, so I'm not immediately sure as to what the issue could be

Extra note: There should probably be either a warning print or outright error in this case (e.g. Lua 5.1 will error with the message ambiguous syntax (function call x new statement) near '(' when it runs into a call expression that crosses multiple lines in an ambiguous way, e.g. local a = (1)\n(b or c)();), since I was initially misled into thinking this was a Vmify issue

[voidsaken-script]

congratulations on being the first ever valuable post/message related to prometheus