-
Notifications
You must be signed in to change notification settings - Fork 8
[DO NOT MERGE] Tempo support #143
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: upstream
Are you sure you want to change the base?
Conversation
* remove redundant ci workflows * do not compile anvil, port additional files * remove anvil tests * start porting cast * continue porting * add evm, evm core * add templates * continue with forge * this should be all * bump Tempo version * fixes * nit * clean up * use new storage provider closure * re-apply skip test of those who were tagged to be skipped * fix formatting * bump alloy-chains * fix flaky test, unsure why this was test before
disable dependabot on fork, use upstream instead
| let sender = SenderKind::from_wallet_opts(wallet).await?; | ||
|
|
||
| let (tx, _) = CastTxBuilder::new(&provider, tx, &config) | ||
| let (tx, _) = CastTxBuilder::<_, _, TransactionRequest>::new(&provider, tx, &config) |
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.
we can likely upstream the cast builder changes somewhat soon. some care should be taken on what we do wrt flags (e.g. do we namespace them? such as --tempo.nonce-seq for the sequence key, or do we just throw it all in global)
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.
| let mut tx = IERC20::new(token.resolve(&provider).await?, &provider) | ||
| .approve(spender.resolve(&provider).await?, U256::from_str(&amount)?) | ||
| .into_transaction_request(); | ||
| tx.fee_token = send_tx.fee_token; |
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.
this we might also be able to upstream but i do wonder if there is a better way to just have this "automatically" happen if a user supplies --fee-token (and again, maybe it should be --tempo.fee-token)
| requires = "blob", | ||
| help_heading = "Transaction options" | ||
| )] | ||
| path: Option<PathBuf>, |
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.
not sure why we removed this?
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.
Tempo does not support blobs but we should leave it for Ethereum, can be restored I think to make diff smaller
| if is_known_system_sender(tx.from()) | ||
| || tx.transaction_type() == Some(SYSTEM_TRANSACTION_TYPE) | ||
| { | ||
| return Err(eyre::eyre!( | ||
| "{:?} is a system transaction.\nReplaying system transactions is currently not supported.", | ||
| tx.tx_hash() | ||
| )); | ||
| } |
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.
we need to be careful w this given this also affects optimism. we added this check specifically for optimism & prob some other chains (e.g. arb), so maybe we should re-add this check but make it network specific.
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.
added option upstream to replay with system txes, default to false to keep current behavior
| env.evm_env.block_env.timestamp = U256::from(block.header.timestamp()); | ||
| env.evm_env.block_env.beneficiary = block.header.beneficiary(); | ||
| env.evm_env.block_env.difficulty = block.header.difficulty(); | ||
| env.evm_env.block_env.prevrandao = Some(block.header.mix_hash().unwrap_or_default()); | ||
| env.evm_env.block_env.basefee = block.header.base_fee_per_gas().unwrap_or_default(); | ||
| env.evm_env.block_env.gas_limit = block.header.gas_limit(); |
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.
this im unsure how to upstream given the evmenv will change from chain to chain :p
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.
these labels and such we can prob just do somewhere else and make them network specific. e.g. NetworkConfig/NetworkArgs
* fix: properly configure txenv for cast run * fix test --------- Co-authored-by: grandizzy <[email protected]>
Instructions to sync upstream: Once, add `upstream` remote target ``` git remote add upstream [email protected]:foundry-rs/foundry.git ``` First, sync `upstream` branch ``` git fetch upstream git switch upstream git reset --hard upstream/master git push --force-with-lease origin upstream ``` Next, sync `tempo` branch by PR ``` SYNC_BRANCH="sync-$(date -u +%Y%m%d-%H%M%S)" git fetch origin upstream git switch -c "$SYNC_BRANCH" origin/tempo git merge upstream/master git push -u origin "$SYNC_BRANCH" ``` :warning: This should NOT be merged with a squash commit to preserve commit history
Sync's Tempo and Foundry to latest commits
chore: cleanup mktx and run
<!-- Thank you for your Pull Request. Please provide a description above and review the requirements below. Bug fixes and new features should include tests. Contributors guide: https://github.com/foundry-rs/foundry/blob/HEAD/CONTRIBUTING.md The contributors guide includes instructions for running rustfmt and building the documentation. --> <!-- ** Please select "Allow edits from maintainers" in the PR Options ** --> ## Motivation add possibility to specify which network to run CI check on - testnet - devnet - all <!-- Explain the context and why you're making that change. What is the problem you're trying to solve? In some cases there is not a problem and this can be thought of as being the motivation for your change. --> ## Solution <!-- Summarize the solution and provide any necessary context needed to understand the code change. --> ## PR Checklist - [ ] Added Tests - [ ] Added Documentation - [ ] Breaking changes
Contains all changes applied to make Foundry work with Tempo
Instructions to sync upstream:
Once, add
upstreamremote targetFirst, sync
upstreambranchNext, sync
tempobranch by PR