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.
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; the other two
are limited by their base class initializers which accept info=None, but
neither actually use it in practice.
Signed-off-by: John Snow <js...@redhat.com>
---
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(
--
2.43.0
