False positive shift-shift conflicts, is this a bug?

[glyh]

Can anyone help me spot what is wrong in this description?

  processing file `/home/lyh/Documents/CS/hmc/hermicrab/src/grammar.lalrpop`
  /home/lyh/Documents/CS/hmc/hermicrab/src/grammar.lalrpop:194:24: 194:48: Local ambiguity detected

    The problem arises after having observed the following symbols in the input:
      "word" "(" Expression ","
    At that point, if the next token is a `")"`, then the parser can proceed in two different ways.

    First, the parser could execute the production at
    /home/lyh/Documents/CS/hmc/hermicrab/src/grammar.lalrpop:194:24: 194:48, which would consume
    the top 2 token(s) from the stack and produce a `(<Expression> "," "NL"*)+`. This might then
    yield a parse tree like
      "(" Expression                "," ")"
      │   └─(<Expression> "," "NL"*)+─┘   │
      └─TypedArgsNoNLWith<")">────────────┘

    Alternatively, the parser could shift the `")"` token and later use it to construct a
    `TypedArgsNoNLWith<")">`. This might then yield a parse tree like
      "word" "("   Expression  ","  ")"
      │      ├─TypedArgsNoNLWith<")">─┤
      │      ├─TypedArgsNoNLNormal────┤
      │      └─TypedArgsNoNL──────────┤
      └─CommandCallNoNL───────────────┘

    See the LALRPOP manual for advice on making your grammar LR(1).

[yannham]

It's very hard to tell without seeing the grammar. However, it seems to be related to NL*, which seems is ambiguous when there is zero repetition. Maybe you'll have to make your rule non ambiguous by having a case NL+ and a case without NL. Here it looks like the two cases intersect (no NL and NL*)

[glyh]

Thanks a lot!