(towards #3124) Codeblocks with children references#3247
(towards #3124) Codeblocks with children references#3247
Conversation
… children references
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #3247 +/- ##
=======================================
Coverage 99.95% 99.95%
=======================================
Files 386 386
Lines 54181 54206 +25
=======================================
+ Hits 54159 54184 +25
Misses 22 22 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@arporter @LonelyCat124 @hiker This is ready for review, it is another step into making the all references expressed in the PSyIR so that tools that expect/operate on References don't need edge cases. |
arporter
left a comment
There was a problem hiding this comment.
Nice, thanks Sergi.
The only concern I have is that, with this change, we now won't warn if a Symbol incorrectly gets added to the table of a Container. Can we tighten up on that?
I see you ran the integration tests so I won't do that again this time around.
| # s symbol should not be in my_mod | ||
| with pytest.raises(KeyError): | ||
| psyir.children[0].symbol_table.lookup("s") | ||
| # FIXME: explain |
There was a problem hiding this comment.
Done. Its an important consideration, feel free to discuss.
| ''' | ||
| fake_parent, fparser2spec = process_where( | ||
| "WHERE (ptsu(myfunc(), :, :) /= 0._wp)\n" | ||
| "WHERE (ptsu(unres, :, :) /= 0._wp)\n" |
There was a problem hiding this comment.
What was the reason for this change?
| ''' Tests the infer_sharing_attributes() method when some of the loops have | ||
| Codeblocks inside it. We check that the infer_sharing attribute analysis | ||
| succeed by assuming worst case. | ||
| potentially hidden references (e.g. inside codeblocks or loop varialbes). |
| loop = psyir.walk(Loop)[loop_idx] | ||
| # Make sure that the write statements inside the loop are CodeBlocks, | ||
| # otherwise we need a new test example | ||
| assert loop.has_descendant(nodes.CodeBlock) |
There was a problem hiding this comment.
We still need something like this check - probably has to be a walk now.
|
@arporter It took me a long time to get back to this, but it is now ready for another look. |
arporter
left a comment
There was a problem hiding this comment.
Very nearly there. There's just one line in the fortran backend that isn't covered by the associated tests. I'll fire off the ITs in the meantime.
| if type(symbol) is Symbol and symbol.is_unresolved: | ||
| # However we also accept symbols that we don't know where | ||
| # they are declared, so we propagated upwards. | ||
| continue |
There was a problem hiding this comment.
Unfortunately this line isn't covered by the fortran_*test.py tests.
There was a problem hiding this comment.
Since I'm here, I'm also not sure what "we propagated upwards" means as we're already handling a FileContainer at this point. Do you mean they will have been propagated upwards and have ended up in this table?
|
Thanks for reviewing @arporter . This PR doesn't bring any benefit by itself, it will only be a benefit when all data symbol usage is captured by a Reference (Loop iterators and LFRic Kernels arguments are still missing). Since a release is imminent, I am wondering if we should not not mess with the CodeBlock structure now and merge this after the release. What do you think? |
Yes, that sounds sensible to me. I'll mark it as 'blocked' pending cutting of a release-candidate. |
|
Just stumbled across #831 which I think might already be done and will definitely be done once this is complete? |
No description provided.