Re: incorrect yychar for unambiguous GLR

[Joel E. Denny]

On Wed, 11 Jan 2006, Joel E. Denny wrote:

> On Tue, 10 Jan 2006, Joel E. Denny wrote:
> 
> > On Tue, 10 Jan 2006, Paul Hilfinger wrote:
> > 
> > > As things stand, this organization will slightly expand the size of a
> > > yyGLRStackItem in some cases.  How about the following definition of 
> > > yySemanticOption instead?
> > > 
> > >     struct yySemanticOption {
> > >       /** Type tag: always false. */
> > >       yybool yyisState;
> > >       /** The lookahead symbol for this reduction.  */
> > >       short yyrawchar;
> > >       /** Semantic value of the lookahead for this reduction. */
> > >       YYSTYPE yyval;
> > >       /** Location of the lookahead for this reduction. */
> > >       YYLTYPE yyloc;
> > >       /** The last RHS state in the list of states to be reduced. */
> > >       yyGLRState* yystate;
> > >       /** Next sibling in chain of options. To facilitate merging,
> > >        *  options are chained in decreasing order by address. */
> > >       yySemanticOption* yynext;
> > >     };
> > 
> > That makes sense.  I suppose yyrule can go after yyloc.
> 
> Would you like to commit this as well?

I just noticed that this changes yyrawchar from int to short.  I'm not 
smart enough to know if this matters.

Joel