Constify bitfield constructor for Rust 1.57+

[hugwijst]

Allows creating structs with bitfields in a const context, for example:

static FIRST: bindings::bitfields::First = bindings::bitfields::First {
    _bitfield_align_1: [],
    _bitfield_1: bindings::bitfields::First::new_bitfield_1(1, 2, 3),
};

This can be useful when interacting with existing C libraries in a bare-metal environment, as these sometimes expect global structs with specific symbols to exist.

The current workaround is to create a mutable struct with the bitfield assigned to something like __BindgenBitfieldUnit::new([0; 2]), and then call the appropriate field setters before the struct gets used. This has multiple downsides:

1. It requires hard-coding the size of the storage array of __BindgenBitfieldUnit.
2. It requires the struct to be mutable, which would require the use of unsafe if the struct also has to be static.
3. It increases the code size.

[hugwijst]

Could be lowered to 1.56 (gated by constification of core::mem::transmute) if we are okay with removing the debug_asserts! in the generated code.

[hugwijst]

r? @fitzgen

[kulp]

@hugwijst I like const fns, but can you explain the motivation? Without a PR description I wonder how to evaluate whether this is worth the added complexity.

[rockboynton]

@hugwijst I like const fns, but can you explain the motivation? Without a PR description I wonder how to evaluate whether this is worth the added complexity.

@kulp, I can provide an example. A lot of C APIs require there to be global (mutable) struct variables and these structures may have bitfields.

In order to mimic this in Rust, we need to use static mut VAR: Type = Type {}. But since bitfields don't have a const constructor, that definition would need some dummy values, and use a bunch of setter functions later in the code.

This change lets the entire structure to be defined initially, as it is in C.

Hopefully that provides some context 🙂

[hugwijst]

@hugwijst I like const fns, but can you explain the motivation? Without a PR description I wonder how to evaluate whether this is worth the added complexity.

I've updated the PR description, happy to discuss alternatives too.

[rockboynton]

bump

[kulp]

Thanks @rockboynton for more explanation. I am sorry for the long delays.

It feels like a lot of code changes to me for what it yields, but I will not pretend I am equipped to weigh the trade-offs here.

Maybe @pvdrz or @amanjeev or @emilio will have some wisdom.

[pvdrz]

👋 I think this is a nice addition!

I'm wondering if there's a way to avoid having both set_bit_const and set_bit available at the same time as it would be a bit confusing having two functions that do basically the same. Sadly, we cannot make the original set_bit a const fn because it uses &mut self and it indexes a slice and not an array from what I see. We could do two changes:

1. We could change set_bit to do things by-value instead of by-ref and this would make both set_bit and set_bit_const interchangeable almost everywhere. This would be a breaking change so we would need to put that into account.

2. Another change we could do is change the bitfield struct definition so it uses [u8; N] instead of the generic Storage. But this would break code generation for any rust target that doesn't have const generics.

I would suggest to do change 1 and then do change 2 behind version 1.57 so most people can transition from the non-const version to the const version if they update the rust version. Take this suggestion with a grain of salt as I don't have the last word on this matter 😅

I would merge this without this suggestion anyway.

[krukai]

Any update on this? We are actually relying on @hugwijst's fork right now and it would be great to see it merged.

[bors-servo]

☔ The latest upstream changes (presumably 2034a0f) made this pull request unmergeable. Please resolve the merge conflicts.

[kulp]

FYI, the current PR's closure may or may not have been intended. @pvdrz can comment.