I regret that %destructor and %printer give access to the %parse-param
in lalr1.cc, since that prevents them from being implemented as a
simple destructor and operator<<. Let's not repeat the mistake in
glr2.cc. In addition, fixes a name conflict we have currently in
tests 566 568 570 657:
calc.cc:1395:85: error: declaration shadows a field of 'calc::parser' [-Werror,-Wshadow]
void glr_state::destroy (char const* yymsg, calc::parser& yyparser, semantic_value *result, int *count, int *nerrs)
^
calc.hh:441:21: note: previous declaration is here
semantic_value *result;
^
With this commit, the whole test suite passes for glr2.cc.
* data/skeletons/glr2.cc (glr_state::destroy): Don't take the user
arguments.
Fixes several calc tests.
Tests 566 568 570 657 still fail because of a name clash when using
%parse-param:
calc.cc:1395:85: error: declaration shadows a field of 'calc::parser' [-Werror,-Wshadow]
void glr_state::destroy (char const* yymsg, calc::parser& yyparser, semantic_value *result, int *count, int *nerrs)
^
calc.hh:441:21: note: previous declaration is here
semantic_value *result;
^
* data/skeletons/glr2.cc: Fix indentation/trailing spaces.
In order to be able to link several glr2.cc parser together, we cannot
have glr_stack and glr_state be in no namespace. Putting them in the
unnamed namespace is not doable, since we need to fwd declare them in
the parser. Putting them in the specified namespace is not enough
either, since some users would like to be able to put several parsers
in the same name, only differing by the class name.
* data/skeletons/glr2.cc (glr_state, glr_stack): Move into yy::parser.
If we link several glr2.cc parsers together, we get linking failures
because of duplicate symbols.
* data/skeletons/glr2.cc (semantic_option::indexIn)
(semantic_option::next): Remove the useless overloads.
We don't need them in the header file.
* data/skeletons/glr2.cc (YY_EXCEPTIONS): Define only in the
implementation file.
* tests/headers.at (Several Parsers): Also check glr2.cc.
Let's use c++/glr to demonstrate custom error messages in C++ (not
just in glr2.cc).
* examples/c++/glr/c++-types.yy (report_syntax_error): New.
* examples/c++/glr/c++-types.test: Adjust.
* examples/c/bistromathic/parse.y: Comment changes.
* tests/local.at (AT_YYERROR_DEFINE(c++)): Use a nicer way to print
the lookakead's name.
Currently glr2.cc uses three variables/struct members to denote the
symbols' kind (or state), value and location. lalr1.cc has two types
for "complete" symbols: symbol_type and stack_symbol_type. Let's use
that model in glr2.cc too.
For a start use yyla (a symbol_type) to denote the lookahead, instead
of the triple yytoken, yylval and yylloc. This will make easier the
introduction of the "context" subclass, used in parse.error=custom.
It simplifies the code in several places. For instance from:
symbol_kind_type yytoken_current = this->yytoken;]b4_variant_if([[
value_type yylval_current;
]b4_symbol_variant([this->yytoken],
[yylval_current], [move], [this->yylval])], [[
value_type yylval_current = this->yylval;]])[]b4_locations_if([
location_type yylloc_current = this->yylloc;])[
to:
symbol_type yyla_current = std::move (this->yyla);
* data/skeletons/glr2.cc (yytoken, yylval, yylloc): Replace by...
(yyla): this.
Adjust all dependencies.
(yyloc_default): Remove, unused.
* tests/c++.at, tests/glr-regression.at, tests/types.at: C++11 is
required for glr2.cc.
Adjust to changes in glr2.cc.
* data/skeletons/c++.m4: Don't define obsolete identifiers in the case
of glr2.cc. Let's not start with technical debt.
* data/skeletons/glr2.cc, data/skeletons/lalr1.cc,
* data/skeletons/variant.hh: Use token_kind_type, not token_type.
* tests/c++.at, tests/local.at: Use value_type, not semantic_type.
It is not available on HP-UX 11i.
Reported by Larkin Nickle <me@larbob.org>.
<https://lists.gnu.org/r/bug-bison/2021-09/msg00012.html>
Gnulib provides no replacement, but anyway we should be using doubles,
since difftime uses doubles.
* bootstrap.conf: We want portability on stdtod.
* src/counterexample.c: Use double, not float, for time measurements.
The recent changes to comply with POSIX are breaking Automake's test
suite.
Reported by Kiyoshi Kanazawa.
<https://lists.gnu.org/r/bug-bison/2021-09/msg00005.html>
To limit the impact of POSIX changes, bind them to $POSIXLY_CORRECT.
Suggested by Karl Berry.
<https://lists.gnu.org/r/bug-bison/2021-09/msg00009.html>
The existing `maintainer-check-posix` Make target checks these
changes.
* src/getargs.h, src/getargs.c (set_yacc): New.
Use it.
* data/skeletons/bison.m4 (b4_posix_if): New.
* data/skeletons/yacc.c (b4_declare_yyerror_and_yylex): Use it.
* doc/bison.texi, tests/local.at: Adjust.
For some reason this test fails on Solaris/x86. But multistart is not
part of 3.8, so we can postpone the debugging of this issue.
Reported by Dagobert Michelsen.
<https://lists.gnu.org/r/bug-bison/2021-08/msg00027.html>
* tests/report.at (Multistart reports): Comment out.
Contrary to what commit d8cc6b073e "c++:
shorten the assertions that check whether tokens are correct"
believed, MS Visual C++'s preprocessor limitation is not on the input
line length, but on the size of the line holding the full C++
statement.
Reported by Vince Huffaker <vince@vincejulie.com>
<https://lists.gnu.org/r/help-bison/2021-08/msg00003.html>
* data/skeletons/variant.hh (_b4_symbol_constructor_define): Hide the
assertion from Visual C++.
On Solaris, sed throws away the NUL bytes from the stream, even in C
locale. So instead of postprocessing bison's stderr to neutralize
changes in value of `argv[0]`, use an envvar to actually neutralize
variations of `argv[0]` during tests.
Reported by Dagobert Michelsen.
<https://lists.gnu.org/r/bug-bison/2021-08/msg00025.html>
* src/main.c (main): Change `argv[0]` if BISON_PROGRAM_NAME is
defined.
* tests/bison.in: No longer mess with stderr, just pass
the expected BISON_PROGRAM_NAME value.
Besides, for mysterious reasons, this fails on some environment.
Reported by Dagobert Michelsen.
<https://lists.gnu.org/archive/html/bug-bison/2021-08/msg00008.html>
* examples/c/lexcalc/lexcalc.test, examples/c/lexcalc/parse.y,
* examples/c/lexcalc/scan.l: Revert to a single-start example.
Reported by Dagobert Michelsen.
https://lists.gnu.org/r/bug-bison/2021-08/msg00006.html
* m4/bison-cxx-std.m4 (_BISON_CXXSTD_98_snippet): We don't need
vector::data, it was only for glr2.cc, which is C++11 anyway.
(_BISON_CXXSTD_11_snippet): We need vector::data and std::swap on
arrays.
* m4/cxx.m4 (BISON_TEST_FOR_WORKING_CXX_COMPILER): We don't need
vector::data.
* tests/local.at (AT_COMPILE_CXX): Skip when glr2.cc and no support
for C++11.
In c2ba260487 ("glr.c: fix signature
when using custom error messages"), I meant to add a test case for C,
not C++. It does not work in C++.
* tests/calc.at: Run for glr.c, not glr.cc.
GCC 4.2 on macOS claims to support C++98, but does not feature it.
input.cc: In member function 'void state_stack::yycompressStack()':
input.cc:1774: error: 'class std::vector<glr_stack_item, std::allocator<glr_stack_item> >' has no member named 'data'
Reported by Christopher Nielsen <mascguy@github.com>.
<https://trac.macports.org/raw-attachment/ticket/59927/bison-test-results-20210811-95b72.log.xz>.
* m4/bison-cxx-std.m4 (_BISON_CXXSTD_98_snippet): Check for it.
* m4/cxx.m4 (BISON_TEST_FOR_WORKING_CXX_COMPILER): Ditto.
* tests/atlocal.in: It was an error for tests to depend on gnulib:
they must not, as gnulib would hide portability issues that we want to
catch. So this piece of code is no longer useful, and must not be
useful.
