-
Notifications
You must be signed in to change notification settings - Fork 218
feat(common): replace solidity-parser
with Slang
#3811
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
base: main
Are you sure you want to change the base?
Conversation
|
@ggiraldez is attempting to deploy a commit to the Lattice Team on Vercel. A member of the Team first needs to authorize it. |
packages/common
packages/common
packages/common
solidity-parser
with Slang
The latest updates on your projects. Learn more about Vercel for GitHub.
|
ast = parse(source); | ||
} catch (error) { | ||
throw new MUDError(`Failed to parse contract ${contractName}: ${error}`); | ||
const parser = Parser.create("0.8.24"); |
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.
Is there a way to avoid hardcoding the version here?
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 believe we already parse the foundry config and pass that through in a few places in MUD tools, so we could pass that through here to avoid hardcoding it
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.
actually, why wouldn't the parser use the pragma to determine which version to use? 🤔
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 wasn't sure what the version policy wrt Solidity was for MUD. Is it bound to the MUD release, or is completely user defined? Otherwise, Slang can infer the version from the source code, or we can extract it as a constant, or pass it through as a parameter. Happy to implement whatever solution works best for you.
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 went with the version inference path. It should be the safest and most durable.
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.
@alvrs @frolic I noticed that the currently used solc version in this repository is updated manually every now and then. Example: aabd307
In that commit, while projects/existing code specifically use 0.8.24
, the Solidity files contain a more permissive pragma pragma solidity >=0.8.24;
. When using the Slang parser, the version can be hard-coded/updated manually along the rest of the codebase like the commit above, or inferred automatically (as suggested by @ggiraldez's comment here). But with inference, a higher version could be inferred, since it would match >=0.8.24
. Up to you on which solution you prefer.
Please let us know if you have any other feedback.
This PR replaces
solidity-parser
by Slang for the tasks of analyzing Solidity source code for generating MUD wrappers. It's a somewhat straight translation, but opens up the possibility of using more features of Slang (eg. name bindings, Solidity multi-version support, or full fidelity CST).The PR also adds some unit tests for some of the migrated modules.