Skip to content

(towards #3124) Codeblocks with children references#3247

Open
sergisiso wants to merge 23 commits intomasterfrom
3124_codeblocks_virtual_references
Open

(towards #3124) Codeblocks with children references#3247
sergisiso wants to merge 23 commits intomasterfrom
3124_codeblocks_virtual_references

Conversation

@sergisiso
Copy link
Collaborator

No description provided.

@codecov
Copy link

codecov bot commented Dec 2, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.95%. Comparing base (dfb7589) to head (568bf95).
⚠️ Report is 1 commits behind head on master.

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.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@sergisiso
Copy link
Collaborator Author

@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.

Copy link
Member

@arporter arporter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes please :-)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What was the reason for this change?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reverted

''' 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).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"variables"

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

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)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We still need something like this check - probably has to be a walk now.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re-introduced

@sergisiso
Copy link
Collaborator Author

@arporter It took me a long time to get back to this, but it is now ready for another look.

Copy link
Member

@arporter arporter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately this line isn't covered by the fortran_*test.py tests.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@sergisiso
Copy link
Collaborator Author

sergisiso commented Mar 9, 2026

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?

@arporter
Copy link
Member

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.

@arporter arporter added Blocked An issue/PR that is blocked by one or more issues/PRs. and removed under review labels Mar 10, 2026
@arporter
Copy link
Member

Just stumbled across #831 which I think might already be done and will definitely be done once this is complete?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Blocked An issue/PR that is blocked by one or more issues/PRs.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants