Extraneous brackets cause parsing for arithmetic operator error

[RaoulHC]

The following valid fortran fails to be parsed

      program main
      integer*4 bar
      call foo((bar)*2)
      end program main

Giving:

ProgramFilefortran-src: test.f, 3:22: test.f: parsing failed. 
Last parsed token: TStar (3:21)-(3:21).
CallStack (from HasCallStack):
  error, called at app/Main.hs:108:36 in main:Main

This seems to apply to all arithmetic operators (haven't tried other operators) and only if the brackets are on the left side.

[raehik]

Argh. This is surely caused by b335ac5 . I imagine it gets to the '(' VARIABLE ')' line in the CALLABLE_EXPRESSION rule:

fortran-src/src/Language/Fortran/Parser/Fixed/Fortran77.y

Lines 750 to 753 in 70c0456

	| '(' VARIABLE ')'
	{ let ExpValue _ _ (ValVariable v) = $2
	in Argument () (getTransSpan $1 $3) Nothing (ArgExprVar () (getSpan $2) v) }
	| EXPRESSION { Argument () (getSpan $1) Nothing (ArgExpr $1) }

But (bar)*2 is an expression, not a variable. So it erroneously parses (bar), then has nowhere to go for the rest of the expression.

[raehik]

Works fine on commit 58b0de3 (immediately before the arg expr change)

[RaoulHC]

Why exactly is that parsed differently? Is there anything significant about bracketed arguments?

[raehik]

In #203 we found some surprising cases where bracketing variables in call() argument lists produced different behaviour. We inserted an intermediate data type to enable disambiguating whether an arg was bracketed or not and adding parsing for it, above.

Not too sure how to approach this immediately. Do we have to refactor to handle bracketed expressions in a more complex way? may I ask @dorchard if he has any insights...?

[RaoulHC]

Oh I was unaware of that too, that's a feature that introduces some unfortunate syntactical ambiguity.

Not sure what the best way to handle that is. Obviously foo((var)*2) should still be valid so the parser might have some nastiness to deal with both these cases.