On 10/13/2015 06:19 AM, Markus Armbruster wrote:
> Eric Blake <eblake@redhat.com> writes:
> 
>> A future patch will move some error checking from the parser
>> to the various QAPISchema*.check() methods, which run only
>> after parsing completes.  It will thus be possible to create
>> a python instance representing an implicit QAPI type that
>> parses fine but will fail validation during check().  Since
>> all errors have to have an associated 'info' location, we
>> need a location to be associated with those implicit types.
>> The intuitive info to use is the location of the enclosing
>> entity that caused the creation of the implicit type; similar
>> to what was done for array types in an earlier patch.
>>

>> +++ b/scripts/qapi.py
>> @@ -793,9 +793,9 @@ class QAPISchemaEntity(object):
>>          # For explicitly defined entities, info points to the (explicit)
>>          # definition.  For builtins (and their arrays), info is None.
>>          # For other arrays, info points to an explicit place that uses
>> -        # the array (there may be more than one such place).
>> -        # TODO For other implicitly defined entities, it should point to
>> -        # a place that triggers implicit definition.
>> +        # the array (there may be more than one such place).  For other
>> +        # implicitly defined entities, it points to the place that
>> +        # triggered the implicit definition.
> 
> How does info for implicitly defined arrays differ from info for other
> implicitly defined entities?  I suspect it doesn't, and this comment
> should become simpler:
> 
>         # For explicitly defined entities, info points to the (explicit)
>         # definition.  For builtins (and their arrays), info is None.
>         # For implicitly defined entities, info points to a place that
>         # triggered the implicit definition (there may be more than one
>         # such place).
> 

Works for me.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org