Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IR: Automatic sanitisation of tuples in IR constructors #350

Merged
merged 5 commits into from
Jul 26, 2024

Conversation

mlange05
Copy link
Collaborator

@mlange05 mlange05 commented Jul 24, 2024

Just`` testing for now....

Note, this is based on #349, as it requires pydantic version >=2.0.

Following the Pydantic upadte, this PR now smoothes over the type-checking of the base IR nodes, in particular InternalNode, and adds "smart" conversion of .body tuples to the desired internal format. In particular, this now means that erroneous tuples (eg. nested, or containing None instances) are now automatically fixed, before being passed to the pydantic validators. This in turn will allow a more liberal use of Transformers for in-traversal replacements (the real point of this change!).

In more detail:

  • Added a small _sanitise_tuple utility method to loki.ir.nodes
  • Explicitly typed .body as Tuple[Union[Node, Scope], ...] to allow nested Subroutine objects (eg. internal procedures)
  • Added auto-casting tests to IR tests for Loop and Conditional, and added test for Section, which tests only the inherited behaviour from InternalNode

Copy link

Documentation for this branch can be viewed at https://sites.ecmwf.int/docs/loki/350/index.html

@mlange05 mlange05 requested a review from reuterbal July 24, 2024 15:33
@mlange05 mlange05 marked this pull request as ready for review July 24, 2024 15:33
Copy link

codecov bot commented Jul 24, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.35%. Comparing base (536908b) to head (561d748).
Report is 12 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #350      +/-   ##
==========================================
+ Coverage   95.33%   95.35%   +0.01%     
==========================================
  Files         171      171              
  Lines       36543    36801     +258     
==========================================
+ Hits        34837    35090     +253     
- Misses       1706     1711       +5     
Flag Coverage Δ
lint_rules 96.39% <ø> (ø)
loki 95.33% <100.00%> (+0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@mlange05 mlange05 force-pushed the naml-ir-autocast-constructors branch from b31ee40 to a013e13 Compare July 25, 2024 03:34
Copy link
Collaborator

@reuterbal reuterbal left a comment

Choose a reason for hiding this comment

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

This looks fantastic, many thanks, and we finally gain the flexibility of being more forgiving in the tuple nesting in the constructor while ensuring correct IR nodes.

One question about a potential change in default behaviour for Conditional and whether this is intentional, otherwise good to go!

@@ -560,7 +570,7 @@ class _ConditionalBase():

condition: Expression
body: Tuple[Node, ...]
else_body: Optional[Tuple[Node, ...]] = None
else_body: Optional[Tuple[Node, ...]] = ()
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is that a change in behaviour for the default value of else_body?
I think so far we used else_body=None as indicator that there isn't an else branch in the conditional - as opposed to an empty else branch (which has the same result but different on a string level).

As in, will ir.Conditional(condition=<...>, body=<...>) now be represented as the following?

IF (<...>) THEN
  <...>
ELSE
ENDIF

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Nope, we're doing a plain old if o.else_body: which evaluates to the same thing:
https://github.com/ecmwf-ifs/loki/blob/main/loki/backend/fgen.py#L633

@mlange05
Copy link
Collaborator Author

@reuterbal I just noted that we now have a hard dependency on pydantic>=2.0 with this, so please let me quickly update the setup file....

@mlange05
Copy link
Collaborator Author

Ok, fix pushed. Please note that existing local checkouts might fail after this - to remedy, a simple pip install -e . in the loki directory should suffice to get pydantic updated.

@reuterbal reuterbal merged commit 2b3b206 into main Jul 26, 2024
12 checks passed
@reuterbal reuterbal deleted the naml-ir-autocast-constructors branch July 26, 2024 13:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants