Modelling of parameters in 'REWIND', 'OPEN', 'INQUIRE' and other statements

[lsafina]

Currently for statements like

REWIND (UNIT=3, IOSTAT=CODE, ERR=100)
inquire(unit=xunit,form=zform,err=10,iostat=zios)
OPEN(8, FILE='projectA/data.test', ERR=99)
...

parameters are modelled as FASTFortranAssignmentStatement, which does not work for the cases like err=10 when the right part of the expression is an instance of FASTFortranLabelReference which is not a subclass of FASTFortranExpression expected there.

Possible solutions: 1) make FASTFortranLabelReference inherit FASTFortranExpression 2) allow FASTFortranAssignmentStatement to have FASTFortranLabelReference in the right side. (Requires changes in FAST-Core!) 3) when FASTFortranLabelReference used as parameter, recreate is as FASTFortranIntegerLiteral 4) design some new type of entities or reuse existent ones to model such parameters

[NicolasAnquetil]

It seems strange to me that it is a FASTFortranLabelReference.

In my old (2 weeks) image, it is an Integer literal here is a screenshot of test SyntaxJsonToFASTTests >> testRewindStatementIOParameters.

There seems to be some regression there, no?

[lsafina]

Yes, it has been changed as a start_pos was added to a label reference.

Before the rule <110b:label_ref> = %unsigned_int_constant was returning $ptext ("%unsigned_int_constant") which was then treated as an integer in pharo.

Now it returns an object with start_pos

$LIST( <110b:label_ref>)
{
  $LIST( <110b:label_ref>) = ast_label_ref(
    LOCATION(0),
    $ptext ("%unsigned_int_constant")
  );
}

and in pharo creates a FASTFortranLabelReference

visitLabelReference: aNode
^ self visitJsonMap: aNode keys: #( start_pos label )

visitLabelReference: aNode
    | data |

    data := super visitLabelReference: aNode.

    ^(self newEntity: FASTFortranLabelReference withPosition: data)
        label: (aNode at: #label) ;
        yourself

[lsafina]

Number 3 on the level of visitControlInfoValue