Skip to content

Conversation

devrandom
Copy link
Member

No description provided.

@codecov
Copy link

codecov bot commented Aug 1, 2021

Codecov Report

Merging #1028 (c483d85) into main (bee9a1e) will increase coverage by 0.02%.
The diff coverage is 95.13%.

❗ Current head c483d85 differs from pull request most recent head 32d13a2. Consider uploading reports for the commit 32d13a2 to get more accurate results
Impacted file tree graph

@@            Coverage Diff             @@
##             main    #1028      +/-   ##
==========================================
+ Coverage   90.80%   90.82%   +0.02%     
==========================================
  Files          60       61       +1     
  Lines       31460    31458       -2     
==========================================
+ Hits        28568    28573       +5     
+ Misses       2892     2885       -7     
Impacted Files Coverage Δ
lightning/src/ln/onion_route_tests.rs 97.11% <ø> (ø)
lightning/src/routing/router.rs 95.94% <0.00%> (ø)
lightning/src/util/chacha20.rs 95.37% <ø> (ø)
lightning/src/chain/keysinterface.rs 95.36% <50.00%> (ø)
lightning/src/ln/msgs.rs 88.86% <88.88%> (+0.16%) ⬆️
lightning/src/util/ser.rs 92.11% <94.44%> (ø)
lightning/src/chain/channelmonitor.rs 90.80% <100.00%> (ø)
lightning/src/chain/onchaintx.rs 94.19% <100.00%> (ø)
lightning/src/chain/package.rs 92.27% <100.00%> (ø)
lightning/src/lib.rs 100.00% <100.00%> (ø)
... and 18 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bee9a1e...32d13a2. Read the comment docs.

@devrandom
Copy link
Member Author

Completes the work started in #842

[dependencies]
bitcoin = "0.27"
bitcoin = { version = "0.27", default-features = false, features = ["secp-recovery"] }
# TODO maybe bitcoin no-std should pull in this feature?
Copy link
Collaborator

Choose a reason for hiding this comment

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

Yes, it absolutely should.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'll submit that to rust-bitcoin, and clean up here in a followup PR after it's released?

Copy link
Member Author

Choose a reason for hiding this comment

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

Opened rust-bitcoin/rust-bitcoin#637 to address this

[dev-dependencies.bitcoin]
version = "0.27"
features = ["bitcoinconsensus"]
default-features = false
Copy link
Collaborator

Choose a reason for hiding this comment

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

Given we rely on libbitcoinconsensus, do we need this?

Copy link
Member Author

Choose a reason for hiding this comment

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

Are you saying that libbitcoinconsensus is dependent on std anyway, so there's no point in turning it off? shouldn't that library be made no_std?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Hmm, yea, I guess it could be made no_std eventually, though I doubt anyone is gonna sit down and fight to get it there.

Copy link
Member Author

Choose a reason for hiding this comment

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

So if I remove default-features = false then cargo test --no-default-features --features no_std fails. I think that's because the bitcoin crate has the std feature on, but this crate doesn't, so there's a mismatch in the bitcoin API signatures.

@devrandom devrandom force-pushed the 2021-08-no-std branch 3 times, most recently from 4f3eef9 to 34fe1e5 Compare August 2, 2021 14:40
pub use alloc::borrow::ToOwned;
pub use alloc::string::ToString;

pub use io_extras::read_to_end;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Just personal preference, but I'm really not a fan of transparently including functions in prelude - it makes it somewhat unclear where they're coming from in code using it. Can we instead export copy from io_extras and then explicitly use copy and read_to_end from io_extras in files that use them?

Copy link
Member Author

Choose a reason for hiding this comment

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

Agreed. Moving those and also sink.

#[cfg(any(test, feature = "_test_utils"))] extern crate hex;
#[cfg(any(test, feature = "fuzztarget", feature = "_test_utils"))] extern crate regex;

#[cfg(feature = "no_std")] extern crate core2;
Copy link
Contributor

Choose a reason for hiding this comment

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

This line uses core2 under feature = no_std but core2 is also used below as not(feature = std). Should they be unified?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I wonder if we should almost always use not(feature = std), as, if both are set, we really just want to use std::io because it probably means someone should/will set the core2/std flag.

Copy link
Member Author

Choose a reason for hiding this comment

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

Done

@devrandom
Copy link
Member Author

I addressed the comments. I also pushed a commit that renames the no_std feature to no-std, to match rust-bitcoin and the kebab convention.

matches rust-bitcoin
@TheBlueMatt TheBlueMatt merged commit 57feb26 into lightningdevkit:main Aug 3, 2021
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.

3 participants