Shift/reduce conflict with C-like grammar under Bison -

i've been working on c-like grammar personal amusement. however, i've been running shift/reduce conflicts, , i'm quite sure resolved.

right expressions this, in simplified form, stripped of actions:

%left '+' '-'  %% expr  : number  | identifier  | expr '+' expr  | expr '-' expr  /* other operators '*', '/', etc. */  | expr '(' expr ')' /* function call */ %% 

however, results in shift/reduce conflicts: parser unsure how treat parentheses. -v tells me, unclear whether expression expr '+' expr '(' should reduce expr '+' expr expr or shift parenthesis.

obviously, want parenthesis shifted. foo % bar(4) shouldn't end being (foo % bar)(4). however, i've had no success using %prec directive mean. adding %left funcall , %prec funcall after rule yields no change.

i know default path bison's lalr parsers go when encountering shift/reduce shift, , use %expect fix work around problem. however, 1 conflict generated each expression, , ever need change list, i'll need change %expect declaration, looks rather ugly solution me. besides, i'm sure 1 of wise kids have solution problem.

my goal have rule similar 1 above, bison know whenever encounters '(' function call rule, has shift parenthesis, without possible shift/reduce conflict. record, use of %prec directive following, if i'm doing wrong can correct me. have shift/reduce conflict.

%left '+' '-' %left funcall  %%  expr     : number     | identifier     | expr '+' expr     | expr '-' expr     /* other operators '*', '/', etc. */     | expr '(' expr ')' %prec funcall /* function call */  %% 

you need add %left '(' precedence rules (or %nonassoc '(' might better).

the way precedence works resolve shift/reduce conflicts in yacc/bison compares precedence of rule reduced precedence of token shifted. in example, conflict between reducing expr: expr '+' expr , shifting '(', resolve it, need precedence on '(' (and want higher rule, comes '+')

the %prec directive sets precedence of rule, overriding default precedence comes first token on rhs. doesn't affect precedence of tokens appear in rule in way.