Skip to content

Conversation

ggiraldez
Copy link

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.

@ggiraldez ggiraldez requested a review from alvrs as a code owner August 29, 2025 16:41
Copy link

changeset-bot bot commented Aug 29, 2025

⚠️ No Changeset found

Latest commit: 8365cb9

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

Copy link

vercel bot commented Aug 29, 2025

@ggiraldez is attempting to deploy a commit to the Lattice Team on Vercel.

A member of the Team first needs to authorize it.

@ggiraldez ggiraldez changed the title Use Slang in packages/common feat: Use Slang in packages/common Sep 2, 2025
@alvrs alvrs changed the title feat: Use Slang in packages/common feat(common): replace solidity-parser with Slang Sep 3, 2025
Copy link

vercel bot commented Sep 3, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Preview Comments Updated (UTC)
id.place Ready Ready Preview Comment Sep 3, 2025 3:58pm

ast = parse(source);
} catch (error) {
throw new MUDError(`Failed to parse contract ${contractName}: ${error}`);
const parser = Parser.create("0.8.24");
Copy link
Member

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?

Copy link
Member

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

Copy link
Member

@frolic frolic Sep 4, 2025

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? 🤔

Copy link
Author

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.

Copy link
Author

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.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants