explain why NOT is missing from generated parser

[James K. Lowden]

Hi, 

I'm writing a parser for Cobol.  If you know Cobol, you know that's a
mouthful. Cobol predates BNF, and sometimes it shows.

Parser: 

https://git.symas.net/cobolworx/gcc-cobol/gcc/cobol/parse.y

Documentation of the verb: 

https://www.ibm.com/docs/en/cobol-zos/6.2?topic=statements-unstring-statement

At the moment, I'm Just Confused.  I have two verbs, STRING and
UNSTRING, with similar syntax.  Yet STRING is parsing correctly, and
UNSTRING not.

Both statements accept an OVERFLOW (and NOT OVERFLOW) phrase:

  913 on_overflow: on_overflow1 statements

  915 on_overflow: on_overflow1 statements $@37 on_overflow1 statements

  916 on_overflow1: OVERFLOW
  917             | NOT OVERFLOW

Yet, when we get to the "on_overflow" nonterminal, only STRING
recognizes NOT.  

How do I diagnose why bison is "ignoring" the NOT in when evaluating
on_overflow1 for UNSTRING? 

The following comes from the bison report output; the "?" represents the
bullet that indicates where the parser is. 

State 1138

  894 string: STRING_kw str_delimiteds str_into ? on_overflow end_string
  895       | STRING_kw str_delimiteds str_into ?
  896       | STRING_kw str_delimiteds str_into ? END_STRING

    NOT         shift, and go to state 1382
    END_STRING  shift, and go to state 1383
    OVERFLOW    shift, and go to state 1384

    $default  reduce using rule 895 (string)


State 1528

918 unstring: UNSTRING scalar uns_delimited INTO uns_into ?
                        on_overflow end_unstring 
919         | UNSTRING scalar uns_delimited INTO uns_into ? 
920         | UNSTRING scalar uns_delimited INTO uns_into ? END_UNSTRING

    END_UNSTRING  shift, and go to state 1641
    OVERFLOW      shift, and go to state 1384

    $default  reduce using rule 919 (unstring)

The grammar so far has 1000 rules, and I still feel like an amateur.  I
know the tool is deterministic, but sometimes what seem like minor
changes make it go from working to nonworking, and vice-versa.  

In this particular case, I intentionally made the the two rules as
similar as possible.  I'm guessing the precedence of "NOT" is the
culprit: that when we get to 

        uns_into * on_overflow

there's a terminal in uns_into that causes the NOT in on_overflow to
be ... something.  But every form of uns_into ends in "scalar" (a
variable), so my theory doesn't explain anything.  

What should my strategy be to analyze why bison is producing the parser
it is, instead of the parser I want?  

Many thanks, 

--jkl