Statement function fix #214
Conversation
|
Oh snap, I just realised that a statement function test exists in subroutines, and that the issue goes a little deeper. Apologies! Will take a look how to address C1112: |
It seems a solution to this has existed before? <confused>
Codecov Report
@@ Coverage Diff @@
## master #214 +/- ##
==========================================
+ Coverage 89.71% 89.89% +0.17%
==========================================
Files 34 34
Lines 11929 11930 +1
==========================================
+ Hits 10702 10724 +22
+ Misses 1227 1206 -21
Continue to review full report at Codecov.
|
|
Ok, so re-enabling the existing fix/workaround for statement functions seems to bring the tests back to green. Since neither #202 nor the comments in the code specified why that was disabled in the first place, I'd be very interested to see what the concerns were and if I can help find a better solution for this. Happy to help and do some legwork, as it's an unfortunately strong requirement for my downstream stuff. |
Basically, without knowing the exact limits of the specification and execution parts of a subroutine, a statement function looks like an array access to the frontend and aliased. This new test checks that the distinction is made correctly, and that a stmt function in the execution part fails.
|
@rupertford After off-line discussion, I think I understand what the issues are. I've added a test case to demonstrate the aliasing issue with array assignment statements across the divide between specification and execution part of a subroutine. More work needed to get around this though... |
|
Hi @mlange05. Given our discussion at ECMWF and the newly updated descriptions of #202 and #201 (which suggest we create a symbol table before trying to tackle determining whether this is a statement function or not i.e. get more contextual information than just the rule itself), would it make sense for this PR to be changed into simply adding an appropriate xfailing test, or do you want to keep it open ready for personal use and to wait for the completion of #201? |
|
@rupertford Yeah, I think I'll keep the branch for reference but simply close the PR for now. I'll bring it back once we have the symbol table in place. I'll try and find some time to look at this soon. 🤞 |
While statement functions are already implemented in
fparser.two.Fortran2003.py, they are not recognised in thedeclaration-constructof subroutines. This PR fixes this and adds a small set of tests. With the test in place, issue #202 has probably been addressed?