On 10/02/2015 11:05 AM, Markus Armbruster wrote:
>> Might be doable, but then we'd have to generate the implicit object name
>> prior to creating its Member objects (thus splitting
>> _make_implicit_object_type() into two parts).
>
> def _make_implicit_object_type(self, name, role, members):
Eric Blake writes:
> On 10/02/2015 03:50 AM, Markus Armbruster wrote:
>> Eric Blake writes:
>>
>>> Future commits will migrate semantic checking away from parsing
>>> and over to the various QAPISchema*.check() methods. But to
>>> report an error message about an incorrect semantic use of a
>>
On 10/02/2015 03:50 AM, Markus Armbruster wrote:
> Eric Blake writes:
>
>> Future commits will migrate semantic checking away from parsing
>> and over to the various QAPISchema*.check() methods. But to
>> report an error message about an incorrect semantic use of a
>> member of an object type, w
Eric Blake writes:
> Future commits will migrate semantic checking away from parsing
> and over to the various QAPISchema*.check() methods. But to
> report an error message about an incorrect semantic use of a
> member of an object type, we need to know which type, command,
> or event owns the m
Future commits will migrate semantic checking away from parsing
and over to the various QAPISchema*.check() methods. But to
report an error message about an incorrect semantic use of a
member of an object type, we need to know which type, command,
or event owns the member. Rather than making all
