Il mar 6 mag 2025, 04:41 Manos Pitsidianakis <manos.pitsidiana...@linaro.org> ha scritto:
> > It's not about hot paths, it's more that 1) you cannot use From/Into in > > a "static"'s initializer 2) bilge relies a lot on non-const methods in > > its internal implementation, which makes it quite messy to use it in > > some places. See for example this thing for which I take all the blame: > > Yeah it's not nice that we can't use it in static/const initializers. [...] It has its pros and cons that's for sure... there are many crates that > let you define typed bitfields, I haven't looked into the current > state of the art lately. We should definitely move on to something > better if it exists now or in the future. > I tried using bitfield-struct. The definitions are a bit less polished than bilge but usage is the same, it is const friendly and has fewer dependencies. I don't think there's one that's clearly better, but we can look at the tradeoffs and decide. To streamline expressions on bit flags maybe we could have a macro like bits!(Interrupt: RX | TX) which expands to Interrupt.RX.union(Interrupt.TX), where union() is a const function (likewise for & or !). This should not be hard to write as a procedural macro, it's just a recursive descent parser. Oops, I forgot I had archived it because I moved development to > https://gitlab.com/epilys/qemu . I made it public again. Bear in mind > this was a WIP, basically my git stash but committed. > Understood. The nice thing to have would be to automatically derive the PropertyInfo from the type of the field. Paolo > BTW, if you need it to model reflection better I think it is acceptable > > to assume const_refs_to_static is present. > > > > Paolo > >
