-
Notifications
You must be signed in to change notification settings - Fork 13
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
Sanitise: Resolve free range indices when resolving associates #455
Merged
Merged
Changes from all commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
f4b9036
Sanitise: Add test for matching range indices in array expressions
mlange05 6618203
Sanitise: Add utility method to match indices to free range symbols
mlange05 2f71142
Sanitise: Apply partial range resolution when resolving associates
mlange05 344d098
Sanitise: Terminate after dims/type recursion when resolving assocs
mlange05 c055d93
Sanitise: Only apply partial range resolution if new symbols has dims
mlange05 bed1ae8
Sanitise: Use iterator, when matching free symbols in assoc resolve
mlange05 e350f50
Sanitise: Add recursion + symbol-matching to array slice test
mlange05 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I'm following the logic here. The first recursion to expr_dims seems to only be used if the array's scope isn't an associate - could we not move it into the conditional just before the return statement?
Or alternatively, in which situation do we expect the return value of the recursion on
new.dimensions
to differ from the first recursion? Could we maybe use the previous recursion value here?I suspect the second wouldn't work but the first should allow us to save some recursion maybe?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, yes, this was quite fiddly. The initial recursion is required for resolving associations in the dimensions of arrays that are not actually scope to the
Associate
; that's also why it has to happen before the short-circuiting. For example, considerThe second recursion is then done on the potentially replaced symbol (
new
), which now might have entirely different.dimensions
. For example considerIn the first line of this example
expr == 'a'
andexpr.dimensions == None
andnew.dimensions == (:, :, i)
, the latter of which we have not recursed into yet. In the second example linenew.dimensions
then also needs to be matched against(j, k)
to yieldb(j, k, i)
. Does that make sense?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
EDIT: Scratch this, I'm seeing my error 🤦
Thanks, I suspected something along these lines.
My question was mostly on the grounds of avoiding redundant recursion, purely judged from the dependencies within this method.
Something like this:This should save the need to do the recursion on the dimensions for symbols from the associate since you're recursing on thenew_dims
anyway