On Mon, May 05, 2025 at 11:04:31AM +0200, Paolo Bonzini wrote:
> Date: Mon, 5 May 2025 11:04:31 +0200
> From: Paolo Bonzini <pbonz...@redhat.com>
> Subject: [PATCH 06/11] rust: use MaybeUninit::zeroed() in const context
> X-Mailer: git-send-email 2.49.0
>
> Reviewed-by: Manos Pitsidianakis <manos.pitsidiana...@linaro.org>
> Signed-off-by: Paolo Bonzini <pbonz...@redhat.com>
> ---
> docs/devel/rust.rst | 4 --
> rust/hw/timer/hpet/src/fw_cfg.rs | 6 +-
> rust/qemu-api/src/zeroable.rs | 104 +++++--------------------------
> 3 files changed, 18 insertions(+), 96 deletions(-)
LGTM,
Reviewed-by: Zhao Liu <zhao1....@intel.com>
...
> -/// The need for a manual implementation is only because `zeroed()` cannot
> -/// be used as a `const fn` prior to Rust 1.75.0. Once we can assume a new
> -/// enough version of the compiler, we could provide a `#[derive(Zeroable)]`
Do we still need `#[derive(Zeroable)]`? I think at least it can help
HPETFwEntry & HPETFwConfig and reduces manual blanket implementation.
> -/// macro to check at compile-time that all struct fields are Zeroable, and
> -/// use the above blanket implementation of the `ZERO` constant.
> +/// behavior.
> ///
...
> +unsafe impl Zeroable for crate::bindings::Property__bindgen_ty_1 {}
> +unsafe impl Zeroable for crate::bindings::Property {}
> +unsafe impl Zeroable for crate::bindings::VMStateFlags {}
> +unsafe impl Zeroable for crate::bindings::VMStateField {}
> +unsafe impl Zeroable for crate::bindings::VMStateDescription {}
> +unsafe impl Zeroable for crate::bindings::MemoryRegionOps__bindgen_ty_1 {}
> +unsafe impl Zeroable for crate::bindings::MemoryRegionOps__bindgen_ty_2 {}
> +unsafe impl Zeroable for crate::bindings::MemoryRegionOps {}
> +unsafe impl Zeroable for crate::bindings::MemTxAttrs {}
> +unsafe impl Zeroable for crate::bindings::CharBackend {}
Anyway, `#[derive(Zeroable)]` can't help these types from
crate::bindings::*.
Thanks,
Zhao
