2011-07-20 03:50:43 +08:00
|
|
|
# *-*- Mode: Python -*-*
|
|
|
|
|
2015-10-13 12:22:24 +08:00
|
|
|
# This file is a stress test of supported qapi constructs that must
|
|
|
|
# parse and compile correctly.
|
|
|
|
|
2011-07-20 03:50:43 +08:00
|
|
|
# for testing enums
|
|
|
|
{ 'enum': 'EnumOne',
|
|
|
|
'data': [ 'value1', 'value2', 'value3' ] }
|
2015-05-04 23:05:27 +08:00
|
|
|
{ 'struct': 'NestedEnumsOne',
|
2011-07-20 03:50:43 +08:00
|
|
|
'data': { 'enum1': 'EnumOne', '*enum2': 'EnumOne', 'enum3': 'EnumOne', '*enum4': 'EnumOne' } }
|
|
|
|
|
2015-10-13 12:22:24 +08:00
|
|
|
# An empty enum, although unusual, is currently acceptable
|
|
|
|
{ 'enum': 'MyEnum', 'data': [ ] }
|
|
|
|
|
2015-08-26 21:21:20 +08:00
|
|
|
# for testing override of default naming heuristic
|
|
|
|
{ 'enum': 'QEnumTwo',
|
|
|
|
'prefix': 'QENUM_TWO',
|
|
|
|
'data': [ 'value1', 'value2' ] }
|
|
|
|
|
2011-07-20 03:50:43 +08:00
|
|
|
# for testing nested structs
|
2015-05-04 23:05:27 +08:00
|
|
|
{ 'struct': 'UserDefOne',
|
2015-06-26 16:19:11 +08:00
|
|
|
'base': 'UserDefZero', # intentional forward reference
|
2014-03-01 15:40:31 +08:00
|
|
|
'data': { 'string': 'str', '*enum1': 'EnumOne' } }
|
2011-07-20 03:50:43 +08:00
|
|
|
|
2015-06-26 16:19:11 +08:00
|
|
|
{ 'struct': 'UserDefZero',
|
|
|
|
'data': { 'integer': 'int' } }
|
|
|
|
|
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 23:05:30 +08:00
|
|
|
{ 'struct': 'UserDefTwoDictDict',
|
|
|
|
'data': { 'userdef': 'UserDefOne', 'string': 'str' } }
|
|
|
|
|
|
|
|
{ 'struct': 'UserDefTwoDict',
|
|
|
|
'data': { 'string1': 'str',
|
|
|
|
'dict2': 'UserDefTwoDictDict',
|
|
|
|
'*dict3': 'UserDefTwoDictDict' } }
|
|
|
|
|
2015-05-04 23:05:27 +08:00
|
|
|
{ 'struct': 'UserDefTwo',
|
2011-11-15 05:05:29 +08: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 23:05:30 +08:00
|
|
|
'dict1': 'UserDefTwoDict' } }
|
2011-11-15 05:05:29 +08:00
|
|
|
|
2012-03-07 01:55:56 +08:00
|
|
|
# for testing unions
|
qapi: Test for various name collisions
Expose some weaknesses in the generator: we don't always forbid
the generation of structs that contain multiple members that map
to the same C or QMP name. This has already been marked FIXME in
qapi.py in commit d90675f, but having more tests will make sure
future patches produce desired behavior; and updating existing
patches to better document things doesn't hurt, either. Some of
these collisions are already caught in the old-style parser
checks, but ultimately we want all collisions to be caught in the
new-style QAPISchema*.check() methods.
This patch focuses on C struct members, and does not consider
collisions between commands and events (affecting C function
names), or even collisions between generated C type names with
user type names (for things like automatic FOOList struct
representing array types or FOOKind for an implicit enum).
There are two types of struct collisions we want to catch:
1) Collision between two keys in a JSON object. qapi.py prevents
that within a single struct (see test duplicate-key), but it is
possible to have collisions between a type's members and its
base type's members (existing tests struct-base-clash,
struct-base-clash-deep), and its flat union variant members
(renamed test flat-union-clash-member).
2) Collision between two members of the C struct that is generated
for a given QAPI type:
a) Multiple QAPI names map to the same C name (new test
args-name-clash)
b) A QAPI name maps to a C name that is used for another purpose
(new tests flat-union-clash-branch, struct-base-clash-base,
union-clash-data). We already fixed some such cases in commit
0f61af3e and 1e6c1616, but more remain.
c) Two C names generated for other purposes clash
(updated test alternate-clash, new test union-clash-branches,
union-clash-type, flat-union-clash-type)
Ultimately, if we need to have a flat union where a tag value
clashes with a base member name, we could change the generator to
name the union (using 'foo.u.value' rather than 'foo.value') or
otherwise munge the C name corresponding to tag values. But
unless such a need arises, it will probably be easier to just
forbid these collisions.
Some of these negative tests will be deleted later, and positive
tests added to qapi-schema-test.json in their place, when the
generator code is reworked to avoid particular code generation
collisions in class 2).
[Note that viewing this patch with git rename detection enabled
may see some confusion due to renaming some tests while adding
others, but where the content is similar enough that git picks
the wrong pre- and post-patch files to associate]
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1443565276-4535-6-git-send-email-eblake@redhat.com>
[Improve commit message and comments a bit, drop an unrelated test]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-09-30 06:21:03 +08:00
|
|
|
# Among other things, test that a name collision between branches does
|
|
|
|
# not cause any problems (since only one branch can be in use at a time),
|
|
|
|
# by intentionally using two branches that both have a C member 'a_b'
|
2015-05-04 23:05:27 +08:00
|
|
|
{ 'struct': 'UserDefA',
|
qapi: Test for various name collisions
Expose some weaknesses in the generator: we don't always forbid
the generation of structs that contain multiple members that map
to the same C or QMP name. This has already been marked FIXME in
qapi.py in commit d90675f, but having more tests will make sure
future patches produce desired behavior; and updating existing
patches to better document things doesn't hurt, either. Some of
these collisions are already caught in the old-style parser
checks, but ultimately we want all collisions to be caught in the
new-style QAPISchema*.check() methods.
This patch focuses on C struct members, and does not consider
collisions between commands and events (affecting C function
names), or even collisions between generated C type names with
user type names (for things like automatic FOOList struct
representing array types or FOOKind for an implicit enum).
There are two types of struct collisions we want to catch:
1) Collision between two keys in a JSON object. qapi.py prevents
that within a single struct (see test duplicate-key), but it is
possible to have collisions between a type's members and its
base type's members (existing tests struct-base-clash,
struct-base-clash-deep), and its flat union variant members
(renamed test flat-union-clash-member).
2) Collision between two members of the C struct that is generated
for a given QAPI type:
a) Multiple QAPI names map to the same C name (new test
args-name-clash)
b) A QAPI name maps to a C name that is used for another purpose
(new tests flat-union-clash-branch, struct-base-clash-base,
union-clash-data). We already fixed some such cases in commit
0f61af3e and 1e6c1616, but more remain.
c) Two C names generated for other purposes clash
(updated test alternate-clash, new test union-clash-branches,
union-clash-type, flat-union-clash-type)
Ultimately, if we need to have a flat union where a tag value
clashes with a base member name, we could change the generator to
name the union (using 'foo.u.value' rather than 'foo.value') or
otherwise munge the C name corresponding to tag values. But
unless such a need arises, it will probably be easier to just
forbid these collisions.
Some of these negative tests will be deleted later, and positive
tests added to qapi-schema-test.json in their place, when the
generator code is reworked to avoid particular code generation
collisions in class 2).
[Note that viewing this patch with git rename detection enabled
may see some confusion due to renaming some tests while adding
others, but where the content is similar enough that git picks
the wrong pre- and post-patch files to associate]
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1443565276-4535-6-git-send-email-eblake@redhat.com>
[Improve commit message and comments a bit, drop an unrelated test]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-09-30 06:21:03 +08:00
|
|
|
'data': { 'boolean': 'bool', '*a_b': 'int' } }
|
2012-03-07 01:55:56 +08:00
|
|
|
|
2015-05-04 23:05:27 +08:00
|
|
|
{ 'struct': 'UserDefB',
|
qapi: Test for various name collisions
Expose some weaknesses in the generator: we don't always forbid
the generation of structs that contain multiple members that map
to the same C or QMP name. This has already been marked FIXME in
qapi.py in commit d90675f, but having more tests will make sure
future patches produce desired behavior; and updating existing
patches to better document things doesn't hurt, either. Some of
these collisions are already caught in the old-style parser
checks, but ultimately we want all collisions to be caught in the
new-style QAPISchema*.check() methods.
This patch focuses on C struct members, and does not consider
collisions between commands and events (affecting C function
names), or even collisions between generated C type names with
user type names (for things like automatic FOOList struct
representing array types or FOOKind for an implicit enum).
There are two types of struct collisions we want to catch:
1) Collision between two keys in a JSON object. qapi.py prevents
that within a single struct (see test duplicate-key), but it is
possible to have collisions between a type's members and its
base type's members (existing tests struct-base-clash,
struct-base-clash-deep), and its flat union variant members
(renamed test flat-union-clash-member).
2) Collision between two members of the C struct that is generated
for a given QAPI type:
a) Multiple QAPI names map to the same C name (new test
args-name-clash)
b) A QAPI name maps to a C name that is used for another purpose
(new tests flat-union-clash-branch, struct-base-clash-base,
union-clash-data). We already fixed some such cases in commit
0f61af3e and 1e6c1616, but more remain.
c) Two C names generated for other purposes clash
(updated test alternate-clash, new test union-clash-branches,
union-clash-type, flat-union-clash-type)
Ultimately, if we need to have a flat union where a tag value
clashes with a base member name, we could change the generator to
name the union (using 'foo.u.value' rather than 'foo.value') or
otherwise munge the C name corresponding to tag values. But
unless such a need arises, it will probably be easier to just
forbid these collisions.
Some of these negative tests will be deleted later, and positive
tests added to qapi-schema-test.json in their place, when the
generator code is reworked to avoid particular code generation
collisions in class 2).
[Note that viewing this patch with git rename detection enabled
may see some confusion due to renaming some tests while adding
others, but where the content is similar enough that git picks
the wrong pre- and post-patch files to associate]
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1443565276-4535-6-git-send-email-eblake@redhat.com>
[Improve commit message and comments a bit, drop an unrelated test]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-09-30 06:21:03 +08:00
|
|
|
'data': { 'intb': 'int', '*a-b': 'bool' } }
|
2012-03-07 01:55:56 +08:00
|
|
|
|
2014-03-01 15:40:33 +08:00
|
|
|
{ 'union': 'UserDefFlatUnion',
|
2015-06-26 16:19:11 +08:00
|
|
|
'base': 'UserDefUnionBase', # intentional forward reference
|
2014-03-05 10:44:39 +08:00
|
|
|
'discriminator': 'enum1',
|
2015-06-26 16:19:11 +08:00
|
|
|
'data': { 'value1' : 'UserDefA',
|
|
|
|
'value2' : 'UserDefB',
|
|
|
|
'value3' : 'UserDefB' } }
|
2014-03-01 15:40:33 +08:00
|
|
|
|
2015-06-26 16:19:11 +08:00
|
|
|
{ 'struct': 'UserDefUnionBase',
|
2015-06-26 19:21:10 +08:00
|
|
|
'base': 'UserDefZero',
|
2015-06-26 16:19:11 +08:00
|
|
|
'data': { 'string': 'str', 'enum1': 'EnumOne' } }
|
|
|
|
|
2014-09-19 04:36:42 +08: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',
|
2015-06-26 16:19:11 +08:00
|
|
|
'data': { 'value1' : 'UserDefC', # intentional forward reference
|
|
|
|
'value2' : 'UserDefB',
|
|
|
|
'value3' : 'UserDefA' } }
|
2014-09-19 04:36:42 +08:00
|
|
|
|
2015-05-04 23:05:13 +08:00
|
|
|
{ 'alternate': 'UserDefAlternate',
|
2014-03-01 15:40:30 +08:00
|
|
|
'data': { 'uda': 'UserDefA', 's': 'str', 'i': 'int' } }
|
|
|
|
|
2015-06-26 16:19:11 +08:00
|
|
|
{ 'struct': 'UserDefC',
|
|
|
|
'data': { 'string1': 'str', 'string2': 'str' } }
|
|
|
|
|
2015-09-30 06:21:06 +08:00
|
|
|
# for testing use of 'number' within alternates
|
|
|
|
{ 'alternate': 'AltStrBool', 'data': { 's': 'str', 'b': 'bool' } }
|
|
|
|
{ 'alternate': 'AltStrNum', 'data': { 's': 'str', 'n': 'number' } }
|
|
|
|
{ 'alternate': 'AltNumStr', 'data': { 'n': 'number', 's': 'str' } }
|
|
|
|
{ 'alternate': 'AltStrInt', 'data': { 's': 'str', 'i': 'int' } }
|
|
|
|
{ 'alternate': 'AltIntNum', 'data': { 'i': 'int', 'n': 'number' } }
|
|
|
|
{ 'alternate': 'AltNumInt', 'data': { 'n': 'number', 'i': 'int' } }
|
|
|
|
|
2013-05-11 06:46:09 +08: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 23:05:01 +08:00
|
|
|
'string': ['str'],
|
2015-09-16 19:06:24 +08:00
|
|
|
'sizes': ['size'],
|
|
|
|
'any': ['any'] } }
|
2013-05-11 06:46:09 +08:00
|
|
|
|
2011-07-20 03:50:43 +08:00
|
|
|
# testing commands
|
|
|
|
{ 'command': 'user_def_cmd', 'data': {} }
|
|
|
|
{ 'command': 'user_def_cmd1', 'data': {'ud1a': 'UserDefOne'} }
|
2014-03-01 15:40:28 +08:00
|
|
|
{ 'command': 'user_def_cmd2',
|
|
|
|
'data': {'ud1a': 'UserDefOne', '*ud1b': 'UserDefOne'},
|
|
|
|
'returns': 'UserDefTwo' }
|
2015-10-13 12:22:25 +08:00
|
|
|
|
|
|
|
# Returning a non-dictionary requires a name from the whitelist
|
|
|
|
{ 'command': 'guest-get-time', 'data': {'a': 'int', '*b': 'int' },
|
2014-03-01 15:40:29 +08:00
|
|
|
'returns': 'int' }
|
2015-09-16 19:06:24 +08:00
|
|
|
{ 'command': 'guest-sync', 'data': { 'arg': 'any' }, 'returns': 'any' }
|
2013-08-20 06:35:40 +08: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 23:05:27 +08:00
|
|
|
{ 'struct': 'UserDefOptions',
|
2013-08-20 06:35:40 +08:00
|
|
|
'data': {
|
|
|
|
'*i64' : [ 'int' ],
|
|
|
|
'*u64' : [ 'uint64' ],
|
|
|
|
'*u16' : [ 'uint16' ],
|
|
|
|
'*i64x': 'int' ,
|
|
|
|
'*u64x': 'uint64' } }
|
2014-06-18 14:43:29 +08:00
|
|
|
|
|
|
|
# testing event
|
2015-05-04 23:05:27 +08:00
|
|
|
{ 'struct': 'EventStructOne',
|
2014-06-18 14:43:29 +08: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 20:50:56 +08:00
|
|
|
|
|
|
|
# test that we correctly compile downstream extensions
|
|
|
|
{ 'enum': '__org.qemu_x-Enum', 'data': [ '__org.qemu_x-value' ] }
|
2015-05-14 20:50:57 +08: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 20:50:58 +08:00
|
|
|
{ 'union': '__org.qemu_x-Union1', 'data': { '__org.qemu_x-branch': 'str' } }
|
2015-05-14 20:50:59 +08: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 20:51:00 +08:00
|
|
|
{ 'alternate': '__org.qemu_x-Alt',
|
|
|
|
'data': { '__org.qemu_x-branch': 'str', 'b': '__org.qemu_x-Base' } }
|
2015-05-14 20:51:01 +08: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' }
|