The problem is very simple, when seeing:

f(

in a statement context, the parser does not know with bounded lookahead whether it will see a mere function call, or an assignment of the form:

f(1,2,3) = 42;

The latter is obviously not allowed by the language, but currently this restriction is only enforced at the type level instead of the syntax level. I propose adding these restrictions to the syntax to spare the parser from pointless backtracking:

assignment_statement :
    | ( lhs_expression | underscore ) equal short_circuit_or_expression
lhs_expression :
    | ( star | and ) * core_lhs_expression postfix_expression ?
core_lhs_expression :
    | ident
    | paren_left lhs_expression paren_right

Instead of the current approach where practically any expression can be on the left-hand side of an assignment.

I looked at all type rules that allow the creation of memory references (required for the left-hand side of an assignment), and I believe that I have captured all possible such expressions. I tried to verify it by checking that all of our examples still parse with the new grammar.

This allows removing one of the 3 known conflicts in the grammar today which prevent it from being LR(1). I hope to fix the other two in separate PRs.