Re: [PATCH 09/17] widl: Split the expr rule up into multiple rules to fix operator precedence.

[Alexandre Julliard]

Robert Shearman <rob(a)codeweavers.com> writes:
> @@ -263,8 +263,14 @@ static void add_explicit_handle_if_necessary(func_t *func);
>  %type <attr> attribute
>  %type <attr_list> m_attributes attributes attrib_list
>  %type <str_list> str_list
> -%type <expr> m_expr expr expr_const
> -%type <expr_list> m_exprs /* exprs expr_list */ expr_list_const
> +%type <expr> m_expr expr_const expression conditional_expression
> +%type <expr> conditional_expression logical_OR_expression logical_AND_expression
> +%type <expr> inclusive_OR_expression exclusive_OR_expression AND_expression
> +%type <expr> equality_expression relational_expression shift_expression
> +%type <expr> additive_expression additive_expression multiplicative_expression
> +%type <expr> cast_expression unary_expression postfix_expression
> +%type <expr> primary_expression
> +%type <expr_list> m_exprs expr_list_const
>  %type <array_dims> array array_list
>  %type <ifinfo> interfacehdr
>  %type <type> inherit interface interfacedef interfacedec

You shouldn't need that, the %left/%right declarations should define the
correct precedence already. Why doesn't this work for you?

-- 
Alexandre Julliard
julliard(a)winehq.org

[PATCH 09/17] widl: Split the expr rule up into multiple rules to fix operator precedence.

[Robert Shearman]

Alexandre Julliard wrote:
> You shouldn't need that, the %left/%right declarations should define the
> correct precedence already. Why doesn't this work for you?

I was attempting to fix the attached case. The result of the expression 
evaluation can be seen in the generated _c.c file by searching for "/* 
Corr desc:  constant, val=".

I see that the issue is that the %left and %right declarations aren't in 
the correct order (and some aren't grouped properly either).

So this bug can indeed be fixed without splitting up expr into multiple 
rules.

-- 
Rob Shearman