aboutsummaryrefslogtreecommitdiff
path: root/tests/qapi-schema/qapi-schema-test.out
diff options
context:
space:
mode:
authorMarkus Armbruster <armbru@redhat.com>2017-05-22 18:42:15 +0200
committerMarkus Armbruster <armbru@redhat.com>2017-05-31 16:04:09 +0200
commitc0644771ebedbd8f47f3c24816445e30111d226b (patch)
tree52c414b513c7fa746579b43f66a8a55042ec3912 /tests/qapi-schema/qapi-schema-test.out
parent8168ca8ea3699b9fca4d8c948c7fa6ecdedc4a97 (diff)
downloadqemu-c0644771ebedbd8f47f3c24816445e30111d226b.zip
qemu-c0644771ebedbd8f47f3c24816445e30111d226b.tar.gz
qemu-c0644771ebedbd8f47f3c24816445e30111d226b.tar.bz2
qapi: Reject alternates that can't work with keyval_parse()
Alternates are sum types like unions, but use the JSON type on the wire / QType in QObject instead of an explicit tag. That's why we require alternate members to have distinct QTypes. The recently introduced keyval_parse() (commit d454dbe) can only produce string scalars. The qobject_input_visitor_new_keyval() input visitor mostly hides the difference, so code using a QObject input visitor doesn't have to care whether its input was parsed from JSON or KEY=VALUE,... The difference leaks for alternates, as noted in commit 0ee9ae7: a non-string, non-enum scalar alternate value can't currently be expressed. In part, this is just our insufficiently sophisticated implementation. Consider alternate type 'GuestFileWhence'. It has an integer member and a 'QGASeek' member. The latter is an enumeration with values 'set', 'cur', 'end'. The meaning of b=set, b=cur, b=end, b=0, b=1 and so forth is perfectly obvious. However, our current implementation falls apart at run time for b=0, b=1, and so forth. Fixable, but not today; add a test case and a TODO comment. Now consider an alternate type with a string and an integer member. What's the meaning of a=42? Is it the string "42" or the integer 42? Whichever meaning you pick makes the other inexpressible. This isn't just an implementation problem, it's fundamental. Our current implementation will pick string. So far, we haven't needed such alternates. To make sure we stop and think before we add one that cannot sanely work with keyval_parse(), let's require alternate members to have sufficiently distinct representation in KEY=VALUE,... syntax: * A string member clashes with any other scalar member * An enumeration member clashes with bool members when it has value 'on' or 'off'. * An enumeration member clashes with numeric members when it has a value that starts with '-', '+', or a decimal digit. This is a rather lazy approximation of the actual number syntax accepted by the visitor. Note that enumeration values starting with '-' and '+' are rejected elsewhere already, but better safe than sorry. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <1495471335-23707-5-git-send-email-armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Diffstat (limited to 'tests/qapi-schema/qapi-schema-test.out')
-rw-r--r--tests/qapi-schema/qapi-schema-test.out4
1 files changed, 2 insertions, 2 deletions
diff --git a/tests/qapi-schema/qapi-schema-test.out b/tests/qapi-schema/qapi-schema-test.out
index 3081091..9f68610 100644
--- a/tests/qapi-schema/qapi-schema-test.out
+++ b/tests/qapi-schema/qapi-schema-test.out
@@ -22,10 +22,10 @@ alternate AltNumInt
tag type
case n: number
case i: int
-alternate AltNumStr
+alternate AltStrObj
tag type
- case n: number
case s: str
+ case o: TestStruct
event EVENT_A None
boxed=False
event EVENT_B None