Lane Table not quite correct?

[modulovalue]

Hi @nikomatsakis (and other maintainers)

I wanted to ask about a weird observation that both, yours and Xin Chen's interpretation of Pager's lane table approach appear to exhibit.

Consider your explanation here:

It says that for the second example, the lane table would look like this:

| State | C0    | C1    | C2    | Successors |
| S1    |       | ["d"] | ["c"] | {S3}       |
| S2    |       | ["c"] | ["d"] | {S3}       |
| S3    | ["e"] | []    | []    | {S3}       |

However, shouldn't it be:

| State | C0    | C1         | C2         | Successors |
| S1    |       | ["d"]      | ["c"]      | {S3}       |
| S2    |       | ["c"]      | ["d"]      | {S3}       |
| S3    | ["e"] | ["c", "d"] | ["c", "d"] | {S3}       |

because if we trace back on S3 via an "e" back to S3, and then move forward in the automaton by an X (or Y), we will end up in a successor state of S3 which will introduce a "c" and "d" lookahead.

on grammophone

And if we look at it from the DeRemer and Pennello relations based approach for calculating LALR lookaheads, we will notice that there's a lookback relation for each of the conflicting reductions in S3 to a successor state, which introduces "c" and "d" lookaheads as I've pointed out above.

This appears not to be an issue because the missing lookaheads depend on those that already exist in the table. So things kind of work out? But still, I'm wondering whether this is a critical bug that makes the algorithm not quite correct.

[Pat-Lafon]

At a quick glance, is this related to #768?

[Pat-Lafon]

Ah whoops, I see you just commented on that issue. Race-conditions...