[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH RFC v3 02/32] qapi: New QAPISchema intermediate
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [PATCH RFC v3 02/32] qapi: New QAPISchema intermediate reperesentation |
Date: |
Wed, 5 Aug 2015 08:27:57 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 |
On 08/05/2015 12:23 AM, Markus Armbruster wrote:
> Eric Blake <address@hidden> 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).
>>> + 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' ].
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
- [Qemu-devel] [PATCH RFC v3 04/32] qapi: New QAPISchemaVisitor, (continued)
[Qemu-devel] [PATCH RFC v3 08/32] Revert "qapi: Generate comments to simplify splitting for review", Markus Armbruster, 2015/08/04
[Qemu-devel] [PATCH RFC v3 12/32] qapi-commands: Convert to QAPISchemaVisitor, Markus Armbruster, 2015/08/04
[Qemu-devel] [PATCH RFC v3 18/32] qapi: Replace dirty is_c_ptr() by method c_null(), Markus Armbruster, 2015/08/04
[Qemu-devel] [PATCH RFC v3 13/32] qapi: De-duplicate enum code generation, Markus Armbruster, 2015/08/04
[Qemu-devel] [PATCH RFC v3 23/32] qapi: De-duplicate parameter list generation, Markus Armbruster, 2015/08/04