yylval
and yylloc
are set in the lexer, not in the parser. Traditionally, these are global variables, but in a "pure" (re-entrant) parser, they are internal to the parser, and their addresses are passed to the scanner as arguments. C++ parsers are always pure.
Since 3.0, these values are no longer independent variables in the parser; rather, they are part of a class representing a symbol. That change doesn't affect the scanner, since it still receives the same pointers as arguments, but it makes the values inaccessible by name to parser actions.
Clearly, that incompatibility should be documented somewhere, but I haven't found where.
Nonetheless, it's worth noting that you rarely need to refer to the semantic value and location of the lookahead token in a parser action, although doing so has been supported since time immemorial and continues to work in C parsers, and even in GLR parsers. I'm sure you have your reasons, and while I'm curious as to what they are, you are under no obligation to reveal them. Examination of the C++ skeleton code suggests that you should be able to use yyla.value
and yyla.location
instead of yylval
and yylloc
, but that's not documented so there are no guarantees.
If we're lucky, Akim Demaille will come by and answer this question properly. Personally, I use the C interface, even with C++; old habits die hard.