Re: [PATCH 14/19] scripts/qapi: generate high-level Rust bindings

[Paolo Bonzini <pbonzini@redhat.com>]

On 12/9/25 11:03, Markus Armbruster wrote:
> * Why is util::qobject::QObject needed?
> 
> * NONE is an error value, not a valid QType.  Having such error values
>    in enums isn't unusual in C.  What about idiomatic Rust?  Even if it's
>    unusual there, we may elect to do it anyway, just to keep generated
>    Rust closer to C.  But it should be a conscious decision, not a blind
>    port from C to Rust.

For QType we don't need to keep it closer, but actually ABI-compatible: 
QType is defined by QAPI but is used (almost exclusively) by QObject. 
We use the C version in the QObject bindings, for example:

                 $($crate::bindings::QTYPE_QNULL => break $unit,)?

> * "Default for QType" is NONE.  In C, it's zero bytes, which boils down
>    to QTYPE_NONE.
> 
> * QTYPE__MAX is a bit of a headache in C.  It's not a valid enum value.
>    We make it one only because we need to know the largest valid enum
>    value, e.g. to size arrays, and the easiest way to get that value is
>    adding an invalid one to the enum.  Same for all the other generated
>    enums.  Could we avoid it in Rust?

Yes, I think so.

> * C has a file comment of the form
> 
>      /*
>       * One-line description of the file's purpose
>       *
>       * Copyright lines
>       *
>       * License blurb
>       */
> 
>    I think Rust could use such a comment, too.

Ok.

> * C has built-in types like QType in qapi-builtin-types.h, generated
>    only with -b.  This is a somewhat crude way to let code generated for
>    multiple schemas coexist: pass -b for exactly one of them.  If we
>    generated code for built-in types unconditionally into qapi-types.h,
>    the C compiler would choke on duplicate definitions.  Why is this not
>    a problem with Rust?

Because there's better namespacing, so it's okay to define the builtin 
types in more than one place.  However, do we need at all the builtin 
types in Rust?  QType is only defined in QAPI to have the nice enum 
lookup tables, and we can get it via FFI bindings.  Lists, as you say 
below, are not needed, and they are also a part of qapi-builtin-types.h.

So I think Rust does not need built-in types at all, which I think 
solves all your problems here (other than _MAX which can be removed).

> 
> * The Rust version doesn't have deallocation boilerplate.  Deallocation
>    just works there, I guess.
> 
> * The Rust version doesn't have the List type.  Lists just work there, I
>    guess.

Yep.

> * The Rust version doesn't have the implicit type q_obj_my_command_arg,
>    which is the arguments of my-command as a struct type.  C needs it for
>    marshaling / unmarshaling with visitors.  Rust doesn't, because we use
>    serde.  Correct?

Commands are not supported at all yet.

Paolo