From 69f390d6096c597dbe63f20fd02b2312da211de8 Mon Sep 17 00:00:00 2001 From: Carl Worth Date: Wed, 19 May 2010 07:42:42 -0700 Subject: Fix bug (and test) for an invocation using macro name as a non-macro argument This adds a second shift/reduce conflict to our grammar. It's basically the same conflict we had previously, (deciding to shift a '(' after a FUNC_MACRO) but this time in the "argument" context rather than the "content" context. It would be nice to not have these, but I think they are unavoidable (withotu a lot of pain at least) given the preprocessor specification. --- glcpp-parse.y | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) (limited to 'glcpp-parse.y') diff --git a/glcpp-parse.y b/glcpp-parse.y index 8dc07483c1..ea27184c47 100644 --- a/glcpp-parse.y +++ b/glcpp-parse.y @@ -103,8 +103,12 @@ _argument_list_member_at (argument_list_t *list, int index); * 1. '(' after FUNC_MACRO name which is correctly resolved to shift * to form macro invocation rather than reducing directly to * content. + * + * 2. Similarly, '(' after FUNC_MACRO which is correctly resolved to + * shift to form macro invocation rather than reducing directly to + * argument. */ -%expect 1 +%expect 2 %% @@ -168,6 +172,10 @@ argument: | macro { $$ = _string_list_create (parser); } +| FUNC_MACRO { + $$ = _string_list_create (parser); + _string_list_append_item ($$, $1); + } | argument word { _string_list_append_item ($1, $2); talloc_free ($2); -- cgit v1.2.3