feat(common): replace solidity-parser with Slang#3811
feat(common): replace solidity-parser with Slang#3811ggiraldez wants to merge 15 commits intolatticexyz:mainfrom
solidity-parser with Slang#3811Conversation
|
|
@ggiraldez is attempting to deploy a commit to the Lattice Team on Vercel. A member of the Team first needs to authorize it. |
ggiraldez
changed the title
packages/commonpackages/common
alvrs
changed the title
packages/commonsolidity-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.
Is there a way to avoid hardcoding the version here?
There was a problem hiding this comment.
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.
actually, why wouldn't the parser use the pragma to determine which version to use? 🤔
There was a problem hiding this comment.
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.
I went with the version inference path. It should be the safest and most durable.
There was a problem hiding this comment.
@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.
4 participants
This PR replaces
solidity-parserby 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.