-
Notifications
You must be signed in to change notification settings - Fork 16
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
fix: ignore unknown opcodes in source maps #764
Conversation
🦋 Changeset detectedLatest commit: 801e351 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
9a022ba
to
c127666
Compare
The Drop write lock immediately after using it commit is unrelated to this fix, but I ran into that when trying to debug something, and @agostbiro suggested we make that change, since it's a more sane handling of the lock. |
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.
Thanks LGTM with one nit
let opcode = if let Some(opcode) = OpCode::new(bytecode[pc]) { | ||
opcode | ||
} else { | ||
debug!("Invalid opcode {} at pc: {}", bytecode[pc], pc); |
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.
nit: I prefer to not to import these macros from log and just write log::debug!
so that it's easy to differentiate from tracing::debug!
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.
+1
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.
Same comment as Agost. Otherwise looks good to me!
Closes #763.
As far as I can tell, this can only happens when solc produces source maps that have an error, so I think just ignoring this is fine. I'm not adding a test for this because it seems to only happen in very special circumstances, with older versions of solc.