-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Conversation
Remove botched ethcore-error crate
* master: Extricate PodAccount and state Account to own crates (#10838) logs (#10817) refactor: whisper: Add type aliases and update rustdocs in message.rs (#10812) Break circular dependency between Client and Engine (part 1) (#10833) tests: Relates to #10655: Test instructions for Readme (#10835) refactor: Related #9459 - evmbin: replace untyped json! macro with fully typed serde serialization using Rust structs (#10657)
…hore/extricate-state-backend * dp/chore/extricate-account-db-into-own-crate: third time's the charm test failure 2 test failure Extricate PodAccount and state Account to own crates (#10838) logs (#10817) refactor: whisper: Add type aliases and update rustdocs in message.rs (#10812) Break circular dependency between Client and Engine (part 1) (#10833) tests: Relates to #10655: Test instructions for Readme (#10835) refactor: Related #9459 - evmbin: replace untyped json! macro with fully typed serde serialization using Rust structs (#10657)
* master: Improve logging and cleanup in miner around block sealing (#10745)
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.
There are several things that I like and don't like about this pr. I definitely like unification of error types and cleanup possibilities that it brings. I don't like putting more modules into types/
crate which imo should be kept as small as possible. But all in all I believe that pros of this pr significantly out-wage cons and we can modularize types crate more after we finish our work with ethcore.
great work!
/// Auxiliary data fetcher for an Ethereum machine. In Ethereum-like machines | ||
/// there are two kinds of auxiliary data: bodies and receipts. | ||
#[derive(Default, Clone)] | ||
pub struct AuxiliaryData<'a> { |
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.
Can we keep those data structures together with Machine
? I don't think that putting all plain data structures in the same crate is a good idea. imo this crate should define only the basic few (header, block, blockid..) and nothing else
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.
You are right and I agree that with this pr the common-types crate becomes a bit too “heavy”. We need to move some types out of the way on the path to disentangle machine from engine though but that’s not done in this pr so maybe best to undo this change here and redo it in the next pr (or do it better).
|
||
/// Ethash-specific extensions. | ||
#[derive(Debug, Clone)] | ||
pub struct EthashExtensions { |
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.
same 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.
a bunch of grumbles
use executive::Executed; | ||
use account_state::state::StateInfo; | ||
use trace::LocalizedTrace; | ||
use verification::queue::QueueInfo as BlockQueueInfo; | ||
use verification::queue::kind::blocks::Unverified; | ||
use verification::queue::kind::blocks::Unverified; // todo this is reexported from common_types |
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.
do you want to resolve the TODO in this PR?
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's do it in a separate one
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.
It’s fine to do in separate pr: it’s a matter of checking what uses the type outside ethcore.
I'll rebase this pr and fix review suggestions to get it in soon ;) |
"Engine error" | ||
} | ||
} | ||
|
||
/// Seal type. | ||
#[derive(Debug, PartialEq, Eq)] | ||
pub enum Seal { |
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.
Feels like Seal
and SealingState
should go together, no?
|
||
[dev-dependencies] | ||
rustc-hex= "1.0" | ||
rustc-hex= "1.0" # todo: only needed for CommonParams to do from_hex on a const. Remove? |
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.
that's fine for tests
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.
oh, yes, I should've removed the comment
This PR is a small step on the way to be able to extract the
Engine
trait from ethcore. The next step after this is probably to removeMachine
from the trait but there are several tricky types that need moving/deep thought too:State<StateDB>
which means it can't be moved tocommon-types
(circular ref.)WithState
variant which implies a dependency onMachine
.ethcore
because of how theExecute
variant is used.…and probably others.
Reviewers guide
PreverifiedBlock
and several machine related types:AuxiliaryData
,AuxiliaryRequest
,Call
,CommonParams
(here the crate gained way more code than I'd like: something we can perhaps fix with a trait), all error typesaccount-state
(and potentially others down the line)params()
function in theEngine
trait does not provide a default implementation anymore: the idea is that future PRs will remove the dependency onMachine
all-together.