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. [...]
