Update to the current gnulib CVS repository, and fix trigraph handling

in Bison.
* bootstrap: Update gnulib CVS repository URL.
(symlink_to_dir): Encapsulate the code that guarantees the destination
directory exists into...
(check_dst_dir): ... this new function, and...
(cp_mark_as_generated): ... reuse it here so that bootstrap doesn't
fail when copying files into lib/uniwidth/.
* src/output.c (prepare_symbols): When writing yytname muscles, where
symbol names will be encoded in C-string literals, tell quotearg to
escape trigraphs.  This used to be the default in gnulib.
* tests/regression.at (Token definitions): Because of the change in
gnulib's quotearg behavior, string_as_id in parse-gram.y no longer
escapes trigraphs in symbol names.  Thus, yytname no longer has
trigraphs unnecessarily doubly escaped.  Update test case output.
Extend test case to be sure Bison's own error messages will no longer
have trigraphs in symbol names unnecessarily escaped once.
This commit is contained in:
Joel E. Denny
2008-04-21 06:54:39 +00:00
parent 8452fdd914
commit 1cfe6375ce
7 changed files with 168 additions and 112 deletions

View File

@@ -444,6 +444,7 @@ int yylex (void);
%token C_TOKEN 'c'
%token 'd' D_TOKEN
%token SPECIAL "\\\'\?\"\a\b\f\n\r\t\v\001\201\x001\x000081??!"
%token SPECIAL "\\\'\?\"\a\b\f\n\r\t\v\001\201\x001\x000081??!"
%%
exp: "a" "\\\'\?\"\a\b\f\n\r\t\v\001\201\x001\x000081??!";
%%
@@ -469,10 +470,22 @@ main (void)
}
]])
AT_BISON_CHECK([-o input.c input.y])
# Checking the warning message guarantees that the trigraph "??!" isn't
# unnecessarily escaped here even though it would need to be if encoded in a
# C-string literal. Also notice that unnecessary escaping, such as "\?", from
# the user specification is eliminated.
AT_BISON_CHECK([-o input.c input.y], [[0]], [[]],
[[input.y:22.8-14: warning: symbol SPECIAL redeclared
input.y:22.8-63: warning: symbol `"\\'?\"\a\b\f\n\r\t\v\001\201\001\201??!"' used more than once as a literal string
]])
AT_COMPILE([input])
# Checking the error message here guarantees that yytname, which does contain
# C-string literals, does have the trigraph escaped correctly. Thus, the
# symbol name reported by the parser is exactly the same as that reported by
# Bison itself.
AT_DATA([experr],
[[syntax error, unexpected "\\'?\"\a\b\f\n\r\t\v\001\201\001\201?\?!", expecting a
[[syntax error, unexpected "\\'?\"\a\b\f\n\r\t\v\001\201\001\201??!", expecting a
]])
AT_PARSER_CHECK([./input], 1, [], [experr])
AT_CLEANUP