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.
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
Don't ignore errors reported after analysis #15624
Don't ignore errors reported after analysis #15624
Changes from all commits
7e1486d
95c6e84
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Previously,
stack.optimize()
was called prior to invokingstack.parserResult()
. However, now it is called afterward (on line 1264). If I’m not mistaken, theObject
returned byparserResult()
can also be modified byoptimize()
, meaning thathasContiguousSourceIndices
will not be checked against the optimized object anymore, no? Is this intentional, or am I misunderstanding something?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 don't think that was intentional. The check was inserted after
optimize()
probably simply because it was more convenient to do it there. IMO it makes more sense to do such checks on the unoptimized code that the user is submitting rather than on some modified version so the change is good.In any case, it should not affect solc behavior in practice -
optimize()
theoretically could change the code in an arbitrary way, but in practice it will never touch the@use-src
annotation so this property should remain unchanged.We also have a second validation against this in the asm export code, which would catch this if it did happen:
solidity/libevmasm/Assembly.cpp
Lines 509 to 514 in ea52aca
We have the check in the CLI only because we don't catch
AssemblyImportError
there. Perhaps we should later change it into aCodeGenerationError
so that it gets caught byYulStack
and reported as a normal error.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.
Yeah, I don't see why not do that.
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.
ok, I'll keep it in mind for when we're done with this series of PRs and can actually handle those errors properly.