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
