forked from crytic/slither
-
Notifications
You must be signed in to change notification settings - Fork 2
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
Store Custom Error Instance in LibraryCall #7
Merged
Merged
Changes from all commits
Commits
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
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.
On line 996, there is a
CustomError
case handler (presumably for top-level custom error calls).Our implementation should reflect the top-level path's
CustomError
handling.(Though, it's annoying that they are still using
SolidityCall
, instead of creatingCustomErrorCall
there.)Also, I'd like this code to be more symmetric to the
EventCall
case above.Let's create a separate if-statement here just like the event_sym leaving this default case as the normal library call.
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.
Will do.
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.
Upon thinking about this: the thing is we don't have a
CustomErrorCall
, let's assume for a moment that we don't want to implement that. Then the following scenario:the
revert L.E()
would be converted into aLibraryCall
, which is handled on line 846. In this case I have to make the changes as I made in this PR. The counterpart for event (event emit through library, not normal event emission. Normal event emission is handled around line 804) is also handled around there. Similarly, line 996 which you pointed out handled only emission of top level custom error and in-contract custom error, which is not the issue I want to address through this PR.The easy and temporary solution would be as is as of this PR. If we want to refactor it to be more scalable, the way to do is implement
CustomErrorCall
.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 guess I should clarify: the normal custom error revert already stored the instance of its custom error, this PR specifically want to address the case where a custom error from library is reverted.
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, let's keep it a LibraryCall when a library error is constructed :(
So, our detector will have to deal with both LibraryCall and SolidityCall.
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.
That indeed is how the detector was written.
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.
Alright. I filed https://github.com/CertiKProject/slither-task/issues/94 to record the situation.