fix[codegen]: cache result of iter eval#4488
Merged
charles-cooper merged 4 commits intovyperlang:masterfrom Feb 22, 2025
Merged
fix[codegen]: cache result of iter eval#4488charles-cooper merged 4 commits intovyperlang:masterfrom
charles-cooper merged 4 commits intovyperlang:masterfrom
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #4488 +/- ##
=======================================
Coverage 92.06% 92.06%
=======================================
Files 120 120
Lines 17329 17330 +1
Branches 2932 2932
=======================================
+ Hits 15954 15955 +1
Misses 957 957
Partials 418 418 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
cyberthirst
approved these changes
Feb 22, 2025
Collaborator
cyberthirst
left a comment
There was a problem hiding this comment.
let's please link the PR to the advisory before merging
Collaborator
|
should we update the docs for how the evaluation of the iter behaves? |
Member
Author
i don't think so, i think this is the expected behavior. we have the advisory for the old behavior. |
Member
Author
i think it's already linked? |
lemenkov
pushed a commit
to fedora-ethereum/vyper
that referenced
this pull request
Feb 27, 2025
prior to this commit, multiple evaluation of a single expression is possible in the iterator target of a for loop. while the iterator expression cannot produce multiple writes, it can _consume_ side effects produced in the loop body (e.g. read a storage variable updated in the loop body) and thus lead to unexpected program behavior. specifically, reads in iterators which contain an `IfExp` (e.g. `for s: uint256 in ([read(), read()] if True else []))` would issue one evaluation of the list `[read(), read()]` per loop iteration, thus interleaving reads with writes in the loop body. this commit fixes the issue by using `cache_when_complex` to enforce evaluation of the iterator before entering the loop body. this is incidentally also a performance fix, since it moves the repeated evaluation into a one-time evaluation. references: - GHSA-h33q-mhmp-8p67
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What I did
fix for GHSA-h33q-mhmp-8p67 by always evaluating complex expressions before entry into the loop body. this is also a perf fix, since it moves the repeated evaluation into a one-time evaluation.
How I did it
How to verify it
Commit message
Description for the changelog
Cute Animal Picture