The goal of implementing a "try-first-fallback" logic, often referred to as ordered choice, is a common requirement when transitioning from PEG parsers to LALR(1) parsers like LALRPOP. However, LALRPOP relies on a Look-Ahead LR(1) automaton. It determines the action to take (shifting a token or reducing a rule) based strictly on the current parser state and the next available token. It does not support backtracking to try alternative productions if the first one leads to a dead end later on. When multiple rules are valid for the same state and lookahead token, the compiler reports a shift/reduce or reduce/reduce conflict.

Using Inlining to Reduce States

One of the most effective ways to resolve these conflicts is to flatten the grammar structure using the #[inline] attribute. When a non-terminal is inlined, the parser generator expands its definition directly into the calling rule. This reduces the number of states in the parsing table and often eliminates the ambiguity.

For example, if you have a wrapper rule causing conflicts:

#[inline]
PathWrapper: Vec<String> = {
    PathSegmentList
};

Disambiguating via Lookahead Tokens

To manually enforce priority or distinction between conflicting rules, you can refactor the grammar to explicitly require specific lookahead tokens. This involves creating an intermediate rule that consumes the distinguishing token.

Consider a conflict where a division operation looks similar to a member access because they share a common prefix:

Expression: Box<Expr> = {
    <l:Value> "/" <r:Path> => Box::new(Expr::Divide(l, r)),
    <p:Path> "." <m:Identifier> => Box::new(Expr::MemberAccess(p, m)),
};

To fix this, you can create a specific rule for the path followed by a dot, forcing the parser to commit to that path only when the dot is guaranteed:

Expression: Box<Expr> = {
    <l:Value> "/" <r:Path> => Box::new(Expr::Divide(l, r)),
    <d:DottedPath> <m:Identifier> => Box::new(Expr::MemberAccess(d.path, m)),
};

DottedPath: Dotted = {
    <p:Path> "." => Dotted { path: p },
};

Separating Production Rules by Priority

Another strategy involves isolating high-priority or complex rules into their own non-terminals. By creating a hierarchy, you can guide the parser into specific states that match the intended logic first.

Statement: Stmt = {
    ControlFlow,
    Assignment
};

ControlFlow: Stmt = {
    "if" <c:Expression> "then" <b:Block> => Stmt::IfThen(c, b),
};

Assignment: Stmt = {
    <v:Identifier> "=" <e:Expression> => Stmt::Assign(v, e),
};

It is important to understand that LALRPOP cannot inherently "try the first rule and fallback to the next." The order of rules in the grammar file does not imply priority in the parsing automaton. Conflicts must be resolved by restructuring the grammar sothat the parser can distinguish between alternatives using the available lookahead information.