Add attributes for ignore new(), into_bytes(), from_bytes() functions

[chabapok]

There is unwanted warnings if one of these function not called in client code.

[vext01]

Do I see it correctly that there's no way to silence these warnings, short of #![allow(dead_code)] at the module level?

[vext01]

Is there any harm in unconditionally marking the generated functions #[allow(dead_code)]? This would be a simple fix.

[chabapok]

#![allow(dead_code)] hide all dead code in that module. Therefore, I do not recommend using it. You may add something like drop(Foo::new().into_bytes()) somewhere in you code.

[vext01]

![allow(dead_code)] hide all dead code in that module. Therefore, I do not recommend using it.

Indeed, that's awful.

You may add something like drop(Foo::new().into_bytes()) somewhere in you code.

And I find this unsatisfying also.

Is there any harm in unconditionally marking the generated functions #[allow(dead_code)]? This would be a simple fix.

Why not do this? ^

[chabapok]

Yes, fixing this warning in that way is easy. But, it needs to be included in the crate code, not in the client code.

[vext01]

I'm on it now :)

[chabapok]

#[allow(dead_code)] is better than nothing - but leads to extra code in the object files. It would probably be correct to configure this behavior through attributes. Something like:

#[bitfield(with=(new, info_bytes))] /* but without from_bytes */
struct Foo {...}

or something like that.

But if you make a PR. As far as I understand, #[allow(dead_code)] is better than nothing. Anyway, this code is still there now. Advanced configuring may be in future.

[vext01]

@chabapok I've raised the PR, but to be honest this repo doesn't appear to be maintained and as a result, I'm reluctant to use it for anything. The tests were failing before I started, the rustfmt config doesn't work, no commits in over 2 years...

Hopefully upstream will prove me wrong.