Re: [PATCH v2 10/16] scripts/qapi: add QAPISchemaType.is_predefined

Markus Armbruster
2026-02-25T08:45:04Z

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 2/25/26 08:33, Markus Armbruster wrote:
>> Paolo Bonzini <pbonzini@redhat.com> writes:
>>
>>> It is impossible to call is_implicit on an enum type from the visitor, because
>>> the QAPISchemaEnumType has already been exploded into its costituent fields.
>>
>> constituent
>>
>> Passing selected attributes instead of the entire object to its visitor
>> method limits what the visitor can do. This is both good and bad.
>> We've run into "bad" a couple of times. It's never been bad enough to
>> change the interface, though.
>>
>> Thoughts?
>
> I think that applies here, is_predefined() is a reasonable addition.
>
>>> The Rust backend is also not modular (yet?) so it is not possible to filter
>>> out the builtin module;
>>
>> Really?
>>
>> The visitors are all based on QAPISchemaVisitor. Protocol:
>>
>> .visit_begin()
>> for all modules:
>> .visit_module()
>> for all entities:
>> if .visit_needed():
>> .visit_FOO()
>> .visit_end()
>>
>> QAPISchemaModularCVisitor implements .visit_module() to generate code
>> per module. Its .write() skips builtin modules unless opt_builtins.
>
> ... because its .write() already builds multiple QAPIGen{C,H,Trace}, one
> per module. Here instead there is just one QAPIGenRs.
>
> Using multiple QAPIGenRs instances, one per module, would be hackish.

I was thinking of having .visit_module() save .is_builtin_module(name)
in self.in_builtin_module, then use that to recognize built-ins.

> I'd rather just go modular instead of that. I can take a look, since
> this series will be (early) 11.1 material anyway.

Modular C code generation reduces incremental build time massively.
Before, we suffered from "touch the schema, recompile the world". If
Rust would similarly profit, then I'm all for going modular. …