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.
This commit is contained in:
Carl Worth 2010-05-19 07:42:42 -07:00
parent be0e2e9b2a
commit 69f390d609
2 changed files with 11 additions and 1 deletions

View file

@ -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);

View file

@ -0,0 +1,2 @@
#define foo(bar) bar
foo(foo)