Yacc++ and the Language Objects Library

List of Known Problems and Workarounds in Software

Is there a list of known bugs in the table generators and library?

Is there a documentation corrections page?

I am getting a link error on the prog "Hello World!" installation test case. Any ideas?

You may be using a different C++ compiler or a different revision of the C++ compiler than we used to pre-compile the Language Objects Library. This can result in link errors due to binary incompatibilities.

I used the KEYWORD declaration in the lexer section of my grammar. When I build my application and give it a valid keyword as input, it gets a syntax error. Why is it not recognizing it?

Check for problems in your grammar. One common error is that you have not included a valid token definition in your lexer that does a symbol table lookup.

My application is getting the following assertion at runtime. What does this mean? What should I do?

Assertion failed: yy_psr_left_area <= yy_psr_left && 
                  yy_psr_left - yy_psr_left_area < yy_psr_left_max

How do I know if I have assertions enabled? What do they do?

If you set the define constant yy_assert_disable_ on your C++ compilation line, runtime assertions are disabled.

DEFINES= -Dyy_assert_disable_

To enable assertions, simply delete the explicit define on the compilations.

DEFINES= 

When there is a syntax error in the input in my application it always reports line number 0. Why am I not getting an accurate line number from calls to yy_err_report()?

Syntax errors are detected during the first pass over the input, the lexing and parsing pass. yy_err_report() displays the line number from the line number data member in the buffer object.

Check your lexer in your grammar. The lexer must increment the line number in the buffer object as it lexes newlines. When a syntax error occurs during lexing and parsing on the first pass, the line number in the buffer object will have the accurate value.

WHITE_SPACE  :   (" "             // space
             |    "\t"            // tab
             |    "\n"            // newline
                                  {  ++yy_buf_lineno();  }
                  )+
             ;

My application uses AST trees. I update the line number in the lexer on the first pass, but when a semantic error is detected on a subsequent pass while walking the AST tree, the last line number is always reported.

To access the correct line number during a second pass, the line number must be preserved in the leaves of the AST tree at the time of creation. At the time a semantic error is detected, access the appropriate line number from the AST tree. If you are calling yy_err_report() you will want to reset the line number in the buffer object from the AST line number before making the call.

Note that you may have a need for accurate line numbers for more than semantic error reporting. For example, if you are generating a cross-reference listing of symbols on a second pass.

Preserving Line Numbers in AST Trees

One way to preserve the line numbers is to add a line number member to your base AST class and fill in the line number in the base AST class constructor. This will preserve line number information in each leaf of your AST.

My grammar uses CONSTRUCT declarations for AST object creation. My application has some memory leaks for AST objects. What do I need to do? Why doesn't Yacc++ automatically take care of the deletion of the AST tree?

Yacc++ can't assume the parser stack entries are pointers. To provide upward compatibility with lex/yacc, the auxiliary data in Yacc++ might be a numeric value. We are considering adding an option that will enable you to tell Yacc++ that your application uses only AST pointers. Opinions?

In the meantime, follow these instructions to avoid memory leaks in your application when using AST's.

Lexer and Parser Destructors

If your application creates AST objects, you must take responsibility for the deletion of the AST tree in the destructors for the lexer and parser object.

Please see Tutorial AST in the Tutorial Guide for the code for recursive deletion.

REMOVE Declarations

If you are using a version of Yacc++ prior to revision 2.3, do not create AST objects for parser non-terminals that are declared REMOVE. This will cause a memory leak.

At Revision 2.3, Yacc++ now gives a warning for each parser non-terminal that appears in both a REMOVE and a CONSTRUCT declaration. The modifications in the next section will work for non-terminals that are declared either IGNORE and REMOVE, as both use the yy_psr_ign() function in the Language Objects Library.

IGNORE Declarations

Avoid creating AST objects for parser non-terminals that are declared IGNORE. This will cause a memory leak.

If you have an IGNORE parser non-terminal that is usually ignored, but in some specific context is explicitly defined and requires an AST, delete the AST for the ignore cases. You need to make the change to yy_psr_ign() in the Language Objects Library to delete the AST before it is ignored.

This change is only needed if your grammar has one or more parser non-terminals that are declared both IGNORE and CONSTRUCT.

This change is specifically for use with applications that have only AST objects as parser stack entries.

yy_psr_ign() in Revision 2.3

In Revision 2.3, ignore processing is provided by the yy_psr_ign() member function in yy_psrsk.h.

Change from:    --yy_psr_stack_rt_ix;

to:             delete (yy_ast_ptr(*yy_psr_stack_rt_ix));
                --yy_psr_stack_rt_ix;

There are 2 occurrences to change within yy_psr_ign().

yy_psr_ign() Before Revision 2.3

In Revision 2.2 and Revision 2.1, yy_psr_ign() is a macro for ignore processing. It is repeated in each of the parser classes by table type. Make the change to yy_psrfa.cpp, yy_psrsm.cpp, and yy_psrrd.cxx.

Change from:  #define yy_psr_ign() yy_psr_valid_rt_ix(); --yy_psr_rt;

to:           #define yy_psr_ign() yy_psr_valid_rt_ix(); \
              delete (yy_ast_ptr(*yy_psr_rt));\
              --yy_psr_rt;

CONSTRUCT Types PREFIX and INFIX

Delete the unused parser stack entries for PREFIX and INFIX in the AST constructor.

Syntax Errors

I'm getting "Error 200 : State xx has an action code conflict". What is this and how do I fix it?

Please read Tutorial SHIFT in the Tutorial Guide.

Action code counts as a lookahead just as if it were a symbol. If your grammar puts the parser generator in a position where it has to decide between two actions prematurely, it reports an action code conflict.

    grammar :  RED { cout << "I'm pink first"; }  BLUE   GREEN   ORANGE  PINK   YELLOW
            |  RED { cout << "I'm yellow first"; }  BLUE   GREEN   ORANGE  YELLOW   PINK
            ;

The parser generator doesn't know whether it needs to execute the first or second action until several symbols later when it sees PINK or YELLOW. To get rid of the conflict, move the action code. The later you can postpone the execution of the action code, the less lookahead is required to determine what action to execute. The following requires no lookahead.

    grammar :  RED  BLUE  GREEN  ORANGE  PINK  { cout << "I'm pink first"; }  YELLOW
            |  RED  BLUE  GREEN  ORANGE  YELLOW  { cout << "I'm yellow first"; }  PINK
            ;

I want to lex all identifiers using the same syntactic rule. I want to pass a more specific token type to the parser depending on what type it has in the symbol table, For example, a "float_identifier" or an "integer_identifier" instead of "identifier". What is the method in Yacc++ that I can use in the lexer to change a token's type before it is returned to the parser?

My application gets a parser stack assertion failure at runtime using Revision 2.3. What does this mean? Also, if I disable assertions, my application compiles its input and seems to work correctly.

Assertion failed: yy_false, file e:\yxx\inc.vc\yy_psrsk.h, line 1379

    case(yy_psr_stack_rt_empty_):
        assert(yy_psr_stack_rt_ix == 0);
        assert(yy_false);                 <------- Stopped here

This says there is an illegal reference on the parser stack, in this case an attempted reference to an empty stack. Look at the call stack in your debugger and locate the action code where the problem originates. In this particular case, the developer wrote parser action code that referenced the yy_lex_rdc() interface of the lexer object. (If you do not understand why this is illegal, please see Tutorial LEXCODE in the Tutorial Guide).