Currently our error messages include both "symbol redeclared" and
"symbol redefined", and they mean something different. This is
obscure, let's make this clearer.
I think the idea between 'definition' vs. 'declaration' is that in the
case of the nonterminals, the actual definition is its set of rules,
so %nterm would be about declaration. The case of %token is less
clear.
* src/symtab.c (complain_class_redefined): New.
(symbol_class_set): Use it.
Simplify the logic of this function to clearly skip its body when the
preconditions are not met.
* tests/input.at (Symbol class redefinition): New.
* examples/java/Calc.y: New, based on test 495: "Calculator
parse.error=verbose %locations".
* examples/java/Calc.test, examples/java/local.mk: New.
* configure.ac (ENABLE_JAVA): New.
* examples/test (prog): Be ready to run Java programs.
Reported by Rici Lake.
http://lists.gnu.org/archive/html/bug-bison/2018-10/msg00000.html
* src/complain.h: Formatting change.
* src/parse-gram.y (id): Reject character literals used in a context
for non-terminals.
* tests/input.at (Invalid %nterm uses): Check that.
Reported by Uxio Prego.
https://lists.gnu.org/archive/html/help-bison/2018-11/msg00031.html
We also need to move the unreachable 'goto' to a reachable place,
otherwise clang complains about the code being unreachable anyway.
See also https://bugs.llvm.org/show_bug.cgi?id=39736.
Interestingly, we don't have to apply that trick to
`#define YYCDEBUG if (false) std::cerr`, clang does not warn when the
code comes from macro expansion.
* configure.ac: Use -Wunreachable-code when supported.
* data/lalr1.cc, data/yacc.c: Pacify clang's warning about `if (0)`
by using a macro.
Another possibility was to move this statement to a reachable place.
* tests/actions.at, tests/c++.at: Avoid generating unreachable code.
Currently on a grammar such as
exp : a '1' | a '2' | a '3' | b '1' | b '2' | b '3'
a:
b:
we count only one rr-conflict on the `b:` rule, i.e., we expect:
b: %expect-rr 1
although there are 3 conflicts in total. That's because in the
conflicted state we count only a single conflict, not three (one for
each of the lookaheads: '1', '2', '3').
State 0
0 $accept: . exp $end
1 exp: . a '1'
2 | . a '2'
3 | . a '3'
4 | . b '1'
5 | . b '2'
6 | . b '3'
7 a: . %empty ['1', '2', '3']
8 b: . %empty ['1', '2', '3']
'1' reduce using rule 7 (a)
'1' [reduce using rule 8 (b)]
'2' reduce using rule 7 (a)
'2' [reduce using rule 8 (b)]
'3' reduce using rule 7 (a)
'3' [reduce using rule 8 (b)]
$default reduce using rule 7 (a)
exp go to state 1
a go to state 2
b go to state 3
See https://lists.gnu.org/archive/html/bison-patches/2013-02/msg00106.html.
* src/conflicts.c (rule_has_state_rr_conflicts): Rename as...
(count_rule_state_sr_conflicts): this.
DWIM.
(count_rule_rr_conflicts): Adjust.
* tests/conflicts.at (%expect-rr in grammar rules)
(%expect-rr too much in grammar rules)
(%expect-rr not enough in grammar rules): New.
On a grammar such as
exp: "num" | "num" | "num"
we currently report only one RR conflict, instead of two.
This bug is present since the origins of Bison
commit 08089d5d35
Author: David MacKenzie <djm@djmnet.org>
Date: Tue Apr 20 05:42:52 1993 +0000
Initial revision
and was preserved in
commit 676385e29c
Author: Paul Hilfinger <Hilfinger@CS.Berkeley.EDU>
Date: Fri Jun 28 02:26:44 2002 +0000
Initial check-in introducing experimental GLR parsing. See entry in
ChangeLog dated 2002-06-27 from Paul Hilfinger for details.
See
https://lists.gnu.org/archive/html/bison-patches/2018-11/msg00011.html
* src/conflicts.h, src/conflicts.c (count_state_rr_conflicts)
(count_rr_conflicts): Use only the correct count of conflicts.
* tests/glr-regression.at: Fix expectations.
Currently on a grammar such as
exp: "number" | exp "+" exp | exp "*" exp
we count only one sr-conflict for both binary rules, i.e., we expect:
exp: "number" | exp "+" exp %expect 1 | exp "*" exp %expect 1
although there are 4 conflicts in total. That's because in the states
in conflict, for instance that for the "+" rule:
State 6
2 exp: exp . "+" exp
2 | exp "+" exp . [$end, "+", "*"]
3 | exp . "*" exp
"+" shift, and go to state 4
"*" shift, and go to state 5
"+" [reduce using rule 2 (exp)]
"*" [reduce using rule 2 (exp)]
$default reduce using rule 2 (exp)
we count only a single conflict, although there are two (one on "+"
and another with "*").
See https://lists.gnu.org/archive/html/bison-patches/2013-02/msg00106.html.
* src/conflicts.c (rule_has_state_sr_conflicts): Rename as...
(count_rule_state_sr_conflicts): this.
DWIM.
(count_rule_sr_conflicts): Adjust.
* tests/conflicts.at (%expect in grammar rules): New.
This change allows one to document (and check) which rules participate
in shift/reduce and reduce/reduce conflicts. This is particularly
important GLR parsers, where conflicts are a normal occurrence. For
example,
%glr-parser
%expect 1
%%
...
argument_list:
arguments %expect 1
| arguments ','
| %empty
;
arguments:
expression
| argument_list ',' expression
;
...
Looking at the output from -v, one can see that the shift-reduce
conflict here is due to the fact that the parser does not know whether
to reduce arguments to argument_list until it sees the token AFTER the
following ','. By marking the rule with %expect 1 (because there is a
conflict in one state), we document the source of the 1 overall shift-
reduce conflict.
In GLR parsers, we can use %expect-rr in a rule for reduce/reduce
conflicts. In this case, we mark each of the conflicting rules. For
example,
%glr-parser
%expect-rr 1
%%
stmt:
target_list '=' expr ';'
| expr_list ';'
;
target_list:
target
| target ',' target_list
;
target:
ID %expect-rr 1
;
expr_list:
expr
| expr ',' expr_list
;
expr:
ID %expect-rr 1
| ...
;
In a statement such as
x, y = 3, 4;
the parser must reduce x to a target or an expr, but does not know
which until it sees the '='. So we notate the two possible reductions
to indicate that each conflicts in one rule.
See https://lists.gnu.org/archive/html/bison-patches/2013-02/msg00105.html.
* doc/bison.texi (Suppressing Conflict Warnings): Document %expect,
%expect-rr in grammar rules.
* src/conflicts.c (count_state_rr_conflicts): Adjust comment.
(rule_has_state_sr_conflicts): New static function.
(count_rule_sr_conflicts): New static function.
(rule_nast_state_rr_conflicts): New static function.
(count_rule_rr_conflicts): New static function.
(rule_conflicts_print): New static function.
(conflicts_print): Also use rule_conflicts_print to report on individual
rules.
* src/gram.h (struct rule): Add new fields expected_sr_conflicts,
expected_rr_conflicts.
* src/reader.c (grammar_midrule_action): Transfer expected_sr_conflicts,
expected_rr_conflicts to new rule, and turn off in current_rule.
(grammar_current_rule_expect_sr): New function.
(grammar_current_rule_expect_rr): New function.
(packgram): Transfer expected_sr_conflicts, expected_rr_conflicts
to new rule.
* src/reader.h (grammar_current_rule_expect_sr): New function.
(grammar_current_rule_expect_rr): New function.
* src/symlist.c (symbol_list_sym_new): Initialize expected_sr_conflicts,
expected_rr_conflicts.
* src/symlist.h (struct symbol_list): Add new fields expected_sr_conflicts,
expected_rr_conflicts.
* tests/conflicts.at: Add tests "%expect in grammar rule not enough",
"%expect in grammar rule right.", "%expect in grammar rule too much."
We may generate code such as
basic_symbol (typename Base::kind_type t, YY_RVREF (std::pair<int,int>) v);
which, of course, breaks, because YY_RVREF sees two arguments. Let's
not play tricks with _VA_ARGS__, I'm unsure about it portability.
Anyway, I plan to change more things in this area.
Reported by Sébastien Villemot.
http://lists.gnu.org/archive/html/bug-bison/2018-11/msg00014.html
* data/variant.hh (b4_basic_symbol_constructor_declare)
(b4_basic_symbol_constructor_define): Don't use macro on user types.
* tests/types.at: Check that we support pairs.
* tests/local.at (AT_LANG_FOR_EACH_STD): New.
(AT_REQUIRE_CXX_VERSION): Rename as...
(AT_REQUIRE_CXX_STD): this.
Accept an argument for what to do when the requirement is not met.
* tests/types.at (api.value.type): Check all the C++ stds.
It is unfortunate that %error_verbose was properly diagnosed as
obsoleted by "%define parse.error verbose", but %error-verbose was
not.
* src/parse-gram.y (%error-verbose): Remove support.
* src/scan-gram.l: Do it here instead, with a warning.
* tests/input.at (Deprecated directives): Check it.
These tests are skipped with GCC:
"\"".c:1:5: error: function declaration isn't a prototype [-Werror=strict-prototypes]
int main() { return 0; }
^~~~
* tests/synclines.at: Stop writing C++ in C.
* tests/local.at: Formatting changes.
Also, make sure that `make dist` generates a correct tarball even if
the C++ compiler does not work.
Reported by Nelson H. F. Beebe.
* m4/cxx.m4 (BISON_CXX_WORKS): Define to true/false instead of
true/exit 77. The latter is too dangerous to use (it directly quits).
(ENABLE_CXX): New name for the Automake conditional, for consistency
with ENABLE_CXX11 etc.
* tests/local.at (AT_COMPILE, AT_COMPILE_CXX): Adjust to the new
semantics of BISON_CXX_WORKS.
* examples/c++/local.mk: Skip the variant test if C++ does not work.
* examples/calc++/local.mk: Likewise.
On some systems (x86_64-pc-solaris2.11), with Developer Studio 12.5's
CC, we get:
".../include/CC/Cstd/vector.cc", line 127: Error: Cannot assign const yy::parser::stack_symbol_type to yy::parser::stack_symbol_type without "yy::parser::stack_symbol_type::operator=(const yy::parser::stack_symbol_type&)";.
".../include/CC/Cstd/vector", line 475: Where: While instantiating "std::vector<yy::parser::stack_symbol_type>::__insert_aux(yy::parser::stack_symbol_type*, const yy::parser::stack_symbol_type&)".
".../include/CC/Cstd/vector", line 475: Where: Instantiated from non-template code.
1 Error(s) detected.
Don't expect __cplusplus to be always defined. If it's not, consider
this is C++98.
Reported by Nelson H. F. Beebe.
* data/c++.m4, data/lalr1.cc, examples/c++/variant.yy, tests/local.at,
* tests/testsuite.h:
An undefined __cplusplus means pre C++11.
On some systems, we don't use our getopt. As a consequence the error
messages vary:
$ bison --skeleton
bison: option requires an argument -- skeleton
Try 'bison --help' for more information.
instead of
bison: option '--skeleton' requires an argument
Try 'bison --help' for more information.
Reported by Jannick and Nelson H. F. Beebe.
https://lists.gnu.org/archive/html/bison-patches/2018-10/msg00140.html
* tests/input.at (Invalid number of arguments): work around getopt
portability issues.
* build-aux/local.mk, cfg.mk, examples/calc++/local.mk,
* examples/local.mk, examples/mfcalc/local.mk,
* examples/rpcalc/local.mk, lib/local.mk, src/local.mk,
* tests/local.mk:
Use Automake comments so that we don't get a copy of each in the
generated Makefile.
The previous name is too obscure, and the other macros for C++ use
CXX, not CC.
* tests/local.at (AT_SKEL_CC_IF, AT_SKEL_JAVA_IF): Rename as...
(AT_CXX_IF, AT_JAVA_IF): these.
Adjust callers.
In some casing, once we moved a stack symbol, we forget to mark the
source stack symbol as emptied. As a consequence, it may be destroyed
a second time.
This happens when the stack has to be resized.
* data/lalr1.cc (stack_symbol_type::stack_symbol_type): Record that
the source was emptied.
(stack_symbol_type::operator=): Likewise.
* tests/c++.at (C++ Variant-based Symbols Unit Tests): Force the stack
to be resized. Check its content.
The files stack.hh and position.hh are deprecated. Rather than
devoting specify %define variables to discard them (api.position.file
and api.stack.file), and rather than having to use special rules when
api.location.file is used, let's simply decide that from %require
"3.2" onwards, these files will not be generated.
The only noticeable thing here is that, in order to be able to check
the behavior of %require "3.2", to have this version (which is still
3.1-*) to accept %require "3.2".
* src/gram.h, src/gram.c (required_version): New.
* src/parse-gram.y (version_check): Set it.
* src/output.c (prepare): Pass it m4.
* data/bison.m4 (b4_required_version_if): Receive it and use it.
* data/location.cc, data/stack.hh: Replace the api.*.file with only
required version comparison.
* tests/input.at: No longer check api.stack.file and api.position.file.
* NEWS, doc/bison.texi: Don't mention them.
Document the %require 3.2 behavior.
* tests/output.at: Use %require 3.2 instead.
Currently, in C, the default semantic action is implemented by being
always run before running the actual user semantic action. As a
consequence, when the user action is run, $$ is already set as $1.
In C++ with variants, we don't do that, since we cannot manipulate the
semantic value without knowing its exact type. When variants are
enabled, the only guarantee is that $$ is default contructed and ready
to the used.
Some users still would like the default action to be run with
variants. Frank Heckenbach's parser in
C++17 (http://lists.gnu.org/archive/html/bug-bison/2018-04/msg00011.html)
provides this feature, but relying on std::variant's dynamic typing,
which we forbid in lalr1.cc.
The simplest seems to be actually generating the default semantic
action (in all languages/skeletons). This makes the pre-action (that
sets $$ to $1) useless. But... maybe some users depend on this, in
spite of the comments that clearly warn againt this. So let's not
turn this off just yet.
* src/reader.c (grammar_rule_check_and_complete): Rename as...
(grammar_rule_check_and_complete): this.
Install the default semantic action when applicable.
* examples/variant-11.yy, examples/variant.yy, tests/calc.at:
Exercise the default semantic action, even with variants.
Currently we use "<dir><api.location.file>" as \file argument, and as
base for the CPP guard. This is not nice when <dir> is absolute, in
which case it is expected that the user will use api.location.include
to get something nicer. If defined, use that name instead.
* data/location.cc (b4_location_path): New.
Use it.
* tests/c++.at (Shared locations): Check the guard and Doxygen doc.
Users may want to generate the location file elsewhere, say
$top_srcdir/include/ast/location.hh. Yet, we should not generate
`#include "$top_srcdir/include/ast/location.hh"` but probably
something like `#include <ast/location.hh>`, or `#include
"ast/location.hh", or `#include <location.hh>`. It entirely depends
on the compiler flags (-I/-isystem) that are used. Bison cannot guess
what is expected, so let's give the user a means to tell how the
location file should be included.
* data/location.cc (b4_location_file): New.
* data/glr.cc, data/lalr1.cc: Use it.
In the case a user wants to create location.hh elsewhere, it can be
helpful to define api.location.file to some possibly absolute path
such as -Dapi.location.file='"$(top_srcdir)/include/ast/location.hh"'.
Currently this does not work with `-o foo/parser.cc`, as we join foo/
and $(top_srcdir) together, the latter starting with slash.
We should not try to do that in m4, manipulating file names is quite
complex when you through Windows file name in. Let m4 delegate this
to gnulib.
* src/scan-skel.l (at_output): Accept up to two arguments.
* data/bison.m4 (b4_output): Adjust.
* tests/skeletons.at (Fatal errors but M4 continues producing output):
Adjust to keep the error.
* data/location.cc, data/stack.hh: Leave the concatenation to @output.
* tests/output.at: Exercise api.location.file with an absolute path.
Make it easier to have fewer files.
* data/stack.hh: Don't generate stack.hh when api.location.file is
specified.
* tests/calc++.at, tests/output.at: Adjust tests.
Let's put the definition of position into location.hh, there's no real
value in keeping them separate: they are small, and share the same
requirements.
To help users transition to this new model, still generate position.hh
by default, but as a simple include to location.hh.
* data/location.cc (api.position.file): Accept only 'none' as possible
value.
(position.hh): Make it a stub.
(location.hh): Adjust.
(b4_position_define): Merge into...
(b4_location_define): this.
* data/glr.cc, data/lalr1.cc, tests/input.at, tests/output.at: Adjust.
