yacc.c: fix broken union when api.value.type=union and %defines are used

Reported by Rich Wilson.

* data/c.m4 (b4_symbol_type_register): Append to b4_union_members,
not b4_user_union_members.
The latter invokes the former, but it is the former which is reinitialized
to empty by b4_value_type_setup_union.
* tests/types.at: Check it.

This reveals another bug, this time in the case of glr.c parsers.

* data/glr.c: Generate the header file before the implementation file,
to be sure that the setup is run before what depends on it.
This commit is contained in:
Akim Demaille
2014-12-31 14:15:06 +01:00
parent a3c3c6f242
commit 8d4dc896cb
5 changed files with 70 additions and 23 deletions

View File

@@ -560,15 +560,15 @@ b4_locations_if([, yylocationp])[]b4_user_args[);
# b4_symbol_type_register(SYMBOL-NUM)
# -----------------------------------
# Symbol SYMBOL-NUM has a type (for variant) instead of a type-tag.
# Extend the definition of %union's body with a field of that type,
# and extend the symbol's "type" field to point to the field name,
# instead of the type name.
# Extend the definition of %union's body (b4_union_members) with a
# field of that type, and extend the symbol's "type" field to point to
# the field name, instead of the type name.
m4_define([b4_symbol_type_register],
[m4_define([b4_symbol($1, type_tag)],
[b4_symbol_if([$1], [has_id],
[b4_symbol([$1], [id])],
[yytype_[]b4_symbol([$1], [number])])])dnl
m4_append([b4_user_union_members],
m4_append([b4_union_members],
m4_expand([
b4_symbol_tag_comment([$1])dnl
b4_symbol([$1], [type]) b4_symbol([$1], [type_tag]);]))

View File

@@ -178,6 +178,39 @@ m4_if(b4_skeleton, ["glr.c"],
## Output files. ##
## -------------- ##
# Unfortunately the order of generation between the header and the
# implementation file matters (for glr.c) because of the current
# implementation of api.value.type=union. In that case we still use a
# union for YYSTYPE, but we generate the contents of this union when
# setting up YYSTYPE. This is needed for other aspects, such as
# defining yy_symbol_value_print, since we need to now the name of the
# members of this union.
#
# To avoid this issue, just generate the header before the
# implementation file. But we should also make them more independant.
# ----------------- #
# The header file. #
# ----------------- #
# glr.cc produces its own header.
m4_if(b4_skeleton, ["glr.c"],
[b4_defines_if(
[b4_output_begin([b4_spec_defines_file])
b4_copyright([Skeleton interface for Bison GLR parsers in C],
[2002-2014])[
]b4_cpp_guard_open([b4_spec_defines_file])[
]b4_shared_declarations[
]b4_cpp_guard_close([b4_spec_defines_file])[
]b4_output_end()
])])
# ------------------------- #
# The implementation file. #
# ------------------------- #
b4_output_begin([b4_parser_file_name])
b4_copyright([Skeleton implementation for Bison GLR parsers in C],
[2002-2014])[
@@ -2550,16 +2583,3 @@ m4_if(b4_prefix, [yy], [],
]b4_epilogue[]dnl
b4_output_end()
# glr.cc produces its own header.
m4_if(b4_skeleton, ["glr.c"],
[b4_defines_if(
[b4_output_begin([b4_spec_defines_file])
b4_copyright([Skeleton interface for Bison GLR parsers in C],
[2002-2014])[
]b4_cpp_guard_open([b4_spec_defines_file])[
]b4_shared_declarations[
]b4_cpp_guard_close([b4_spec_defines_file])[
]b4_output_end()
])])