-
Notifications
You must be signed in to change notification settings - Fork 1.7k
removed std reexports from util && fixed broken tests #6187
Conversation
this pr requires latest cargo |
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.
I've got a few questions but nothing sticks out as egregious. I'd be happy to approve this but I'll keep it as unapproved pending conversation on some of the comments.
@@ -924,10 +927,10 @@ mod tests { | |||
let addr = tap.insert_account("0".sha3().into(), "0").unwrap(); | |||
let mut parent_header: Header = Header::default(); | |||
parent_header.set_seal(vec![encode(&0usize).into_vec()]); | |||
parent_header.set_gas_limit(U256::from_str("222222").unwrap()); |
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.
Any particular reason for this? I'm not fussed, but I was under the impression that these were equivalent?
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.
from_str
requires us to import std::str::FromStr
. parse
does not and is more idiomatic
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.
parse
requires FromStr
, but I definitely agree that it's more idiomatic.
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 does not require the import of FromStr
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.
Ah, true, sorry my brain skipped over that word in your comment
use futures::{self, Future, BoxFuture}; | ||
use futures_cpupool::CpuPool; | ||
use ntp; | ||
use time::{Duration, Timespec}; | ||
use util::{Arc, RwLock}; | ||
use util::RwLock; |
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 is because it uses parking_lot
and not the stdlib RwLock
, right?
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.
yes
@@ -16,13 +16,13 @@ | |||
|
|||
//! Block header. | |||
|
|||
use std::cmp; | |||
use std::cell::RefCell; | |||
use util::*; | |||
use basic_types::{LogBloom, ZERO_LOGBLOOM}; | |||
use time::get_time; | |||
use rlp::*; |
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.
Probably not for this PR, but it'd be really nice if we could deglob everything apart from util
(and ideally, even util
). Better RLS refactoring support would make that way easier.
@@ -170,7 +170,7 @@ fn main() { | |||
fn display(keypair: KeyPair, mode: DisplayMode) -> String { | |||
match mode { | |||
DisplayMode::KeyPair => format!("{}", keypair), | |||
DisplayMode::Secret => format!("{:?}", keypair.secret()), | |||
DisplayMode::Secret => format!("{}", keypair.secret().to_hex()), | |||
DisplayMode::Public => format!("{:?}", keypair.public()), |
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.
If we're not using the debug display for Secret
, can we remove the debug display for Public
and Address
too? Since this is for displaying to a user these are a clear misuse of Debug
.
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.
I generally agree, but I believe it's not a scope of this pr. Here is why:
Publish
and Address
are just typenames for H512
and H160
whereas Secret
is a wrapper around H256
. Recently someone has changed the way Secret
is displayed and broke tests. Our CI hasn't catched that, cause it was not running ethkey-cli
tests... This change only makes our old tests pass...
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.
Ah, I see. Would be a nice issue to file.
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.
"secret: 17d08f5fe8c77af811caa0c9a187e668ce3b74a99acc3f6d976f075fa8e0be55 | ||
public: 689268c0ff57a20cd299fa60d3fb374862aff565b20b5f1767906a99e6e09f3ff04ca2b2a5cd22f62941db103c0356df1a8ed20ce322cab2483db67685afd124 | ||
address: 26d1ec50b4e62c1d1a40d16e7cacc6a6580757d5".to_owned(); | ||
"secret: aa22b54c0cb43ee30a014afe5ef3664b1cde299feabca46cd3167a85a57c39f2 |
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.
Any reason that these strings are different?
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.
Yes. In early version of ethkey
there was a bug in brainwallet generation. Those tests were written for bugged version and were never updated, cause the CI never run them
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.
Makes sense
ipfs/src/route.rs
Outdated
@@ -119,7 +119,8 @@ mod tests { | |||
use ethcore::client::TestBlockChainClient; | |||
|
|||
fn get_mocked_handler() -> IpfsHandler { | |||
IpfsHandler::new(None, None, Arc::new(TestBlockChainClient::new())) | |||
//IpfsHandler::new(None, None, Arc::new(TestBlockChainClient::new())) |
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 have git, we don't need to comment code (I assume this was an accident). Is this not compiling anymore? If it's unimplemented can we remove the function entirely?
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.
Agreed, I should have removed that line.
Yes, it's not compiling, and those tests were not run by our CI. Now this code is being compiled by CI, but the tests are excluded (using --exclude
) flag.
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.
I think my preference would be to leave the original code, uncommented. Just keep the code as similar as possible but --exclude
it. It doesn't matter really though, whatever you would prefer.
scripts/cov.sh
Outdated
@@ -20,8 +20,7 @@ if ! type $KCOV > /dev/null; then | |||
exit 1 | |||
fi | |||
|
|||
. ./scripts/targets.sh | |||
RUSTFLAGS="-C link-dead-code" cargo test $TARGETS --no-run || exit $? | |||
RUSTFLAGS="-C link-dead-code" cargo test --all --exclude ipfs --exclude evmjit --no-run || exit $? |
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.
Why do we exclude IPFS and EVMJIT (same for the doc
below)?
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.
They are broken and their tests are failing. Fixing them is out of scope
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.
I will create issues to track this
Ok, with the questions answered and the commented code fixed I'd say this LGTM |
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.
LGTM. CI is failing and there's merge conflicts, but all the issues I had are fixed.
changes:
std
reexports from util - we were rarely using more than 1-2 imported structsBloomable
trait to it's own crate -bloomable
table
andusing_queue
crates are now dependencies ofethcore
, notutil
scripts/*.sh
andtest.sh