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.
* 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
%%
| 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);
--- /dev/null
+#define foo(bar) bar
+foo(foo)