Skip to content
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

Generic structs not supported #87

Open
ISSOtm opened this issue Oct 21, 2022 · 7 comments
Open

Generic structs not supported #87

ISSOtm opened this issue Oct 21, 2022 · 7 comments

Comments

@ISSOtm
Copy link

ISSOtm commented Oct 21, 2022

Hi!
I'm trying to use modular_bitfield for an array of registers, which all follow the same format, but I'd like them to have different types.

Thus, I have written the following:

#[bitfield]
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
/// C1MASKm – MASK REGISTER m, (m = 0 TO 31)
pub struct C1MASKm<const m: u8> {
    pub msid: B11,
    pub meid: B18,
    pub msid11: bool,
    pub mide: bool,
    #[skip]
    __: B1,
}

However, I get this:

error: encountered invalid generic bitfield struct
    --> src/register.rs:4000:1
     |
4000 | / #[derive(Debug, Clone, Copy, PartialEq, Eq)]
4001 | | /// C1MASKm – MASK REGISTER m, (m = 0 TO 31)
4002 | | pub struct C1MASKm<const m: u8> {
...    |
4007 | |     __: B1,
4008 | | }
     | |_^

...which appears to mean that only non-generic structs are supported. It would be nice if this was the case (by copying the struct's generic arguments & where constraints), but before I work on adding support, are there any obvious caveats or blockers?

Thanks!

@Robbepop
Copy link
Owner

This crate was designed and implemented long before Rust got its generic constant types. I cannot tell for sure how much work it would be to support this. Also this crate is currently unmaintained unfortunately.

@ISSOtm
Copy link
Author

ISSOtm commented Oct 21, 2022

Well, I'm expecting an implementation to work on any generic type, by making the impls themselves generic; it shouldn't be much work, Generics::split_for_impl() does most of the heavy lifting already (example).

When you say it's unmaintained, do you mean you aren't planning on making any modifications yourself, or that you wouldn't merge an eventual PR? If the former, I'm willing to make the change myself.

@Robbepop
Copy link
Owner

Robbepop commented Oct 21, 2022

Ideally someone would fork this crate and implement all the tons of feature requests that are already in the pipeline. If the fork is successful I'd totally support it by advertising it from this crate.

@ISSOtm
Copy link
Author

ISSOtm commented Oct 21, 2022

I'm probably being nerd-sniped, but I also really want this feature... wouldn't co-maintaining the crate be easier?

@Robbepop
Copy link
Owner

Robbepop commented Oct 21, 2022

I do not have the energy to maintain this crate at the moment. Otherwise I would do it since it is a pretty nice utility and of use to many people out there.

@Robbepop
Copy link
Owner

Maybe some day in the future I will have energy to maintain this crate again and will come back if there was not already a successor crate then.

@ISSOtm
Copy link
Author

ISSOtm commented Oct 21, 2022

I understand, but I dislike forks—I'm not even sure how to name it—but if you don't have the energy to review PRs, then that's okay. I'll figure something out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants