On 2/25/26 09:44, Markus Armbruster wrote:
Paolo Bonzini <[email protected]> writes:
On 2/25/26 08:33, Markus Armbruster wrote:
Paolo Bonzini <[email protected]> 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.
Rust compiles by crate rather than file (crate == toplevel module), so
it would need some benchmarking but yeah I expect that to help. That
would mean something like
use qapi_block::*;
Paolo
