Low priority, work around is not reusing the table reader.

Found while using org.spoofax.jsglr2.parsetable.ParseTableReader in a primitive for Stratego so we can use JSGLR2 in strj. While packing a stratego file, it would read a Stratego parse table, parse, implode, follow the imports, find a Stratego file with mix syntax, read another parse table, which would be faulty, then fail (either wrong parse or ClassCastException if you build the whole parse forest).

Submitted by Jeff Smits on 17 June 2018 at 12:18

On 19 June 2018 at 11:49 Jasper Denkers commented:

This was due to a caching issue while constructing parse tables. When constructing the first parse table, a cache of actions is built. The cache then contains reduce actions that have a production field. Equality on productions was defined by id comparison. However, the second parse table has overlapping ids for productions and thus erroneous reuses cached reduce actions from the first. Fixed by defining equality on productions based on content, not id, as in https://github.com/metaborg/jsglr/commit/87bc75129104c0e21c834172c896a357810ca73d.

Log in to post comments