bison (GNU Bison) 2.7.1 flex 2.5.37
This has been filed in [email protected] as a question. On reflection, I think it is a bug. The rationale is that flex generates code which requires direct visibility to YYSTYPE. The bison generated code does two things: 1: If a %union is specified then YYSTYPE is undefined (see code fragment below), and 2: YYSTYPE is 'hidden' within a class definition which is incompatible with flex integration. Most particularly, if the flex option %option bison-bridge is used and YY_DECL is not defined, then the following code is generated (using %option prefix="Slip"): extern int Sliplex \ (YYSTYPE * yylval_param ); which makes Sliplex available to yyparse but requires direct visibility to YYSTYPE. My though is that the actual code generated by bison should be in the file/global scope of y.tab.hpp and not located in a class and that YYSTYPE should always be generated. As seen in the example below, it is not always generated. In y.tab.hpp the definition of YYSTYPE is placed in the class parser as follows: In the parser input file Slip.y the following appears: %file-prefix "Slip.bison" %language "C++" %name-prefix "Slip" %output "Slip.Bison.cpp" %union { int everything; } Which causes the generation of (without #lines) is: namespace Slip { /// A Bison parser. class parser { public: /// Symbol semantic values. #ifndef YYSTYPE union semantic_type { int everything; }; #else typedef YYSTYPE semantic_type; #endif
