Re: glr2.cc: add an example

> Le 11 nov. 2020 à 19:03, Valentin Tolmer <[email protected]> a écrit :
> 
> Hi Akim,

Hi Valentin!

> Thanks for the example, and sorry for the late reply, got swamped with work and the bug was less than easy to track... I had the pleasure of discovering the joys of `rr` for a time-traveling GDB, but I would have hoped it wouldn't come to that.

Never had to use it so far...

> Anyway, I pushed a patch to the glr2_cc branch on my github if you want to have a look (https://github.com/nitnelave/bison/tree/glr2_cc). It was a combination of a memory corruption when accessing the wrong field of an union, and a badly translated loop from glr.c.

I'm afraid there is probably more.  I removed the exit 77 from the test itself, and the test suite still fails.

On "T (x) + y;" it aborts in getState :

frame #3: 0x0000000100001f6d c++-types`glr_stack_item::getState(this=0x0000000101000190) at c++-types.cc:1099:5
   1096	
   1097	  glr_state& getState ()
   1098	  {
-> 1099	    YYDASSERT (is_state ());
   1100	    void *yyp = raw_;
   1101	    return *static_cast<glr_state*> (yyp);
   1102	  }

And on "T (x);", it does not terminate.

I have installed none of your other commits, to make sure we don't add more problems on top of this one.  But I read them, and LGTM, so I doubt they actually make things worse.  Besides, we have the very same failures without these commits.

I'm not fond of the "glr2.cc: remove goto from yytnamerr_" commit (https://github.com/nitnelave/bison/commit/a65094511f8e2a6b51493b64fbb93db3220a47d9): I think it is much more complex than the original approach, and now too different from the approach taken in the other skeletons.  I agree gotos should be avoided, but they are valid in the implementation of state machine, which is what this function is about.

Cheers!