> > So at least 5 different places, perhaps more when you get into it :(
> OK, let's take a look at it. The only one I have seen a problem with
> is:
>
> | '-' a_expr %prec UMINUS
>
> But let's look at the others. Default_expr has it:
>
> default_expr: AexprConst
> { $$ = makeConstantList((A_Const *) $1); }
> | NULL_P
> { $$ = lcons( makeString("NULL"), NIL); }
> | '-' default_expr %prec UMINUS
> { $$ = lcons( makeString( "-"), $2); }
>
> But I don't understand why it is there. Doesn't AexprConst handle
> such a case, or do we get shift-reduce conflicts without it?
No, _no_ negative numbers get through scan.l without being separated
into a minus sign and a positive number. This is because the scanner
does not have any information about context, and cannot distinguish the
usage of the minus, for example between the two cases "a - b" and "- b".
So, to handle "a - b" correctly, the minus sign must always be
separated, otherwise you get "a (-b)" which the grammar does not
understand.
The one place which will see every node come through is in the parser
transformations or in the optimizer, which is why it seems that those
might be good places to look for this case.
- Tom
