diff options
author | Paolo Bonzini <pbonzini@redhat.com> | 2025-06-03 17:45:39 +0200 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2025-06-05 20:24:51 +0200 |
commit | b4ff3cf34fa09b28a480870b98377bac183833c8 (patch) | |
tree | 0ac8a405bda48957853c97010b7bef084df4d695 /rust/hw | |
parent | e8fb9c91a3ea437bdddd1819e180f36112e41ae1 (diff) | |
download | qemu-b4ff3cf34fa09b28a480870b98377bac183833c8.zip qemu-b4ff3cf34fa09b28a480870b98377bac183833c8.tar.gz qemu-b4ff3cf34fa09b28a480870b98377bac183833c8.tar.bz2 |
rust: qemu-api: add bindings to Error
Provide an implementation of std::error::Error that bridges the Rust
anyhow::Error and std::panic::Location types with QEMU's Error*.
It also has several utility methods, analogous to error_propagate(),
that convert a Result into a return value + Error** pair. One important
difference is that these propagation methods *panic* if *errp is NULL,
unlike error_propagate() which eats subsequent errors[1]. The reason
for this is that in C you have an error_set*() call at the site where
the error is created, and calls to error_propagate() are relatively rare.
In Rust instead, even though these functions do "propagate" a
qemu_api::Error into a C Error**, there is no error_setg() anywhere that
could check for non-NULL errp and call abort(). error_propagate()'s
behavior of ignoring subsequent errors is generally considered weird,
and there would be a bigger risk of triggering it from Rust code.
[1] This is actually a violation of the preconditions of error_propagate(),
so it should not happen. But you never know...
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'rust/hw')
0 files changed, 0 insertions, 0 deletions