From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46562) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNE0y-0006tS-DI for qemu-devel@nongnu.org; Thu, 06 Aug 2015 01:46:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZNE0s-0000Jn-Ep for qemu-devel@nongnu.org; Thu, 06 Aug 2015 01:46:52 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57291) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNE0s-0000JB-9r for qemu-devel@nongnu.org; Thu, 06 Aug 2015 01:46:46 -0400 From: Markus Armbruster References: <1438703896-12553-1-git-send-email-armbru@redhat.com> <1438703896-12553-3-git-send-email-armbru@redhat.com> <55C1343F.5060003@redhat.com> <87io8uuuc7.fsf@blackfin.pond.sub.org> <55C21D6D.2080106@redhat.com> Date: Thu, 06 Aug 2015 07:46:43 +0200 In-Reply-To: <55C21D6D.2080106@redhat.com> (Eric Blake's message of "Wed, 5 Aug 2015 08:27:57 -0600") Message-ID: <87mvy5j7ek.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH RFC v3 02/32] qapi: New QAPISchema intermediate reperesentation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: kwolf@redhat.com, berto@igalia.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com Eric Blake writes: > On 08/05/2015 12:23 AM, Markus Armbruster wrote: >> Eric Blake writes: >> >>> On 08/04/2015 09:57 AM, Markus Armbruster wrote: >>>> The QAPI code generators work with a syntax tree (nested dictionaries) >>>> plus a few symbol tables (also dictionaries) on the side. >>>> > >>>> +class QAPISchemaArrayType(QAPISchemaType): >>>> + def __init__(self, name, info, element_type): >>>> + QAPISchemaType.__init__(self, name, info) >>>> + assert isinstance(element_type, str) >>>> + self.element_type_name = element_type >>>> + self.element_type = None >>>> + def check(self, schema): >>>> + self.element_type = schema.lookup_type(self.element_type_name) >>>> + assert self.element_type >>> >>> Is it worth adding: >>> >>> assert not isinstance(self.element_type, QAPISchemaArrayType) >>> >>> since we don't allow 2D arrays? >> >> If the generators actually rely on it, yes. > > Hmm. What happens if you do > { 'command': 'Foo', 'returns': [ 'intList' ] } > >> >> If it's just an arbitrary schema language restriction, probably no. > > That's a tough judgment call. We don't currently allow [ [ 'int' ] ], > and the [ 'intList' ] hack is gross. On the other hand, I'm having a > tough time coming up with technical reasons why we can't do it (arrays > as a parameter or return type should work, and 2D arrays just add > another layer of '*' to the C code). Perhaps a quick experiment can decide the nature of the restriction. >>>> + def _make_array_type(self, element_type): >>>> + name = element_type + 'List' >>>> + if not self.lookup_type(name): >>>> + self._def_entity(QAPISchemaArrayType(name, None, element_type)) >>>> + return name >>> >>> Hmm - we probably have collisions if a user tries to explicitly name a >>> 'struct' or other type with a 'List' suffix. Not made worse by this >>> patch and not an actual problem with any of our existing .json files, so >>> we can save it for another day. >> >> qapi-code-gen.txt reserves the 'Kind' suffix. >> >> We should either adopt a sane, non-colliding scheme for generated names, >> or prevent collisions by rejecting reserved names with a sane error >> message (documenting them is then optional), or document reserved names. >> The latter two require us to figure out what names we reserve. But as >> you say, it's a task for another day. > > And that cleanup can worry about [ 'intList' ]. Yes.