Pull Request Test Coverage Report for Build 13082433226

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 83.292%

Totals
Change from base Build 13081092118:	0.0%
Covered Lines:	21032
Relevant Lines:	25251

💛 - Coveralls

Yes you are on the right track. While reviewing I noticed that it was not trivial to check the imports tested here against the ones done in units/tests/api.rs - perhaps this layout would be better (note I had to rustfmt::skip to keep the comments in the.

#[test]
fn api_can_use_all_types_from_module_block() {
    {
        // New types added in `primitives`.
        use bitcoin_primitives::block::{
            Block, BlockHash, Checked, Header, Unchecked, Version, WitnessCommitment,
        };
    }
    {
        // Re-exports from `units` - `primitives` module layout should mimic `units`.
        use bitcoin_primitives::block::{
            BlockHeight, BlockInterval, TooBigForRelativeBlockHeightError,
        };
    }
}

Yes you are on the right track. While reviewing I noticed that it was not trivial to check the imports tested here against the ones done in units/tests/api.rs - perhaps this layout would be better (note I had to rustfmt::skip to keep the comments in the.

#[test]
fn api_can_use_all_types_from_module_block() {
    {
        // New types added in `primitives`.
        use bitcoin_primitives::block::{
            Block, BlockHash, Checked, Header, Unchecked, Version, WitnessCommitment,
        };
    }
    {
        // Re-exports from `units` - `primitives` module layout should mimic `units`.
        use bitcoin_primitives::block::{
            BlockHeight, BlockInterval, TooBigForRelativeBlockHeightError,
        };
    }
}

Is there any reason why the primitives module should mimic the units but not the other way around?

Yes, because primitives depends on units but not the other way around.

Some structs like TapBranchTag that don't // All public types implement Debug (C-DEBUG). should not be considered in the primitives API surface, am I right?
@tcharding @apoelstra

Some structs like TapBranchTag that don't // All public types implement Debug (C-DEBUG). should not be considered in the primitives API surface, am I right? @tcharding @apoelstra

I currently get the following error when I include such structs

`TapBranchTag` doesn't implement `Debug`
the trait `Debug` is not implemented for `TapBranchTag`rustc[Click for full compiler diagnostic](rust-analyzer-diagnostics-view:/diagnostic message [1]?1#file:///home/innocent/Documents/qala/deliverables/rust-bitcoin/primitives/tests/api.rs)
api.rs(40, 10): Error originated from macro call here
bitcoin_primitives::taproot
pub struct TapBranchTag

Or alternatively, is it necessary to implement the Debug trait manually?

Some structs like TapBranchTag that don't // All public types implement Debug (C-DEBUG). should not be considered in the primitives API surface, am I right? @tcharding @apoelstra

I currently get the following error when I include such structs

`TapBranchTag` doesn't implement `Debug`
the trait `Debug` is not implemented for `TapBranchTag`rustc[Click for full compiler diagnostic](rust-analyzer-diagnostics-view:/diagnostic message [1]?1#file:///home/innocent/Documents/qala/deliverables/rust-bitcoin/primitives/tests/api.rs)
api.rs(40, 10): Error originated from macro call here
bitcoin_primitives::taproot
pub struct TapBranchTag

Or alternatively, is it necessary to implement the Debug trait manually?

@apoelstra @tcharding

cc @Kixunil shouldn't we just put the Debug bound on all the tag types so that we can do this derive?