Re: [PATCH v2 09/19] qapi/schema: allow resolve_type to be used for built-in types

[Markus Armbruster]

John Snow <jsnow@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 <jsnow@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(