Closed reuterbal closed 3 years ago
I can reproduce (thanks for providing the example) and will take a look.
I think I've fixed it. 'Just' need to do the tidying and testing to bring this part of the code into line with the coding standards.
Thanks a ton! This looks like it was a nasty thing to find...
It wasn't too hard - once you see F2PY_EXPR_TUPLE_xxx
in the output you know you're missing a remap() somewhere :-)
It turns out that the "obsolete parentheses" are required by the standard but not, unfortunately, by fparser2 :-(
Without the parentheses, fparser2 matches an Ac_Value_List
rather than an implicit loop:
-> assert "array = (/ival, ival = 1, nval, istep/)" in str(ast)
(Pdb) ast
Assignment_Stmt(Name('array'), '=', Array_Constructor('(/', Ac_Value_List(',', (Name('ival'), Structure_Constructor_2(Name('ival'), Int_Literal_Constant('1', None)), Name('nval'), Name('istep'))), '/)'))
All valid Expr
are valid members of this list but we can see that in this case the parser has matched a Structure_Constructor_2
for the assignment ival = 1
. This does not seem to follow the standard:
R457 structure-constructor is derived-type-spec ( [ component-spec-list ] )
fparser2 has instead: https://github.com/stfc/fparser/blob/ae8f92b3ba0fd2e8cb58bd8aa186b6c2acb914e7/src/fparser/two/Fortran2003.py#L2289-L2292
where:
and it's the structure-constructor-2
that is causing the problem. I can find no mention of R457.b (with which structure-constructor-2
is labelled in the code) in the 2003 standard.
This appeared to be opening a can of worms so I've closed it again by opening issue #255 :-)
Thanks - and sorry for the trouble...
I can confirm that #256 fixes the issue for us. Many thanks!
PR #256 is now on master. Closing this issue.
Hi,
I have found a situation where parentheses in an implied-do break the reader. Consider the following boiled-down example:
Replacing the statement by
(i.e., removing the obsolete parentheses) or by
(i.e., hard-coding the size but keeping the parentheses) works fine.