-
Notifications
You must be signed in to change notification settings - Fork 264
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
Add examples to key
module
#376
Conversation
7c6de93
to
f003b08
Compare
src/key.rs
Outdated
/// # #[cfg(feature="rand")] { | ||
/// use secp256k1::{rand, SecretKey}; |
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.
rand isn't really used 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.
Oh cheers, I've not worked out how to lint the examples yet.
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 haven't tried it but I'd expect --all-targets
on cargo clippy
to include rustdoc.
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 only learned during this PR that -all-targets
does not include docs (I have my editor configured to run clippy with --all-targets
, thanks Lucas :)
/// let mut public_key = key_pair.public_key(); | ||
/// let original = public_key; | ||
/// let parity = public_key.tweak_add_assign(&secp, &tweak).expect("Tweak error"); | ||
/// assert!(original.tweak_add_check(&secp, &public_key, parity, tweak)); |
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.
Too bad we don't have access to a hash function to showcase this properly :(
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.
What did you have in mind? We can access bitcoin_hashes
here.
Sorry for the long review, it's easy to bikeshed over documentation |
No apology needed, I appreciate the comments. Documentation is definitely a funny thing, its easy to agree we need it not so easy to agree how it should be done. That's why I tried to stick meticulously to Rust conventions. (I've not written that much thorough Rust documentation in the past though so I'm still learning.) |
f003b08
to
6d3919a
Compare
@elichai I fixed all the 'should have been found by the linter' issues and squashed them into the original commit ( |
6d3919a
to
5e660fe
Compare
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.
Nice work.
/// # #[cfg(feature="rand")] { | ||
/// use secp256k1::{rand, Secp256k1, SecretKey}; | ||
/// | ||
/// let secp = Secp256k1::new(); | ||
/// let secret_key = SecretKey::new(&mut rand::thread_rng()); | ||
/// # } |
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.
Nice idea with the scope. Untested idea that might also work (note the #!
):
/// # #[cfg(feature="rand")] { | |
/// use secp256k1::{rand, Secp256k1, SecretKey}; | |
/// | |
/// let secp = Secp256k1::new(); | |
/// let secret_key = SecretKey::new(&mut rand::thread_rng()); | |
/// # } | |
/// # #![cfg(feature="rand")] | |
/// use secp256k1::{rand, Secp256k1, SecretKey}; | |
/// | |
/// let secp = Secp256k1::new(); | |
/// let secret_key = SecretKey::new(&mut rand::thread_rng()); |
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 doesn't work with Rust 1.29 unfortunately. I think, IIRC, it starts working at 1.34. I'll add a TODO to remove them after bump of MSRV.
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.
Fail! I did not 'note the !#
' even when you told me too. It is hard to get good help :)
Updating this PR to include this suggestion.
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.
Bother, and I thought the saying was 'if it builds ship it' ... turns out the !#
suggestion builds just fine but doesn't run.
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 that is weird. Should go back to testing my suggestions before making 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.
Not at all, open suggestions lead to leaning stuff. And since they are cheaper to make than tested suggestions it leads to more information being shared, IMO.
e81c6ef
to
4a40a6a
Compare
After re-visiting this I've squashed all the suggested changes into the one commit |
4a40a6a
to
694e46f
Compare
Improve method docs by doing: - Remove 'batch' comment - Remove mention of required features, docs already show this - Use links to types as well as ticks
Improve the main docs by doing: - Remove unneeded `self` from use statement - Add code ticks to `bitcoin_hashes`
Use 'standard' stlye, standard is defined as - No markdown heading - Full sentence (capital first letter and full stop) - Trailing empty comment line
Done in an effort to better test our public API. Add tests in the `Examples` section as is idiomatic in the Rust ecosystem. Make other minor improvements to any rusdocs we touch: - Use full stops - Use 100 character column width - Use plural third person tense - Use plural for section headings
We recently patched much of the docs in the `key` module, lets attempt to attain perfection. Improve docs by doing: - Use full stops - Use 100 character column width - Use plural third person tense - Use plural for section headings - Fix any grammar mistakes - Use code ticks and links as appropriate
694e46f
to
aa828f0
Compare
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.
ACK aa828f0
This is amazing, thanks!
Cheers man! |
aa51638 update changelog for 0.22.0 (Andrew Poelstra) d06dd20 update fuzzdummy API to match normal API (Andrew Poelstra) f3d48a2 update "should terminate abnormally" test to trigger a different ARG_CHECK (Andrew Poelstra) 8294ea3 secp256k1-sys: update upstream library (Andrew Poelstra) 2932179 secp256k1-sys: update secp256k1.h.patch (Andrew Poelstra) Pull request description: Should wait on merging until we get a minor release out with #382 and #376. May also want to bundle #380 with this? ACKs for top commit: real-or-random: ACK aa51638 I can't judge if the feature set is meaningful but this release PR is fine Tree-SHA512: e7f48b402378e280a034127f2de58d3127e04303a114f07f294fa3d00c0a083ae0d43375a8a74d226b13ea45fb3fde07d8450790e602bbf9581adc5fd8bc7d29
This PR is an initial attempt to more thoroughly test our public API.
Add examples to various types/methods/functions in the key module.
I'm not entirely sure when is enough, do we want an example on every single public method, function, and type or is this overkill. In this PR I tried to find a balance by doing ever method/function that took an argument that is a custom type from this lib. I think this should be extended to include return values too though ...
Thanks to @thomaseizinger for the idea!
First 2 patches are docs improvements to
lib.rs
.