On 09/29/2015 02:02 AM, Markus Armbruster wrote: >>>> While at it, we were always passing None as the location of >>>> array types, making that parameter useless; sharing the >>>> location (if any) of the underlying element type makes sense. >>> >>> The parameter is useless only because all array types are implicit. >>> Once we change that, it won't be anymore. >> >> I guess it depends whether I pass in the existing info when creating the >> array or determine the info when resolving the string name of the array >> element during check() (it will ultimately be the same info either way, >> it's just a question of which approach looks cleaner for getting the >> information set). > > The latter leaves info None until check(). Unhealthy state. > > I suspect the appropriate info is readily available in all the places > where we create array types, so let's just pass it to > _make_array_type().
I just realized why I left it None until check(). We can have forward
references to arrays, as in:
{ 'struct':'A', 'data':{ 'list': ['B'] } }
{ 'struct':'B', 'data':{ 'value': 'int' } }
Normally, BList gets created at the same time as B (and so logically
shares the location of B), but with forward references, we have the
problem that _make_member() has no access to info (unless I plumb it
in), and even if it did, it would be the info for A, whereas my check()
methodology used the info for B. That is, _make_array_type() does not
yet have ready access to info in all call sites.
On the other hand, we have the big TODO about whether pre-creating array
types is even necessary, and want to consider lazy array creation where
they are only instantiated if actually used by a member type or command
return value. I guess it's time for me to play with doing that cleanup
first, and then I'd be happy to have an array's info be the info of its
first instantiation, rather than the info of its element type. (And that
means that ['int'] would have an info, if an array of ints is used
anywhere, even though 'int' does not.)
> Back to serious. If we have to work for the assertion, we should
> consider the assertion's value: how likely are the actual mistakes it
> can catch?
>
> Can legitimate errors be reported for built-in types?
I don't think so (and in fact have assertions along those lines) - we
can only report a semantic error about something in the user's QAPI
file, but their file didn't define the builtin types, so I don't see how
we would ever want to report a semantic error at the location tracked by
a builtin type. So we should be safe if builtin types use info=None.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
