Eric Blake <ebl...@redhat.com> writes:
> On 02/11/2018 03:35 AM, Markus Armbruster wrote:
>> The include directive permits modular QAPI schemata, but the generated
>> code is monolithic all the same. To permit generating modular code,
>> the front end needs to pass more information on inclusions to the back
>> ends. The commit before last added the necessary information to the
>> parse tree. This commit adds it to the intermediate representation
>> and its QAPISchemaVisitor. A later commit will use this to to
>> generate modular code.
>>
>> New entity QAPISchemaInclude represents inclusions. Call new visitor
>> method visit_include() for it, so visitors can see the sub-modules a
>> module includes.
>>
>> Note that unlike other entities, QAPISchemaInclude has no name, and is
>> therefore not added to entity_dict.
>>
>> New QAPISchemaEntity attribute @module names the entity's source file.
>> Call new visitor method visit_module() when it changes during a visit,
>> so visitors can keep track of the module being visited.
>>
>> Signed-off-by: Markus Armbruster <arm...@redhat.com>
>> Reviewed-by: Marc-André Lureau <marcandre.lur...@redhat.com>
>> ---
>> @@ -1479,16 +1497,19 @@ class QAPISchema(object):
>> self._entity_dict = {}
>> self._predefining = True
>> self._def_predefineds()
>> - self._predefining = False
>> self._def_exprs(exprs)
>> self.check()
>
> Why does self._predfining not need to be toggled anymore? Do we even
> need this variable any more...
>
>>
>> def _def_entity(self, ent):
>> # Only the predefined types are allowed to not have info
>> assert ent.info or self._predefining
>> - assert ent.name not in self._entity_dict
>
> ...and/or is this assert now worthless?
>
>
>> +++ b/tests/qapi-schema/comments.out
>> @@ -1,4 +1,5 @@
>> object q_empty
>> enum QType ['none', 'qnull', 'qnum', 'qstring', 'qdict', 'qlist', 'qbool']
>> prefix QTYPE
>> +module comments.json
>> enum Status ['good', 'bad', 'ugly']
>
> Based on the generated output, it looks like you can tell whether you
> are in the predefining stage by not having any module at all; the
> first visit_module call is what flips the switch that everything else
> is defined by a module and must therefore have associated info.
Editing accident. I started down the road you described, decided I lack
the time to reach its end, then failed to back out completely.
