Re: [Qemu-devel] [PATCH RFC v3 02/32] qapi: New QAPISchema intermediate reperesentation

[Markus Armbruster]

Eric Blake <address@hidden> writes:

> 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).

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.