From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47677) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1elKoP-0001j5-Ds for qemu-devel@nongnu.org; Mon, 12 Feb 2018 15:34:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1elKoL-0004rv-9l for qemu-devel@nongnu.org; Mon, 12 Feb 2018 15:34:53 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:40716 helo=mx1.redhat.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1elKoL-0004rN-4M for qemu-devel@nongnu.org; Mon, 12 Feb 2018 15:34:49 -0500 References: <20180211093607.27351-1-armbru@redhat.com> <20180211093607.27351-18-armbru@redhat.com> From: Eric Blake Message-ID: Date: Mon, 12 Feb 2018 14:34:47 -0600 MIME-Version: 1.0 In-Reply-To: <20180211093607.27351-18-armbru@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 17/29] qapi: Record 'include' directives in intermediate representation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , qemu-devel@nongnu.org Cc: mdroth@linux.vnet.ibm.com, marcandre.lureau@redhat.com 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. >=20 > New entity QAPISchemaInclude represents inclusions. Call new visitor > method visit_include() for it, so visitors can see the sub-modules a > module includes. >=20 > Note that unlike other entities, QAPISchemaInclude has no name, and is > therefore not added to entity_dict. >=20 > 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. >=20 > Signed-off-by: Markus Armbruster > Reviewed-by: Marc-Andr=C3=A9 Lureau > --- > @@ -1479,16 +1497,19 @@ class QAPISchema(object): > self._entity_dict =3D {} > self._predefining =3D True > self._def_predefineds() > - self._predefining =3D False > self._def_exprs(exprs) > self.check() Why does self._predfining not need to be toggled anymore? Do we even=20 need this variable any more... >=20 > 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', 'qb= ool'] > prefix QTYPE > +module comments.json > enum Status ['good', 'bad', 'ugly'] Based on the generated output, it looks like you can tell whether you=20 are in the predefining stage by not having any module at all; the first=20 visit_module call is what flips the switch that everything else is=20 defined by a module and must therefore have associated info. --=20 Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org