Skip to content
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

feat: optimize compilation by reading AST #7599

Merged
merged 12 commits into from
Apr 17, 2024
Merged

Conversation

klkvr
Copy link
Member

@klkvr klkvr commented Apr 8, 2024

Motivation

Currently when running forge script <contract_name> or forge script <contract_path> we will recompile entire project, this is true for forge create and forge selectors as well.

Solution

Use already existing files filter on ProjectCompiler when path is provided, use solang AST to find source file when only contract name is provided.

Copy link
Member

@mattsse mattsse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nits and q about error handling

crates/common/src/compile.rs Outdated Show resolved Hide resolved
for file in graph.files().keys() {
let src = std::fs::read_to_string(file)?;
let (parsed, _) = solang_parser::parse(&src, 0)
.map_err(|_| eyre::eyre!("Failed to parse {}.", file.display()))?;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we now depend on solang to parse it successfully.

should we fallback to previous behaviour if this fails?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah I think we can do that

actually thought that we assumed solang being able to parse any valid Solidity

perhaps its better to invoke solc with empty output instead? similar to how we do it for tests now requesting just abi

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually thought that we assumed solang being able to parse any valid Solidity

it could be that future lang features are not supported right away, so I think we can fallback to previous behaviour if parsing fails.
if there's any syntax error this should also ensure that the user gets the proper solc error message

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated code, now we fallback to running solc with empty output when solang fails

not really want to fully fallback to old behavior as this is not the most efficient way and will add additional complexity because we'd have to handle potential find_contract_path errors everywhere

crates/common/src/compile.rs Outdated Show resolved Hide resolved
@klkvr klkvr force-pushed the klkvr/smarter-compilation branch from b17a4c6 to c2cfc04 Compare April 14, 2024 14:15
@klkvr klkvr force-pushed the klkvr/smarter-compilation branch from df83444 to ca60334 Compare April 14, 2024 21:54
Copy link
Member

@mattsse mattsse left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggesting to move the new fn f(&Project,..) functions to foundry-compilers directly, we already have solang parsing in there so I think moving them would be appropriate

crates/common/src/compile.rs Outdated Show resolved Hide resolved
mattsse pushed a commit to foundry-rs/compilers that referenced this pull request Apr 17, 2024
@mattsse mattsse merged commit 0a4d246 into master Apr 17, 2024
20 checks passed
@mattsse mattsse deleted the klkvr/smarter-compilation branch April 17, 2024 14:36
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.

2 participants