m4: catch suspicions of unevaluated macros

Check in m4's output if there are sequences such as m4_foo or b4_foo,
which are probably resulting from incorrect m4 processing.

It actually already is useful:

- it caught a leaking b4_lac_if leaking from glr.c, where LAC is not
  supported, hence b4_lac_if is not defined.

- it also caught references to location.hh in position.hh when
  location.hh does not exist.

- while making "Code injection" robust to these new warnings (it is
  its very purpose to let b4_canary pass unevaluated), I saw that it
  did not check lalr1.d, and when adding lalr1.d, it revealed it did
  underquote ocurrences of token value types.

* src/scan-skel.l (macro): New abbreviation.
Use it.
* data/skeletons/glr.c: Don't use b4_lac_if, we don't have it.
* data/skeletons/location.cc: Don't generate position.hh when we don't
generate location.hh.
* data/skeletons/d.m4 (b4_basic_symbol_constructor_define): Fix
underquotation.
* data/skeletons/bison.m4 (b4_canary): New.
* tests/input.at (Code injection): Use it, and check lalr1.d too.
This commit is contained in:
Akim Demaille
2021-08-07 09:30:24 +02:00
parent 6118406c3e
commit 80db1029e6
7 changed files with 57 additions and 40 deletions

View File

@@ -2204,12 +2204,7 @@ yy_syntax_error_arguments (const yyGLRStack* yystackp,
- Don't assume there isn't a lookahead just because this state is a
consistent state with a default action. There might have been a
previous inconsistent state, consistent state with a non-default
action, or user semantic action that manipulated yychar.]b4_lac_if([[
In the first two cases, it might appear that the current syntax
error should have been detected in the previous state when yy_lac
was invoked. However, at that time, there might have been a
different syntax error that discarded a different initial context
during error recovery, leaving behind the current lookahead.]], [[
action, or user semantic action that manipulated yychar.
- Of course, the expected token list depends on states to have
correct lookahead information, and it depends on the parser not
to perform extra reductions after fetching a lookahead from the
@@ -2217,7 +2212,7 @@ yy_syntax_error_arguments (const yyGLRStack* yystackp,
(from LALR or IELR) and default reductions corrupt the expected
token list. However, the list is correct for canonical LR with
one exception: it will still contain any token that will not be
accepted due to an error action in a later state.]])[
accepted due to an error action in a later state.
*/
if (yytoken != ]b4_symbol(empty, kind)[)
{