John Snow <js...@redhat.com> writes:
> allow resolve_type to be used for both built-in and user-specified
> type definitions. In the event that the type cannot be resolved, assert
> that 'info' and 'what' were both provided in order to create a usable
> QAPISemError.
>
> In practice, 'info' will only be None for built-in definitions, which
> *should not fail* type lookup.
>
> As a convenience, allow the 'what' and 'info' parameters to be elided
> entirely so that it can be used as a can-not-fail version of
> lookup_type.
The convenience remains unused until the next patch. It should be added
there.
> Note: there are only three callsites to resolve_type at present where
> "info" is perceived to be possibly None:
>
> 1) QAPISchemaArrayType.check()
> 2) QAPISchemaObjectTypeMember.check()
> 3) QAPISchemaEvent.check()
>
> Of those three, only the first actually ever passes None;
Yes. More below.
> the other two
> are limited by their base class initializers which accept info=None, but
They do?
> neither actually use it in practice.
>
> Signed-off-by: John Snow <js...@redhat.com>
Hmm.
We look up types by name in two ways:
1. Failure is a semantic error
Use .resolve_type(), passing real @info and @what.
Users:
* QAPISchemaArrayType.check() resolving the element type
Fine print: when the array type is built-in, we pass None @info and
@what. The built-in array type's element type must exist for
.resolve_type() to work. This commit changes .resolve_type() to
assert it does.
* QAPISchemaObjectType.check() resolving the base type
* QAPISchemaObjectTypeMember.check() resolving the member type
* QAPISchemaCommand.check() resolving argument type (if named) and
return type (which is always named).
* QAPISchemaEvent.check() resolving argument type (if named).
Note all users are in .check() methods. That's where type named get
resolved.
2. Handle failure
Use .lookup_type(), which returns None when the named type doesn't
exist.
Users:
* QAPISchemaVariants.check(), to look up the base type containing the
tag member for error reporting purposes. Failure would be a
programming error.
* .resolve_type(), which handles failure as semantic error
* ._make_array_type(), which uses it as "type exists already"
predicate.
* QAPISchemaGenIntrospectVisitor._use_type(), to look up certain
built-in types. Failure would be a programming error.
The next commit switches the uses where failure would be a programming
error from .lookup_type() to .resolve_type() without @info and @what, so
failure trips its assertion. I don't like it, because it overloads
.resolve_type() to serve two rather different use cases:
1. Failure is a semantic error; pass @info and @what
2. Failure is a programming error; don't pass @info and what
The odd one out is of course QAPISchemaArrayType.check(), which wants to
use 1. for the user's types and 2. for built-in types. Let's ignore it
for a second.
I prefer to do 2. like typ = .lookup_type(); assert typ. We can factor
this out into its own helper if that helps (pardon the pun).
Back to QAPISchemaArrayType.check(). Its need to resolve built-in
element types, which have no info, necessitates .resolve_type() taking
Optional[QAPISourceInfo]. This might bother you. It doesn't bother me,
unless it leads to mypy complications I can't see.
We can simply leave it as is. Adding the assertion to .resolve_type()
is fine.
Ot we complicate QAPISchemaArrayType.check() to simplify
.resolve_type()'s typing, roughly like this:
if self.info:
self.element_type = schema.resolve_type(
self._element_type_name,
self.info, self.info.defn_meta)
else: # built-in type
self.element_type = schema.lookup_type(
self._element_type_name)
assert self.element_type
Not sure it's worth the trouble. Thoughts?
> ---
> scripts/qapi/schema.py | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/qapi/schema.py b/scripts/qapi/schema.py
> index 66a78f28fd4..a77b51d1b96 100644
> --- a/scripts/qapi/schema.py
> +++ b/scripts/qapi/schema.py
> @@ -1001,9 +1001,10 @@ def lookup_type(self, name):
> assert typ is None or isinstance(typ, QAPISchemaType)
> return typ
>
> - def resolve_type(self, name, info, what):
> + def resolve_type(self, name, info=None, what=None):
> typ = self.lookup_type(name)
> if not typ:
> + assert info and what # built-in types must not fail lookup
> if callable(what):
> what = what(info)
> raise QAPISemError(
