Closed ia0 closed 4 months ago
Using derive(CheckedBitPattern) unconditionally triggers the missing_docs lint. This seems to be because the generated FooBits type is public and without documentation. For example, if a crate using bytemuck would have the following src/lib.rs:
derive(CheckedBitPattern)
missing_docs
FooBits
bytemuck
src/lib.rs
//! foo. #![warn(missing_docs)] /// Foo. #[derive(Copy, Clone, bytemuck::CheckedBitPattern)] #[repr(C)] pub struct Foo { /// x. x: u8, }
There would be some FooBits public type generated as follow (according to cargo expand):
cargo expand
#[repr(C)] pub struct FooBits { x: <u8 as ::bytemuck::CheckedBitPattern>::Bits, }
This type does not have a documentation although Foo has one.
Foo
There are at least 3 options to solve this issue:
I'd love a PR for this.
I think option 3 is best, just add a docs line that the type is generated and doesn't need to be used by humans.
Using
derive(CheckedBitPattern)
unconditionally triggers themissing_docs
lint. This seems to be because the generatedFooBits
type is public and without documentation. For example, if a crate usingbytemuck
would have the followingsrc/lib.rs
:There would be some
FooBits
public type generated as follow (according tocargo expand
):This type does not have a documentation although
Foo
has one.There are at least 3 options to solve this issue:
Foo
forFooBits
.Foo
forFooBits
but slightly modify it to say that all bit patterns are valid.FooBits
stating that it's a version ofFoo
with only valid bit patterns.