Conversation
|
I'm not sure why the release job |
ee312da to
90a0bf6
Compare
90a0bf6 to
acd6a1f
Compare
|
All the force pushes are me rebasing on #1742 trying to get it past CI. |
acd6a1f to
33b04f4
Compare
sanket1729
left a comment
There was a problem hiding this comment.
concept ACK. Left one question
internals/src/error.rs
Outdated
There was a problem hiding this comment.
Why is this pub and why do we need a trait? Any drawbacks of creating this in #cfg(test) for this? We can also do this with function without the trait.
#[cfg(test)
fn assert_send_sync<T: Send + Sync + Debug> {}
macro_rules check_pub_error {
#[cfg(test)]
assert_send_sync<$type>();
}There was a problem hiding this comment.
It's pub because it's in internals and reused. We can define the function inside macro, hygiene should take care of conflicts. Unless someone can prove it slows down compilation.
There was a problem hiding this comment.
I ended up using a trait still but feature guarding so the trait is not built in in non-test builds. Ok?
There was a problem hiding this comment.
Sure. I am okay as long it is only in tests.
We should just check for |
|
Hmm, shitty. So @tcharding the reason CI is failing is that On the one hand, this is exactly what we want to happen (it's telling us that we can't release bitcoin without releasing internals fist). But on the other hand, we're about 48 hours into this release and we're already getting a failure from the CI job, so I guess we've gotta figure out how to get it to be yellow instead of red :) |
|
Sounds like detecting release PRs is a better solution. |
|
@tcharding could you try adding a commit which does that, to see if it makes CI pass? I think that wrapping the publish checks in |
4f2b992 to
b6ca19f
Compare
|
Spent more time playing with bash than I wanted to, will try and fix the release thing again tomorrow. |
b6ca19f to
27d1ec1
Compare
27d1ec1 to
928635d
Compare
internals/src/error.rs
Outdated
There was a problem hiding this comment.
Perhaps we should also check that no_std errors are still Send + Sync?
|
Neat! ACK. Part of me feels like bikeshedding the name, but this is good. Perhaps we should have similar macros for primitives e.g. to make sure that they all implement clone/partialeq/eq/hash/debug/display/fromstr. Unsure. At some point it gets unweildy to do this with macros that we have to remember to call inline. |
apoelstra
left a comment
There was a problem hiding this comment.
ACK 928635ded299622bb08436fc44fb7028b0377b3a
internals/src/error.rs
Outdated
There was a problem hiding this comment.
Still not super happy this is pub.
I would suggest the following changes:
- have a single macro and have a
($type:ty) => {};rule for non-test, non-empty rule for test - do Sanket's approach for methods, have one method
fn check_sendsync<T: Send + Sync>()andfn check_error<T: std::error::Error>()and gate the second on std.
Currently there is a bug that non-std test runs will not be able to build.
There was a problem hiding this comment.
I'm not happy about it either but seems less work for compiler (and compile times!). It's hidden which is a clear signal people shouldn't use it (and internals is also such signal). If anyone is insane enough to depend on it they deserve the consequences.
There was a problem hiding this comment.
I used you suggestions @stevenroose except I was unable to put an attribute on the arms of the macro so I kept the dummy macro for not test builds.
928635d to
b8c3cb2
Compare
|
Changes in force push:
I also checked that the macro is used for all errors (I grepped for |
5e4bead to
70054bc
Compare
|
I'm a little surprised that this works now without the functions being |
apoelstra
left a comment
There was a problem hiding this comment.
ACK 70054bcffa51a43e60fb11f0fb99035418b1c7f1
I was surprise also, I tried to work out why it works and I cannot. (Also the comment on |
internals/src/error.rs
Outdated
There was a problem hiding this comment.
Maybe we should use bare cfg, not feature, so this doesn't get pulled in when --all-features is used?
There was a problem hiding this comment.
I used #[cfg(trait_checks)] and I enabled it in all builds by exporting RUSFLAGS from the top level contrib/test.sh script.
There was a problem hiding this comment.
We should have at least one build without it in case something gets messed up.
There was a problem hiding this comment.
Oh yes, very good point.
internals/src/error.rs
Outdated
There was a problem hiding this comment.
Could also check Debug + Display for no_std.
There was a problem hiding this comment.
Done as a separate trait.
bitcoin/src/taproot.rs
Outdated
There was a problem hiding this comment.
Unrelated but it looks like this should be called HiddenNodesError or be withing an error module.
d442ed9 to
ba16ab7
Compare
|
Changes in force push:
|
ba16ab7 to
44b3ede
Compare
|
Changes in force push:
|
44b3ede to
4ceabb6
Compare
|
ooo, I had missed all the public errors that were structs (as opposed to enums). Now included. |
4ceabb6 to
7ecb4d1
Compare
|
Sweeet, macro finds to unusual error types, they were added in commit: I've added |
|
Good question, IIRC those errors are meant to be converted to |
7ecb4d1 to
981cb9b
Compare
|
I elected to implement |
bitcoin/src/consensus/serde.rs
Outdated
There was a problem hiding this comment.
I'm not totally sure on the best content to put in the error message of write_err, noting it here but can discuss on #1862.
981cb9b to
e48e282
Compare
We have two "helper" error types (used within serde code to hide implementation details) that do not implement the "standard" error traits that we implement. While not totally necessary it does not hurt to implement them, adding only a few lines of easy to maintain code. Implement `Display` and `std::error::Error` for helper error types in the `consensus::serde` module (`DecodeError` and `DecodeInitError`).
|
I rebased this one to fix merge conflicts, but to do the rebase properly I have to go through the whole codebase again and check no new errors were introduced since I last did this. I can't be bothered doing that right now. Can we just agree that this PR might miss adding the macro to some errors, and keep an eye out? |
e48e282 to
2dfce3f
Compare
Public errors are part of the public API, as such we need to be careful not to change them. One thing that is hard to notice is adding/removing `Send`/`Sync`. Add a macro that asserts that an error type implements `Send` and `Sync`. While we are at it, assert `Debug` is implemented as well because we would like all errors to implement `Debug`.
2dfce3f to
c406cc2
Compare
sanket1729
left a comment
There was a problem hiding this comment.
ACK c406cc2. This looks great. Did not check whether all parts are covered
|
Honestly now I'm a little tempted to scrap this PR in favor of just using some creative |
|
That's not a bad idea because it would put further "coding policy" things into the same place instead of having a bunch of macros that one must remember to call (assuming we come up with more things like that introduced here). |
|
Draft until #1880 resolves. |
|
Looks like we are going to use |
|
@tcharding it'd still be nice to have some tool to check that the API is good in the first place (e.g. an error type implements |
|
@Kixunil right -- after bringing in Unfortunately every specific rule we've thought of has had a bunch of exceptions :) but if you have ones in mind it'd be awesome to start doing it. Maybe in hex-conservative first where we have a much smaller API. |
|
Well, I think the one you mentioned doesn't have an exception. :) I'd throw in |
Public errors are part of the public API, as such we need to be careful not to change them. One thing that is hard to notice is adding/removing
Send/Sync.Add a macro that asserts that an error type implements
Send,Syncandstd::error::Error(feature guarded ontestandfeature = "std").Based on idea by @Kixunil: #1127 (comment)
Notes since first raising PR