2011-07-19 23:50:43 +04:00
|
|
|
# *-*- Mode: Python -*-*
|
|
|
|
|
|
|
|
# for testing enums
|
|
|
|
{ 'enum': 'EnumOne',
|
|
|
|
'data': [ 'value1', 'value2', 'value3' ] }
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'NestedEnumsOne',
|
2011-07-19 23:50:43 +04:00
|
|
|
'data': { 'enum1': 'EnumOne', '*enum2': 'EnumOne', 'enum3': 'EnumOne', '*enum4': 'EnumOne' } }
|
|
|
|
|
|
|
|
# for testing nested structs
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'UserDefZero',
|
2014-03-01 11:40:31 +04:00
|
|
|
'data': { 'integer': 'int' } }
|
|
|
|
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'UserDefOne',
|
2014-03-01 11:40:31 +04:00
|
|
|
'base': 'UserDefZero',
|
|
|
|
'data': { 'string': 'str', '*enum1': 'EnumOne' } }
|
2011-07-19 23:50:43 +04:00
|
|
|
|
qapi: Drop tests for inline nested structs
A future patch will be using a 'name':{dictionary} entry in the
QAPI schema to specify a default value for an optional argument;
but existing use of inline nested structs conflicts with that goal.
More precisely, a definition in the QAPI schema associates a name
with a set of properties:
Example 1: { 'struct': 'Foo', 'data': { MEMBERS... } }
associates the global name 'Foo' with properties (meta-type struct)
and MEMBERS...
Example 2: 'mumble': TYPE
within MEMBERS... above associates 'mumble' with properties (type
TYPE) and (optional false) within type Foo
The syntax of example 1 is extensible; if we need another property,
we add another name/value pair to the dictionary (such as
'base':TYPE). The syntax of example 2 is not extensible, because
the right hand side can only be a type.
We have used name encoding to add a property: "'*mumble': 'int'"
associates 'mumble' with (type int) and (optional true). Nice,
but doesn't scale. So the solution is to change our existing uses
to be syntactic sugar to an extensible form:
NAME: TYPE --> NAME: { 'type': TYPE, 'optional': false }
*ONAME: TYPE --> ONAME: { 'type': TYPE, 'optional': true }
This patch fixes the testsuite to avoid inline nested types, by
breaking the nesting into explicit types; it means that the type
is now boxed instead of unboxed in C code, but makes no difference
on the wire (and if desired, a later patch could change the
generator to not do so much boxing in C). When touching code to
add new allocations, also convert existing allocations to
consistently prefer typesafe g_new0 over g_malloc0 when a type
name is involved.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-05-04 18:05:30 +03:00
|
|
|
{ 'struct': 'UserDefTwoDictDict',
|
|
|
|
'data': { 'userdef': 'UserDefOne', 'string': 'str' } }
|
|
|
|
|
|
|
|
{ 'struct': 'UserDefTwoDict',
|
|
|
|
'data': { 'string1': 'str',
|
|
|
|
'dict2': 'UserDefTwoDictDict',
|
|
|
|
'*dict3': 'UserDefTwoDictDict' } }
|
|
|
|
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'UserDefTwo',
|
2011-11-15 01:05:29 +04:00
|
|
|
'data': { 'string0': 'str',
|
qapi: Drop tests for inline nested structs
A future patch will be using a 'name':{dictionary} entry in the
QAPI schema to specify a default value for an optional argument;
but existing use of inline nested structs conflicts with that goal.
More precisely, a definition in the QAPI schema associates a name
with a set of properties:
Example 1: { 'struct': 'Foo', 'data': { MEMBERS... } }
associates the global name 'Foo' with properties (meta-type struct)
and MEMBERS...
Example 2: 'mumble': TYPE
within MEMBERS... above associates 'mumble' with properties (type
TYPE) and (optional false) within type Foo
The syntax of example 1 is extensible; if we need another property,
we add another name/value pair to the dictionary (such as
'base':TYPE). The syntax of example 2 is not extensible, because
the right hand side can only be a type.
We have used name encoding to add a property: "'*mumble': 'int'"
associates 'mumble' with (type int) and (optional true). Nice,
but doesn't scale. So the solution is to change our existing uses
to be syntactic sugar to an extensible form:
NAME: TYPE --> NAME: { 'type': TYPE, 'optional': false }
*ONAME: TYPE --> ONAME: { 'type': TYPE, 'optional': true }
This patch fixes the testsuite to avoid inline nested types, by
breaking the nesting into explicit types; it means that the type
is now boxed instead of unboxed in C code, but makes no difference
on the wire (and if desired, a later patch could change the
generator to not do so much boxing in C). When touching code to
add new allocations, also convert existing allocations to
consistently prefer typesafe g_new0 over g_malloc0 when a type
name is involved.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-05-04 18:05:30 +03:00
|
|
|
'dict1': 'UserDefTwoDict' } }
|
2011-11-15 01:05:29 +04:00
|
|
|
|
2012-03-06 21:55:56 +04:00
|
|
|
# for testing unions
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'UserDefA',
|
2012-03-06 21:55:56 +04:00
|
|
|
'data': { 'boolean': 'bool' } }
|
|
|
|
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'UserDefB',
|
2012-03-06 21:55:56 +04:00
|
|
|
'data': { 'integer': 'int' } }
|
|
|
|
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'UserDefC',
|
2014-09-19 00:36:42 +04:00
|
|
|
'data': { 'string1': 'str', 'string2': 'str' } }
|
|
|
|
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'UserDefUnionBase',
|
2014-03-05 06:44:39 +04:00
|
|
|
'data': { 'string': 'str', 'enum1': 'EnumOne' } }
|
|
|
|
|
2014-03-01 11:40:33 +04:00
|
|
|
{ 'union': 'UserDefFlatUnion',
|
2014-03-05 06:44:39 +04:00
|
|
|
'base': 'UserDefUnionBase',
|
|
|
|
'discriminator': 'enum1',
|
|
|
|
'data': { 'value1' : 'UserDefA', 'value2' : 'UserDefB', 'value3' : 'UserDefB' } }
|
2014-03-01 11:40:33 +04:00
|
|
|
# FIXME generated struct UserDefFlatUnion has members for direct base
|
|
|
|
# UserDefOne, but lacks members for indirect base UserDefZero
|
|
|
|
|
2014-09-19 00:36:42 +04:00
|
|
|
# this variant of UserDefFlatUnion defaults to a union that uses fields with
|
|
|
|
# allocated types to test corner cases in the cleanup/dealloc visitor
|
|
|
|
{ 'union': 'UserDefFlatUnion2',
|
|
|
|
'base': 'UserDefUnionBase',
|
|
|
|
'discriminator': 'enum1',
|
|
|
|
'data': { 'value1' : 'UserDefC', 'value2' : 'UserDefB', 'value3' : 'UserDefA' } }
|
|
|
|
|
2015-05-04 18:05:13 +03:00
|
|
|
{ 'alternate': 'UserDefAlternate',
|
2014-03-01 11:40:30 +04:00
|
|
|
'data': { 'uda': 'UserDefA', 's': 'str', 'i': 'int' } }
|
|
|
|
|
2013-05-11 02:46:09 +04:00
|
|
|
# for testing native lists
|
|
|
|
{ 'union': 'UserDefNativeListUnion',
|
|
|
|
'data': { 'integer': ['int'],
|
|
|
|
's8': ['int8'],
|
|
|
|
's16': ['int16'],
|
|
|
|
's32': ['int32'],
|
|
|
|
's64': ['int64'],
|
|
|
|
'u8': ['uint8'],
|
|
|
|
'u16': ['uint16'],
|
|
|
|
'u32': ['uint32'],
|
|
|
|
'u64': ['uint64'],
|
|
|
|
'number': ['number'],
|
|
|
|
'boolean': ['bool'],
|
2015-05-04 18:05:01 +03:00
|
|
|
'string': ['str'],
|
|
|
|
'sizes': ['size'] } }
|
2013-05-11 02:46:09 +04:00
|
|
|
|
2011-07-19 23:50:43 +04:00
|
|
|
# testing commands
|
|
|
|
{ 'command': 'user_def_cmd', 'data': {} }
|
|
|
|
{ 'command': 'user_def_cmd1', 'data': {'ud1a': 'UserDefOne'} }
|
2014-03-01 11:40:28 +04:00
|
|
|
{ 'command': 'user_def_cmd2',
|
|
|
|
'data': {'ud1a': 'UserDefOne', '*ud1b': 'UserDefOne'},
|
|
|
|
'returns': 'UserDefTwo' }
|
2014-03-01 11:40:29 +04:00
|
|
|
{ 'command': 'user_def_cmd3', 'data': {'a': 'int', '*b': 'int' },
|
|
|
|
'returns': 'int' }
|
2013-08-20 02:35:40 +04:00
|
|
|
|
|
|
|
# For testing integer range flattening in opts-visitor. The following schema
|
|
|
|
# corresponds to the option format:
|
|
|
|
#
|
|
|
|
# -userdef i64=3-6,i64=-5--1,u64=2,u16=1,u16=7-12
|
|
|
|
#
|
|
|
|
# For simplicity, this example doesn't use [type=]discriminator nor optargs
|
|
|
|
# specific to discriminator values.
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'UserDefOptions',
|
2013-08-20 02:35:40 +04:00
|
|
|
'data': {
|
|
|
|
'*i64' : [ 'int' ],
|
|
|
|
'*u64' : [ 'uint64' ],
|
|
|
|
'*u16' : [ 'uint16' ],
|
|
|
|
'*i64x': 'int' ,
|
|
|
|
'*u64x': 'uint64' } }
|
2014-06-18 10:43:29 +04:00
|
|
|
|
|
|
|
# testing event
|
2015-05-04 18:05:27 +03:00
|
|
|
{ 'struct': 'EventStructOne',
|
2014-06-18 10:43:29 +04:00
|
|
|
'data': { 'struct1': 'UserDefOne', 'string': 'str', '*enum2': 'EnumOne' } }
|
|
|
|
|
|
|
|
{ 'event': 'EVENT_A' }
|
|
|
|
{ 'event': 'EVENT_B',
|
|
|
|
'data': { } }
|
|
|
|
{ 'event': 'EVENT_C',
|
|
|
|
'data': { '*a': 'int', '*b': 'UserDefOne', 'c': 'str' } }
|
|
|
|
{ 'event': 'EVENT_D',
|
|
|
|
'data': { 'a' : 'EventStructOne', 'b' : 'str', '*c': 'str', '*enum3': 'EnumOne' } }
|
2015-05-14 15:50:56 +03:00
|
|
|
|
|
|
|
# test that we correctly compile downstream extensions
|
|
|
|
{ 'enum': '__org.qemu_x-Enum', 'data': [ '__org.qemu_x-value' ] }
|
2015-05-14 15:50:57 +03:00
|
|
|
{ 'struct': '__org.qemu_x-Base',
|
|
|
|
'data': { '__org.qemu_x-member1': '__org.qemu_x-Enum' } }
|
|
|
|
{ 'struct': '__org.qemu_x-Struct', 'base': '__org.qemu_x-Base',
|
|
|
|
'data': { '__org.qemu_x-member2': 'str' } }
|
2015-05-14 15:50:58 +03:00
|
|
|
{ 'union': '__org.qemu_x-Union1', 'data': { '__org.qemu_x-branch': 'str' } }
|
2015-05-14 15:50:59 +03:00
|
|
|
{ 'struct': '__org.qemu_x-Struct2',
|
|
|
|
'data': { 'array': ['__org.qemu_x-Union1'] } }
|
|
|
|
{ 'union': '__org.qemu_x-Union2', 'base': '__org.qemu_x-Base',
|
|
|
|
'discriminator': '__org.qemu_x-member1',
|
|
|
|
'data': { '__org.qemu_x-value': '__org.qemu_x-Struct2' } }
|
2015-05-14 15:51:00 +03:00
|
|
|
{ 'alternate': '__org.qemu_x-Alt',
|
|
|
|
'data': { '__org.qemu_x-branch': 'str', 'b': '__org.qemu_x-Base' } }
|
2015-05-14 15:51:01 +03:00
|
|
|
{ 'event': '__ORG.QEMU_X-EVENT', 'data': '__org.qemu_x-Struct' }
|
|
|
|
{ 'command': '__org.qemu_x-command',
|
|
|
|
'data': { 'a': ['__org.qemu_x-Enum'], 'b': ['__org.qemu_x-Struct'],
|
|
|
|
'c': '__org.qemu_x-Union2', 'd': '__org.qemu_x-Alt' },
|
|
|
|
'returns': '__org.qemu_x-Union1' }
|