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

[Markus Armbruster <armbru@redhat.com>]

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.

[...]