-
Notifications
You must be signed in to change notification settings - Fork 275
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
Update the code to edition 2018, and update dependencies #331
Conversation
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.
Thank you for doing this, looking forward to dropping old rand dependencies in our project :)
src/ecdh.rs
Outdated
use crate::Secp256k1; | ||
|
||
use super::SharedSecret; |
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'd recommend we move to starting every test module with use super::*
. In most cases, that will bring in all the types required for the tests.
0a096c7
to
e6dc0b2
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.
utACK e6dc0b2
Didn't review but I randomly noticed that we could change |
Cool! concept ACK. Will review in detail later. I think there is nothing stopping us merging this now? For rust-bitcoin I want a taproot release before the 2018 release, but I believe we don't need any further supporting changes from rust-secp for Taproot? |
e6dc0b2
to
bde5f3a
Compare
match data.len() { | ||
constants::SECRET_KEY_SIZE => { | ||
let mut ret = [0; constants::SECRET_KEY_SIZE]; | ||
match <[u8; constants::SECRET_KEY_SIZE]>::try_from(data) { |
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.
In general TryFrom
should be used to implement fallible conversion, try_into()
to call fallible conversion. (because TryFrom
implies TryInto
) I think it's OK when the types are not generic but maybe keeping the good habit is worth changing?
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.
IMHO try_into
hides information into which specific type the conversion happens and makes code less readable / verifiable by human
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.
@Kixunil I don't think that is generally true. AFAIK it is idiomatic to prefer TryInto
over TryFrom
but if you are not doing trait-bounds at all, TryFrom
might be better because it doesn't need type annotations.
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 possible:
let x: Type = y.try_into()?;
But I think TryFrom
is OK in this case.
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.
The commit message of the final commit (bde5f3a Use new trait TryInto and do small refactoring
is now out of date (should be 'TryFrom'). Also there is one lint warning still on this PR
warning: unused import: `fmt`
--> secp256k1-sys/src/types.rs:2:12
|
2 | use core::{fmt, mem};
| ^^^
|
= note: `#[warn(unused_imports)]` on by default
Apart from that, LGTM :)
.github/workflows/rust.yml
Outdated
@@ -60,7 +60,7 @@ jobs: | |||
strategy: | |||
matrix: | |||
rust: | |||
- 1.29.0 | |||
- 1.36.0 |
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.
Does it make any difference if this is 1.36
as opposed to 1.36.0
? Said another way, will anything be added to a later patch version of 1.36
that we should be enforcing the usage of? I don't know the answer I'm just wondering.
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.
One thing I noticed in the past, running cargo +1.36 build
didn't work while cargo +1.36.0
did, so maybe this has the same interface.
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 mean didn't work as in the build failed? If so then that would validate my question and we should decide whether we are enforcing 1.36.0
or latest 1.36.*
, right?
FTR I have been testing using cargo +1.36 check
.
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 said unknown toolchain or something like that. But TBH it was a long ago, maybe it changed to support it.
We do actually need to do a rust-secp release for Taproot, so delaying this until the next major rev. Also, needs rebase. |
In case you want to save yourself some work @elichai I was playing around with this branch and it took me quite a while to rebase it. Feel free to grab what I have done to save yourself having to do it. Same branch name on my tree ( |
6eb22e5
to
a2d43df
Compare
Have I had a git fail @elichai and pushed to your branch? Super sorry if I did, I did not realize |
Anyways, there is a branch on my tree now that has been updated to do two things
|
No you didn't push here, Thanks for your rebase it helped to make sure I'm rebasing correctly (still rebased myself as to know what actually changed)
Does that change anything here? |
Does not change the patch set AFAICT except for the actual version number itself and the commit messages. |
Hey @elichai, no clue what order the MSRV patches are going to merge across the rust-bitcoin stack but we are in the vicinity of ready to merge this one, have you time to update the PR? |
I was messing around with rust-bitcoin/rust-bitcoin#967 and chased build errors into secp, then into |
I'll rebase today-tomorrow |
First push is a rebase, and the second one is fixing the nits |
src/schnorr.rs
Outdated
@@ -139,8 +135,7 @@ impl<C: Signing> Secp256k1<C> { | |||
#[cfg(any(test, feature = "rand-std"))] | |||
#[cfg_attr(docsrs, doc(cfg(feature = "rand-std")))] | |||
pub fn sign_schnorr(&self, msg: &Message, keypair: &KeyPair) -> Signature { | |||
let mut rng = thread_rng(); | |||
self.sign_schnorr_with_rng(msg, keypair, &mut rng) | |||
self.schnorrsig_sign_with_rng(msg, keypair, &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.
In f792674:
schnorrsig_sign_with_rng
is deprecated; we should use the other method
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.
IMO this is blocking merge.
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.
@elichai I am happy to merge this once you address 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.
Sorry, missed the notification on this
@@ -162,9 +163,8 @@ impl SecretKey { | |||
/// ``` | |||
#[inline] | |||
pub fn from_slice(data: &[u8])-> Result<SecretKey, Error> { | |||
match data.len() { |
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.
In ac8e966:
Maybe worth thinking about turning these from_slice
methods into TryFrom
impls entirely ... doesn't need to be 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.
FWIW I rekon we should keep this PR as lean as possible to help expedite review/merge.
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 2f18866 aside from nits
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 2f18866
Oh, @elichai, I just noticed the PR description mentions 1.36 still. |
This is the last on to go and we have done it, friendly bump please reviewers :) |
Hi, can I ask when this PR is planned to be merged and a new version containing the PR will be released? |
@koushiro we hope for it to be faster than usual but it'll probably still take some time. |
As far as I understand it, soon as this PR merges we can start releasing each of the crates in the rust-bitcoin stack starting at the bottom. |
Friendly bump, can we get an ack on this from another maintainer please. (I don't actually know who are the maintainers of this crate? @real-or-random, @jonasnick). Is that what you are waiting for to merge this @apoelstra? |
I am waiting for the use of |
Fixed, sorry that it took me so long |
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 5d2f1ce
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 5d2f1ce
As proposed in rust-bitcoin/rust-bitcoin#510 (comment) this PR raises the MSRV to 1.41.1 it also changes the code to be Edition 2018.
The PR contains a few things:
core::ffi::c_void
rand
version to latest and modifying ourRngCore
implementations accordinglyTryInto
trait where it makes the code nicerIf people prefer I can split this PR into multiple and/or drop some commits