2011-07-19 21:50:43 +02:00
|
|
|
# *-*- Mode: Python -*-*
|
2020-07-29 20:50:24 +02:00
|
|
|
# vim: filetype=python
|
2011-07-19 21:50:43 +02:00
|
|
|
|
2015-10-13 06:22:24 +02:00
|
|
|
# This file is a stress test of supported qapi constructs that must
|
|
|
|
|
# parse and compile correctly.
|
|
|
|
|
|
2017-03-15 13:56:54 +01:00
|
|
|
# Whitelists to permit QAPI rule violations
|
|
|
|
|
{ 'pragma': {
|
2021-03-23 10:40:23 +01:00
|
|
|
# Types whose member names may use '_'
|
|
|
|
|
'member-name-exceptions': [
|
|
|
|
|
'UserDefA'
|
|
|
|
|
],
|
2017-03-15 13:56:54 +01:00
|
|
|
# Commands allowed to return a non-dictionary:
|
2021-03-23 10:40:16 +01:00
|
|
|
'command-returns-exceptions': [
|
2017-03-15 13:56:54 +01:00
|
|
|
'guest-get-time',
|
|
|
|
|
'guest-sync' ] } }
|
|
|
|
|
|
qapi: Use generated TestStruct machinery in tests
Commit d88f5fd and friends first introduced the various test-qmp-*
tests in 2011, with duplicated hand-rolled TestStruct machinery,
to make sure the qapi visitor interface was tested. Later, commit
4f193e3 in 2013 added a .json file for further testing use by the
files, but without consolidating any of the existing hand-rolled
visitors. And with four copies, subtle differences have crept in,
between the tests themselves (mainly whitespace differences, but
also a question of whether to use NULL or "TestStruct" when
calling visit_start_struct()) and from what the generator produces
(the hand-rolled versions did not cater to partially-allocated
objects, because they did not have a deallocation usage).
Of course, just because the visitor interface is tested does not
mean it is a sane interface; and future patches will be changing
some of the visitor contracts. Rather than having to duplicate
the cleanup work in each copy of the TestStruct visitor, and keep
each hand-rolled copy in sync with what the generator supplies, we
might as well just test what the generator should give us in the
first place.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1446791754-23823-2-git-send-email-eblake@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-11-06 07:35:25 +01:00
|
|
|
{ 'struct': 'TestStruct',
|
2018-12-13 13:37:14 +01:00
|
|
|
'data': { 'integer': {'type': 'int'}, 'boolean': 'bool', 'string': 'str' } }
|
qapi: Use generated TestStruct machinery in tests
Commit d88f5fd and friends first introduced the various test-qmp-*
tests in 2011, with duplicated hand-rolled TestStruct machinery,
to make sure the qapi visitor interface was tested. Later, commit
4f193e3 in 2013 added a .json file for further testing use by the
files, but without consolidating any of the existing hand-rolled
visitors. And with four copies, subtle differences have crept in,
between the tests themselves (mainly whitespace differences, but
also a question of whether to use NULL or "TestStruct" when
calling visit_start_struct()) and from what the generator produces
(the hand-rolled versions did not cater to partially-allocated
objects, because they did not have a deallocation usage).
Of course, just because the visitor interface is tested does not
mean it is a sane interface; and future patches will be changing
some of the visitor contracts. Rather than having to duplicate
the cleanup work in each copy of the TestStruct visitor, and keep
each hand-rolled copy in sync with what the generator supplies, we
might as well just test what the generator should give us in the
first place.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1446791754-23823-2-git-send-email-eblake@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-11-06 07:35:25 +01:00
|
|
|
|
2011-07-19 21:50:43 +02:00
|
|
|
# for testing enums
|
2015-05-04 17:05:27 +02:00
|
|
|
{ 'struct': 'NestedEnumsOne',
|
2015-10-13 06:22:26 +02:00
|
|
|
'data': { 'enum1': 'EnumOne', # Intentional forward reference
|
|
|
|
|
'*enum2': 'EnumOne', 'enum3': 'EnumOne', '*enum4': 'EnumOne' } }
|
2011-07-19 21:50:43 +02:00
|
|
|
|
2015-10-13 06:22:24 +02:00
|
|
|
# An empty enum, although unusual, is currently acceptable
|
|
|
|
|
{ 'enum': 'MyEnum', 'data': [ ] }
|
|
|
|
|
|
tests/qapi-schema: Test for reserved names, empty struct
Add some testsuite coverage to ensure future patches are on
the right track:
Our current C representation of qapi arrays is done by appending
'List' to the element name; but we are not preventing the
creation of an object type with the same name. Add
reserved-type-list.json to test this. Then rename
enum-union-clash.json to reserved-type-kind.json to cover the
reservation that we DO detect, and shorten it to match the fact
that the name is reserved even if there is no clash.
We are failing to detect a collision between a dictionary member
and the implicit 'has_*' flag for another optional member. The
easiest fix would be for a future patch to reserve the entire
"has[-_]" namespace for member names (the collision is also
possible for branch names within flat unions, but only as long as
branch names can collide with (non-variant) members; however,
since future patches are about to remove that, it is not worth
testing here). Add reserved-member-has.json to test this.
A similar collision exists between a dictionary member where
c_name() munges what might otherwise be a reserved name to start
with 'q_', and another member explicitly starts with "q[-_]".
Again, the easiest solution for a future patch will be reserving
the entire namespace, but here for commands as well as members.
Add reserved-member-q.json and reserved-command-q.json to test
this; separate tests since arguably our munging of command 'unix'
to 'qmp_q_unix()' could be done without a q_, which is different
than the munging of a member 'unix' to 'foo.q_unix'.
Finally, our testsuite does not have any compilation coverage
of struct inheritance with empty qapi structs. Update
qapi-schema-test.json to test this.
Note that there is currently no technical reason to forbid type
name patterns from member names, or member name patterns from
types, since the two are not in the same namespace in C and
won't collide; but it's not worth adding positive tests of these
corner cases at this time, especially while there is other churn
pending in patches that rearrange which collisions actually
happen.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1445898903-12082-2-git-send-email-eblake@redhat.com>
[Commit message tweaked slightly]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-10-26 23:34:40 +01:00
|
|
|
# Likewise for an empty struct, including an empty base
|
|
|
|
|
{ 'struct': 'Empty1', 'data': { } }
|
|
|
|
|
{ 'struct': 'Empty2', 'base': 'Empty1', 'data': { } }
|
|
|
|
|
|
2021-09-17 16:31:32 +02:00
|
|
|
# Likewise for an empty union
|
2019-09-13 22:13:43 +02:00
|
|
|
{ 'union': 'Union',
|
|
|
|
|
'base': { 'type': 'EnumOne' }, 'discriminator': 'type',
|
|
|
|
|
'data': { } }
|
|
|
|
|
|
2021-03-23 10:40:21 +01:00
|
|
|
{ 'command': 'user-def-cmd0', 'data': 'Empty2', 'returns': 'Empty2' }
|
2016-03-17 23:48:27 +01:00
|
|
|
|
2015-08-26 15:21:20 +02:00
|
|
|
# for testing override of default naming heuristic
|
|
|
|
|
{ 'enum': 'QEnumTwo',
|
|
|
|
|
'prefix': 'QENUM_TWO',
|
|
|
|
|
'data': [ 'value1', 'value2' ] }
|
|
|
|
|
|
2011-07-19 21:50:43 +02:00
|
|
|
# for testing nested structs
|
2015-05-04 17:05:27 +02:00
|
|
|
{ 'struct': 'UserDefOne',
|
2015-06-26 10:19:11 +02:00
|
|
|
'base': 'UserDefZero', # intentional forward reference
|
2015-10-13 06:22:26 +02:00
|
|
|
'data': { 'string': 'str',
|
|
|
|
|
'*enum1': 'EnumOne' } } # intentional forward reference
|
|
|
|
|
|
|
|
|
|
{ 'enum': 'EnumOne',
|
2018-06-18 10:40:05 +02:00
|
|
|
'data': [ 'value1', 'value2', 'value3', 'value4' ] }
|
2011-07-19 21:50:43 +02:00
|
|
|
|
2015-06-26 10:19:11 +02: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 17:05:30 +02:00
|
|
|
{ 'struct': 'UserDefTwoDictDict',
|
|
|
|
|
'data': { 'userdef': 'UserDefOne', 'string': 'str' } }
|
|
|
|
|
|
|
|
|
|
{ 'struct': 'UserDefTwoDict',
|
|
|
|
|
'data': { 'string1': 'str',
|
|
|
|
|
'dict2': 'UserDefTwoDictDict',
|
|
|
|
|
'*dict3': 'UserDefTwoDictDict' } }
|
|
|
|
|
|
2015-05-04 17:05:27 +02:00
|
|
|
{ 'struct': 'UserDefTwo',
|
2011-11-14 22:05:29 +01: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 17:05:30 +02:00
|
|
|
'dict1': 'UserDefTwoDict' } }
|
2011-11-14 22:05:29 +01:00
|
|
|
|
2018-07-03 17:56:35 +02:00
|
|
|
{ 'struct': 'UserDefThree',
|
|
|
|
|
'data': { 'string0': 'str' } }
|
|
|
|
|
|
qapi: Lazy creation of array types
Commit ac88219a had several TODO markers about whether we needed
to automatically create the corresponding array type alongside
any other type. It turns out that most of the time, we don't!
There are a few exceptions: 1) We have a few situations where we
use an array type in internal code but do not expose that type
through QMP; fix it by declaring a dummy type that forces the
generator to see that we want to use the array type.
2) The builtin arrays (such as intList for QAPI ['int']) must
always be generated, because of the way our QAPI_TYPES_BUILTIN
compile guard works: we have situations (at the very least
tests/test-qmp-output-visitor.c) that include both top-level
"qapi-types.h" (via "error.h") and a secondary
"test-qapi-types.h". If we were to only emit the builtin types
when used locally, then the first .h file would not include all
types, but the second .h does not declare anything at all because
the first .h set QAPI_TYPES_BUILTIN, and we would end up with
compilation error due to things like unknown type 'int8List'.
Actually, we may need to revisit how we do type guards, and
change from a single QAPI_TYPES_BUILTIN over to a different
usage pattern that does one #ifdef per qapi type - right now,
the only types that are declared multiple times between two qapi
.json files for inclusion by a single .c file happen to be the
builtin arrays. But now that we have QAPI 'include' statements,
it is logical to assume that we will soon reach a point where
we want to reuse non-builtin types (yes, I'm thinking about what
it will take to add introspection to QGA, where we will want to
reuse the SchemaInfo type and friends). One #ifdef per type
will help ensure that generating the same qapi type into more
than one qapi-types.h won't cause collisions when both are
included in the same .c file; but we also have to solve how to
avoid creating duplicate qapi-types.c entry points. So that
is a problem left for another day.
Generated code for qapi-types and qapi-visit is drastically
reduced; less than a third of the arrays that were blindly
created were actually needed (a quick grep shows we dropped
from 219 to 69 *List types), and the .o files lost more than
30% of their bulk. [For best results, diff the generated
files with 'git diff --patience --no-index pre post'.]
Interestingly, the introspection output is unchanged - this is
because we already cull all types that are not indirectly
reachable from a command or event, so introspection was already
using only a subset of array types. The subset of types
introspected is now a much larger percentage of the overall set
of array types emitted in qapi-types.h (since the larger set
shrunk), but still not 100% (evidence that the array types
emitted for our new Dummy structs, and the new struct itself,
don't affect QMP).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1444710158-8723-9-git-send-email-eblake@redhat.com>
[Moved array info tracking to a later patch]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-10-13 06:22:28 +02:00
|
|
|
# dummy struct to force generation of array types not otherwise mentioned
|
|
|
|
|
{ 'struct': 'ForceArrays',
|
qapi: Use generated TestStruct machinery in tests
Commit d88f5fd and friends first introduced the various test-qmp-*
tests in 2011, with duplicated hand-rolled TestStruct machinery,
to make sure the qapi visitor interface was tested. Later, commit
4f193e3 in 2013 added a .json file for further testing use by the
files, but without consolidating any of the existing hand-rolled
visitors. And with four copies, subtle differences have crept in,
between the tests themselves (mainly whitespace differences, but
also a question of whether to use NULL or "TestStruct" when
calling visit_start_struct()) and from what the generator produces
(the hand-rolled versions did not cater to partially-allocated
objects, because they did not have a deallocation usage).
Of course, just because the visitor interface is tested does not
mean it is a sane interface; and future patches will be changing
some of the visitor contracts. Rather than having to duplicate
the cleanup work in each copy of the TestStruct visitor, and keep
each hand-rolled copy in sync with what the generator supplies, we
might as well just test what the generator should give us in the
first place.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1446791754-23823-2-git-send-email-eblake@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-11-06 07:35:25 +01:00
|
|
|
'data': { 'unused1':['UserDefOne'], 'unused2':['UserDefTwo'],
|
|
|
|
|
'unused3':['TestStruct'] } }
|
qapi: Lazy creation of array types
Commit ac88219a had several TODO markers about whether we needed
to automatically create the corresponding array type alongside
any other type. It turns out that most of the time, we don't!
There are a few exceptions: 1) We have a few situations where we
use an array type in internal code but do not expose that type
through QMP; fix it by declaring a dummy type that forces the
generator to see that we want to use the array type.
2) The builtin arrays (such as intList for QAPI ['int']) must
always be generated, because of the way our QAPI_TYPES_BUILTIN
compile guard works: we have situations (at the very least
tests/test-qmp-output-visitor.c) that include both top-level
"qapi-types.h" (via "error.h") and a secondary
"test-qapi-types.h". If we were to only emit the builtin types
when used locally, then the first .h file would not include all
types, but the second .h does not declare anything at all because
the first .h set QAPI_TYPES_BUILTIN, and we would end up with
compilation error due to things like unknown type 'int8List'.
Actually, we may need to revisit how we do type guards, and
change from a single QAPI_TYPES_BUILTIN over to a different
usage pattern that does one #ifdef per qapi type - right now,
the only types that are declared multiple times between two qapi
.json files for inclusion by a single .c file happen to be the
builtin arrays. But now that we have QAPI 'include' statements,
it is logical to assume that we will soon reach a point where
we want to reuse non-builtin types (yes, I'm thinking about what
it will take to add introspection to QGA, where we will want to
reuse the SchemaInfo type and friends). One #ifdef per type
will help ensure that generating the same qapi type into more
than one qapi-types.h won't cause collisions when both are
included in the same .c file; but we also have to solve how to
avoid creating duplicate qapi-types.c entry points. So that
is a problem left for another day.
Generated code for qapi-types and qapi-visit is drastically
reduced; less than a third of the arrays that were blindly
created were actually needed (a quick grep shows we dropped
from 219 to 69 *List types), and the .o files lost more than
30% of their bulk. [For best results, diff the generated
files with 'git diff --patience --no-index pre post'.]
Interestingly, the introspection output is unchanged - this is
because we already cull all types that are not indirectly
reachable from a command or event, so introspection was already
using only a subset of array types. The subset of types
introspected is now a much larger percentage of the overall set
of array types emitted in qapi-types.h (since the larger set
shrunk), but still not 100% (evidence that the array types
emitted for our new Dummy structs, and the new struct itself,
don't affect QMP).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1444710158-8723-9-git-send-email-eblake@redhat.com>
[Moved array info tracking to a later patch]
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-10-13 06:22:28 +02:00
|
|
|
|
2012-03-06 18:55:56 +01: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 00:21:03 +02: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 17:05:27 +02: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 00:21:03 +02:00
|
|
|
'data': { 'boolean': 'bool', '*a_b': 'int' } }
|
2012-03-06 18:55:56 +01:00
|
|
|
|
2015-05-04 17:05:27 +02: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 00:21:03 +02:00
|
|
|
'data': { 'intb': 'int', '*a-b': 'bool' } }
|
2012-03-06 18:55:56 +01:00
|
|
|
|
2014-03-01 08:40:33 +01:00
|
|
|
{ 'union': 'UserDefFlatUnion',
|
2015-06-26 10:19:11 +02:00
|
|
|
'base': 'UserDefUnionBase', # intentional forward reference
|
2014-03-05 03:44:39 +01:00
|
|
|
'discriminator': 'enum1',
|
2018-12-13 13:37:14 +01:00
|
|
|
'data': { 'value1' : {'type': 'UserDefA'},
|
2015-06-26 10:19:11 +02:00
|
|
|
'value2' : 'UserDefB',
|
2018-06-18 10:40:05 +02:00
|
|
|
'value3' : 'UserDefB'
|
|
|
|
|
# 'value4' defaults to empty
|
|
|
|
|
} }
|
2014-03-01 08:40:33 +01:00
|
|
|
|
2015-06-26 10:19:11 +02:00
|
|
|
{ 'struct': 'UserDefUnionBase',
|
2015-06-26 13:21:10 +02:00
|
|
|
'base': 'UserDefZero',
|
2015-06-26 10:19:11 +02:00
|
|
|
'data': { 'string': 'str', 'enum1': 'EnumOne' } }
|
|
|
|
|
|
2016-03-03 17:16:43 +01:00
|
|
|
# this variant of UserDefFlatUnion defaults to a union that uses members with
|
2014-09-18 22:36:42 +02:00
|
|
|
# allocated types to test corner cases in the cleanup/dealloc visitor
|
|
|
|
|
{ 'union': 'UserDefFlatUnion2',
|
2016-03-17 23:48:39 +01:00
|
|
|
'base': { '*integer': 'int', 'string': 'str', 'enum1': 'QEnumTwo' },
|
2014-09-18 22:36:42 +02:00
|
|
|
'discriminator': 'enum1',
|
2015-06-26 10:19:11 +02:00
|
|
|
'data': { 'value1' : 'UserDefC', # intentional forward reference
|
2016-02-17 00:39:25 +01:00
|
|
|
'value2' : 'UserDefB' } }
|
2014-09-18 22:36:42 +02:00
|
|
|
|
2016-02-18 07:48:18 +01:00
|
|
|
{ 'struct': 'WrapAlternate',
|
|
|
|
|
'data': { 'alt': 'UserDefAlternate' } }
|
2015-05-04 17:05:13 +02:00
|
|
|
{ 'alternate': 'UserDefAlternate',
|
2018-12-13 13:37:14 +01:00
|
|
|
'data': { 'udfu': {'type': 'UserDefFlatUnion'}, 'e': 'EnumOne', 'i': 'int',
|
2017-06-26 19:25:14 +02:00
|
|
|
'n': 'null' } }
|
2014-03-01 08:40:30 +01:00
|
|
|
|
2015-06-26 10:19:11 +02:00
|
|
|
{ 'struct': 'UserDefC',
|
|
|
|
|
'data': { 'string1': 'str', 'string2': 'str' } }
|
|
|
|
|
|
2015-09-30 00:21:06 +02:00
|
|
|
# for testing use of 'number' within alternates
|
2017-05-22 18:42:14 +02:00
|
|
|
{ 'alternate': 'AltEnumBool', 'data': { 'e': 'EnumOne', 'b': 'bool' } }
|
|
|
|
|
{ 'alternate': 'AltEnumNum', 'data': { 'e': 'EnumOne', 'n': 'number' } }
|
|
|
|
|
{ 'alternate': 'AltNumEnum', 'data': { 'n': 'number', 'e': 'EnumOne' } }
|
|
|
|
|
{ 'alternate': 'AltEnumInt', 'data': { 'e': 'EnumOne', 'i': 'int' } }
|
2022-03-21 17:42:43 +01:00
|
|
|
{ 'alternate': 'AltListInt', 'data': { 'l': ['int'], 'i': 'int' } }
|
2015-09-30 00:21:06 +02:00
|
|
|
|
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>
2017-05-22 18:42:15 +02:00
|
|
|
# for testing use of 'str' within alternates
|
|
|
|
|
{ 'alternate': 'AltStrObj', 'data': { 's': 'str', 'o': 'TestStruct' } }
|
|
|
|
|
|
2021-09-17 16:31:22 +02:00
|
|
|
{ 'struct': 'ArrayStruct',
|
|
|
|
|
'data': { 'integer': ['int'],
|
|
|
|
|
's8': ['int8'],
|
|
|
|
|
's16': ['int16'],
|
|
|
|
|
's32': ['int32'],
|
|
|
|
|
's64': ['int64'],
|
|
|
|
|
'u8': ['uint8'],
|
|
|
|
|
'u16': ['uint16'],
|
|
|
|
|
'u32': ['uint32'],
|
|
|
|
|
'u64': ['uint64'],
|
|
|
|
|
'number': ['number'],
|
|
|
|
|
'boolean': ['bool'],
|
|
|
|
|
'string': ['str'],
|
|
|
|
|
'*sz': ['size'],
|
|
|
|
|
'*any': ['any'],
|
|
|
|
|
'*user': ['Status'] } } # intentional forward ref. to sub-module
|
2013-05-11 00:46:09 +02:00
|
|
|
|
2019-03-01 16:40:48 +01:00
|
|
|
# for testing sub-modules
|
|
|
|
|
{ 'include': 'include/sub-module.json' }
|
|
|
|
|
|
2011-07-19 21:50:43 +02:00
|
|
|
# testing commands
|
2021-03-23 10:40:21 +01:00
|
|
|
{ 'command': 'user-def-cmd', 'data': {} }
|
|
|
|
|
{ 'command': 'user-def-cmd1', 'data': {'ud1a': 'UserDefOne'} }
|
|
|
|
|
{ 'command': 'user-def-cmd2',
|
2018-12-13 13:37:14 +01:00
|
|
|
'data': {'ud1a': {'type': 'UserDefOne'}, '*ud1b': 'UserDefOne'},
|
2014-03-01 08:40:28 +01:00
|
|
|
'returns': 'UserDefTwo' }
|
2015-10-13 06:22:25 +02:00
|
|
|
|
2018-08-30 17:58:10 +02:00
|
|
|
{ 'command': 'cmd-success-response', 'data': {}, 'success-response': false }
|
2020-10-05 17:58:49 +02:00
|
|
|
{ 'command': 'coroutine-cmd', 'data': {}, 'coroutine': true }
|
2018-08-30 17:58:10 +02:00
|
|
|
|
2015-10-13 06:22:25 +02:00
|
|
|
# Returning a non-dictionary requires a name from the whitelist
|
|
|
|
|
{ 'command': 'guest-get-time', 'data': {'a': 'int', '*b': 'int' },
|
2014-03-01 08:40:29 +01:00
|
|
|
'returns': 'int' }
|
2015-09-16 13:06:24 +02:00
|
|
|
{ 'command': 'guest-sync', 'data': { 'arg': 'any' }, 'returns': 'any' }
|
2016-07-14 05:50:20 +02:00
|
|
|
{ 'command': 'boxed-struct', 'boxed': true, 'data': 'UserDefZero' }
|
2021-09-17 16:31:26 +02:00
|
|
|
{ 'command': 'boxed-union', 'data': 'UserDefFlatUnion', 'boxed': true }
|
2019-09-13 22:13:41 +02:00
|
|
|
{ 'command': 'boxed-empty', 'boxed': true, 'data': 'Empty1' }
|
2013-08-20 00:35:40 +02:00
|
|
|
|
2018-07-03 10:53:27 +02:00
|
|
|
# Smoke test on out-of-band and allow-preconfig-test
|
2018-05-11 19:15:59 +02:00
|
|
|
{ 'command': 'test-flags-command', 'allow-oob': true, 'allow-preconfig': true }
|
2018-03-26 08:38:59 +02:00
|
|
|
|
2013-08-20 00:35:40 +02: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 17:05:27 +02:00
|
|
|
{ 'struct': 'UserDefOptions',
|
2013-08-20 00:35:40 +02:00
|
|
|
'data': {
|
|
|
|
|
'*i64' : [ 'int' ],
|
|
|
|
|
'*u64' : [ 'uint64' ],
|
|
|
|
|
'*u16' : [ 'uint16' ],
|
|
|
|
|
'*i64x': 'int' ,
|
|
|
|
|
'*u64x': 'uint64' } }
|
2014-06-18 08:43:29 +02:00
|
|
|
|
|
|
|
|
# testing event
|
2015-05-04 17:05:27 +02:00
|
|
|
{ 'struct': 'EventStructOne',
|
2018-12-13 13:37:14 +01:00
|
|
|
'data': { 'struct1': {'type': 'UserDefOne'}, 'string': 'str', '*enum2': 'EnumOne' } }
|
2014-06-18 08:43:29 +02:00
|
|
|
|
|
|
|
|
{ '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' } }
|
2016-07-14 05:50:20 +02:00
|
|
|
{ 'event': 'EVENT_E', 'boxed': true, 'data': 'UserDefZero' }
|
2019-09-13 22:13:36 +02:00
|
|
|
{ 'event': 'EVENT_F', 'boxed': true, 'data': 'UserDefFlatUnion' }
|
2019-09-13 22:13:41 +02:00
|
|
|
{ 'event': 'EVENT_G', 'boxed': true, 'data': 'Empty1' }
|
2015-05-14 14:50:56 +02:00
|
|
|
|
2015-11-18 09:52:52 +01:00
|
|
|
# test that we correctly compile downstream extensions, as well as munge
|
|
|
|
|
# ticklish names
|
2019-09-13 22:13:42 +02:00
|
|
|
# also test union and alternate with just one branch
|
2015-05-14 14:50:56 +02:00
|
|
|
{ 'enum': '__org.qemu_x-Enum', 'data': [ '__org.qemu_x-value' ] }
|
2015-05-14 14:50:57 +02: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',
|
2015-11-18 09:52:52 +01:00
|
|
|
'data': { '__org.qemu_x-member2': 'str', '*wchar-t': 'int' } }
|
2019-09-13 22:13:42 +02:00
|
|
|
{ 'alternate': '__org.qemu_x-Alt1', 'data': { '__org.qemu_x-branch': 'str' } }
|
2015-05-14 14:50:59 +02:00
|
|
|
{ 'struct': '__org.qemu_x-Struct2',
|
2021-09-17 16:31:30 +02:00
|
|
|
'data': { 'array': ['__org.qemu_x-Union'] } }
|
|
|
|
|
{ 'union': '__org.qemu_x-Union', 'base': '__org.qemu_x-Base',
|
2015-05-14 14:50:59 +02:00
|
|
|
'discriminator': '__org.qemu_x-member1',
|
|
|
|
|
'data': { '__org.qemu_x-value': '__org.qemu_x-Struct2' } }
|
2015-05-14 14:51:00 +02:00
|
|
|
{ 'alternate': '__org.qemu_x-Alt',
|
2019-09-13 22:13:42 +02:00
|
|
|
'data': { '__org.qemu_x-branch': '__org.qemu_x-Base' } }
|
2015-05-14 14:51:01 +02: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'],
|
2021-09-17 16:31:30 +02:00
|
|
|
'c': '__org.qemu_x-Union', 'd': '__org.qemu_x-Alt' } }
|
2018-07-03 17:56:35 +02:00
|
|
|
|
|
|
|
|
# test 'if' condition handling
|
|
|
|
|
|
2021-09-17 16:31:12 +02:00
|
|
|
{ 'struct': 'TestIfStruct',
|
|
|
|
|
'data': { 'foo': 'int',
|
|
|
|
|
'bar': { 'type': 'int', 'if': 'TEST_IF_STRUCT_BAR'} },
|
2021-08-04 10:31:05 +02:00
|
|
|
'if': 'TEST_IF_STRUCT' }
|
2018-07-03 17:56:35 +02:00
|
|
|
|
2021-09-17 16:31:12 +02:00
|
|
|
{ 'enum': 'TestIfEnum',
|
|
|
|
|
'data': [ 'foo', { 'name' : 'bar', 'if': 'TEST_IF_ENUM_BAR' } ],
|
2021-08-04 10:31:05 +02:00
|
|
|
'if': 'TEST_IF_ENUM' }
|
2018-07-03 17:56:35 +02:00
|
|
|
|
2021-09-17 16:31:12 +02:00
|
|
|
{ 'union': 'TestIfUnion',
|
2021-09-17 16:31:28 +02:00
|
|
|
'base': { 'type': 'TestIfEnum' },
|
|
|
|
|
'discriminator': 'type',
|
2021-09-17 16:31:12 +02:00
|
|
|
'data': { 'foo': 'TestStruct',
|
2021-09-17 16:31:28 +02:00
|
|
|
'bar': { 'type': 'UserDefZero', 'if': 'TEST_IF_ENUM_BAR'} },
|
2021-08-04 10:31:05 +02:00
|
|
|
'if': { 'all': ['TEST_IF_UNION', 'TEST_IF_STRUCT'] } }
|
2018-07-03 17:56:35 +02:00
|
|
|
|
2021-03-23 10:40:21 +01:00
|
|
|
{ 'command': 'test-if-union-cmd',
|
2021-03-23 10:40:23 +01:00
|
|
|
'data': { 'union-cmd-arg': 'TestIfUnion' },
|
tests/qapi-schema: Correct two 'if' conditionals
A definition's conditional should imply the conditionals of types it
uses. If it doesn't, some configurations won't compile.
Example (from tests/qapi-schema/qapi-schema-test.json):
{ 'union': 'TestIfUnion', 'data':
{ 'foo': 'TestStruct',
'bar': { 'type': 'str', 'if': 'TEST_IF_UNION_BAR'} },
'if': { 'all': ['TEST_IF_UNION', 'TEST_IF_STRUCT'] } }
{ 'command': 'test-if-union-cmd',
'data': { 'union-cmd-arg': 'TestIfUnion' },
'if': 'TEST_IF_UNION' }
generates
#if (defined(TEST_IF_UNION)) && (defined(TEST_IF_STRUCT))
typedef struct TestIfUnion TestIfUnion;
#endif /* (defined(TEST_IF_UNION)) && (defined(TEST_IF_STRUCT)) */
and
#if defined(TEST_IF_UNION)
void qmp_test_if_union_cmd(TestIfUnion *union_cmd_arg, Error **errp);
void qmp_marshal_test_if_union_cmd(QDict *args, QObject **ret, Error **errp);
#endif /* defined(TEST_IF_UNION) */
which doesn't compile when !defined(TEST_IF_STRUCT).
Messed up in f8c4fdd6ae "tests/qapi: Cover commands with 'if' and
union / alternate 'data'", v4.0.0. Harmless, as we don't actually use
this configuration. Correct it anyway, along with another instance.
This loses coverage for 'not'. The next commit will bring it back.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20210831123809.1107782-4-armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2021-08-31 14:38:00 +02:00
|
|
|
'if': { 'all': ['TEST_IF_UNION', 'TEST_IF_STRUCT'] } }
|
2018-12-08 12:15:57 +01:00
|
|
|
|
2021-09-17 16:31:12 +02:00
|
|
|
{ 'alternate': 'TestIfAlternate',
|
|
|
|
|
'data': { 'foo': 'int',
|
|
|
|
|
'bar': { 'type': 'TestStruct', 'if': 'TEST_IF_ALT_BAR'} },
|
2021-08-04 10:31:05 +02:00
|
|
|
'if': { 'all': ['TEST_IF_ALT', 'TEST_IF_STRUCT'] } }
|
2018-07-03 17:56:35 +02:00
|
|
|
|
2021-03-23 10:40:21 +01:00
|
|
|
{ 'command': 'test-if-alternate-cmd',
|
2021-03-23 10:40:23 +01:00
|
|
|
'data': { 'alt-cmd-arg': 'TestIfAlternate' },
|
tests/qapi-schema: Correct two 'if' conditionals
A definition's conditional should imply the conditionals of types it
uses. If it doesn't, some configurations won't compile.
Example (from tests/qapi-schema/qapi-schema-test.json):
{ 'union': 'TestIfUnion', 'data':
{ 'foo': 'TestStruct',
'bar': { 'type': 'str', 'if': 'TEST_IF_UNION_BAR'} },
'if': { 'all': ['TEST_IF_UNION', 'TEST_IF_STRUCT'] } }
{ 'command': 'test-if-union-cmd',
'data': { 'union-cmd-arg': 'TestIfUnion' },
'if': 'TEST_IF_UNION' }
generates
#if (defined(TEST_IF_UNION)) && (defined(TEST_IF_STRUCT))
typedef struct TestIfUnion TestIfUnion;
#endif /* (defined(TEST_IF_UNION)) && (defined(TEST_IF_STRUCT)) */
and
#if defined(TEST_IF_UNION)
void qmp_test_if_union_cmd(TestIfUnion *union_cmd_arg, Error **errp);
void qmp_marshal_test_if_union_cmd(QDict *args, QObject **ret, Error **errp);
#endif /* defined(TEST_IF_UNION) */
which doesn't compile when !defined(TEST_IF_STRUCT).
Messed up in f8c4fdd6ae "tests/qapi: Cover commands with 'if' and
union / alternate 'data'", v4.0.0. Harmless, as we don't actually use
this configuration. Correct it anyway, along with another instance.
This loses coverage for 'not'. The next commit will bring it back.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20210831123809.1107782-4-armbru@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2021-08-31 14:38:00 +02:00
|
|
|
'if': { 'all': ['TEST_IF_ALT', 'TEST_IF_STRUCT'] } }
|
2018-12-08 12:15:57 +01:00
|
|
|
|
2021-03-23 10:40:21 +01:00
|
|
|
{ 'command': 'test-if-cmd',
|
|
|
|
|
'data': {
|
|
|
|
|
'foo': 'TestIfStruct',
|
2021-08-04 10:31:05 +02:00
|
|
|
'bar': { 'type': 'TestIfEnum', 'if': 'TEST_IF_CMD_BAR' } },
|
2018-07-03 17:56:35 +02:00
|
|
|
'returns': 'UserDefThree',
|
2021-08-04 10:31:05 +02:00
|
|
|
'if': { 'all': ['TEST_IF_CMD', 'TEST_IF_STRUCT'] } }
|
2018-07-03 17:56:35 +02:00
|
|
|
|
2021-03-23 10:40:21 +01:00
|
|
|
{ 'command': 'test-cmd-return-def-three', 'returns': 'UserDefThree' }
|
2018-07-03 17:56:35 +02:00
|
|
|
|
2021-09-17 16:31:12 +02:00
|
|
|
{ 'event': 'TEST_IF_EVENT',
|
|
|
|
|
'data': { 'foo': 'TestIfStruct',
|
|
|
|
|
'bar': { 'type': ['TestIfEnum'], 'if': 'TEST_IF_EVT_BAR' } },
|
2021-08-04 10:31:05 +02:00
|
|
|
'if': { 'all': ['TEST_IF_EVT', 'TEST_IF_STRUCT'] } }
|
2019-06-06 17:37:58 +02:00
|
|
|
|
2021-08-31 14:38:01 +02:00
|
|
|
{ 'event': 'TEST_IF_EVENT2', 'data': {},
|
|
|
|
|
'if': { 'not': { 'any': [ { 'not': 'TEST_IF_EVT' },
|
|
|
|
|
{ 'not': 'TEST_IF_STRUCT' } ] } } }
|
|
|
|
|
|
2020-03-17 12:54:37 +01:00
|
|
|
# test 'features'
|
2019-06-06 17:37:58 +02:00
|
|
|
|
|
|
|
|
{ 'struct': 'FeatureStruct0',
|
|
|
|
|
'data': { 'foo': 'int' },
|
|
|
|
|
'features': [] }
|
|
|
|
|
{ 'struct': 'FeatureStruct1',
|
2020-03-17 12:54:50 +01:00
|
|
|
'data': { 'foo': { 'type': 'int', 'features': [ 'deprecated' ] } },
|
2019-06-06 17:37:58 +02:00
|
|
|
'features': [ 'feature1' ] }
|
|
|
|
|
{ 'struct': 'FeatureStruct2',
|
qapi: New special feature flag "unstable"
By convention, names starting with "x-" are experimental. The parts
of external interfaces so named may be withdrawn or changed
incompatibly in future releases.
The naming convention makes unstable interfaces easy to recognize.
Promoting something from experimental to stable involves a name
change. Client code needs to be updated. Occasionally bothersome.
Worse, the convention is not universally observed:
* QOM type "input-barrier" has properties "x-origin", "y-origin".
Looks accidental, but it's ABI since 4.2.
* QOM types "memory-backend-file", "memory-backend-memfd",
"memory-backend-ram", and "memory-backend-epc" have a property
"x-use-canonical-path-for-ramblock-id" that is documented to be
stable despite its name.
We could document these exceptions, but documentation helps only
humans. We want to recognize "unstable" in code, like "deprecated".
So support recognizing it the same way: introduce new special feature
flag "unstable". It will be treated specially by the QAPI generator,
like the existing feature flag "deprecated", and unlike regular
feature flags.
This commit updates documentation and prepares tests. The next commit
updates the QAPI schema. The remaining patches update the QAPI
generator and wire up -compat policy checking.
Management applications can then use query-qmp-schema and -compat to
manage or guard against use of unstable interfaces the same way as for
deprecated interfaces.
docs/devel/qapi-code-gen.txt no longer mandates the naming convention.
Using it anyway might help writers of programs that aren't
full-fledged management applications. Not using it can save us
bothersome renames. We'll see how that shakes out.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Message-Id: <20211028102520.747396-2-armbru@redhat.com>
2021-10-28 12:25:12 +02:00
|
|
|
'data': { 'foo': { 'type': 'int', 'features': [ 'unstable' ] } },
|
2019-06-06 17:37:58 +02:00
|
|
|
'features': [ { 'name': 'feature1' } ] }
|
|
|
|
|
{ 'struct': 'FeatureStruct3',
|
|
|
|
|
'data': { 'foo': 'int' },
|
|
|
|
|
'features': [ 'feature1', 'feature2' ] }
|
|
|
|
|
{ 'struct': 'FeatureStruct4',
|
|
|
|
|
'data': { 'namespace-test': 'int' },
|
|
|
|
|
'features': [ 'namespace-test', 'int', 'name', 'if' ] }
|
|
|
|
|
|
|
|
|
|
{ 'struct': 'CondFeatureStruct1',
|
|
|
|
|
'data': { 'foo': 'int' },
|
2021-08-04 10:31:05 +02:00
|
|
|
'features': [ { 'name': 'feature1', 'if': 'TEST_IF_FEATURE_1'} ] }
|
2019-06-06 17:37:58 +02:00
|
|
|
{ 'struct': 'CondFeatureStruct2',
|
|
|
|
|
'data': { 'foo': 'int' },
|
2021-08-04 10:31:05 +02:00
|
|
|
'features': [ { 'name': 'feature1', 'if': 'TEST_IF_FEATURE_1'},
|
|
|
|
|
{ 'name': 'feature2', 'if': 'TEST_IF_FEATURE_2'} ] }
|
2019-06-06 17:37:58 +02:00
|
|
|
{ 'struct': 'CondFeatureStruct3',
|
|
|
|
|
'data': { 'foo': 'int' },
|
2021-08-04 10:31:01 +02:00
|
|
|
'features': [ { 'name': 'feature1',
|
2021-08-04 10:31:05 +02:00
|
|
|
'if': { 'all': [ 'TEST_IF_COND_1',
|
|
|
|
|
'TEST_IF_COND_2'] } } ] }
|
2021-08-04 10:31:02 +02:00
|
|
|
{ 'struct': 'CondFeatureStruct4',
|
|
|
|
|
'data': { 'foo': 'int' },
|
|
|
|
|
'features': [ { 'name': 'feature1',
|
2021-08-04 10:31:05 +02:00
|
|
|
'if': {'any': ['TEST_IF_COND_1',
|
|
|
|
|
'TEST_IF_COND_2'] } } ] }
|
2020-03-17 12:54:37 +01:00
|
|
|
|
|
|
|
|
{ 'enum': 'FeatureEnum1',
|
2021-10-25 06:24:02 +02:00
|
|
|
'data': [ 'eins', 'zwei',
|
|
|
|
|
{ 'name': 'drei', 'features': [ 'deprecated' ] } ],
|
2020-03-17 12:54:37 +01:00
|
|
|
'features': [ 'feature1' ] }
|
|
|
|
|
|
|
|
|
|
{ 'union': 'FeatureUnion1',
|
|
|
|
|
'base': { 'tag': 'FeatureEnum1' },
|
|
|
|
|
'discriminator': 'tag',
|
|
|
|
|
'data': { 'eins': 'FeatureStruct1' },
|
|
|
|
|
'features': [ 'feature1' ] }
|
|
|
|
|
|
|
|
|
|
{ 'alternate': 'FeatureAlternate1',
|
|
|
|
|
'data': { 'eins': 'FeatureStruct1' },
|
|
|
|
|
'features': [ 'feature1' ] }
|
|
|
|
|
|
|
|
|
|
{ 'command': 'test-features0',
|
qapi: Implement deprecated-output=hide for QMP command results
This policy suppresses deprecated bits in output, and thus permits
"testing the future". Implement it for QMP command results. Example:
when QEMU is run with -compat deprecated-output=hide, then
{"execute": "query-cpus-fast"}
yields
{"return": [{"thread-id": 9805, "props": {"core-id": 0, "thread-id": 0, "socket-id": 0}, "qom-path": "/machine/unattached/device[0]", "cpu-index": 0, "target": "x86_64"}]}
instead of
{"return": [{"arch": "x86", "thread-id": 22436, "props": {"core-id": 0, "thread-id": 0, "socket-id": 0}, "qom-path": "/machine/unattached/device[0]", "cpu-index": 0, "target": "x86_64"}]}
Note the suppression of deprecated member "arch".
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20210318155519.1224118-4-armbru@redhat.com>
2021-03-18 16:55:11 +01:00
|
|
|
'data': { '*fs0': 'FeatureStruct0',
|
|
|
|
|
'*fs1': 'FeatureStruct1',
|
|
|
|
|
'*fs2': 'FeatureStruct2',
|
|
|
|
|
'*fs3': 'FeatureStruct3',
|
|
|
|
|
'*fs4': 'FeatureStruct4',
|
|
|
|
|
'*cfs1': 'CondFeatureStruct1',
|
|
|
|
|
'*cfs2': 'CondFeatureStruct2',
|
2021-08-04 10:31:02 +02:00
|
|
|
'*cfs3': 'CondFeatureStruct3',
|
|
|
|
|
'*cfs4': 'CondFeatureStruct4' },
|
qapi: Implement deprecated-output=hide for QMP command results
This policy suppresses deprecated bits in output, and thus permits
"testing the future". Implement it for QMP command results. Example:
when QEMU is run with -compat deprecated-output=hide, then
{"execute": "query-cpus-fast"}
yields
{"return": [{"thread-id": 9805, "props": {"core-id": 0, "thread-id": 0, "socket-id": 0}, "qom-path": "/machine/unattached/device[0]", "cpu-index": 0, "target": "x86_64"}]}
instead of
{"return": [{"arch": "x86", "thread-id": 22436, "props": {"core-id": 0, "thread-id": 0, "socket-id": 0}, "qom-path": "/machine/unattached/device[0]", "cpu-index": 0, "target": "x86_64"}]}
Note the suppression of deprecated member "arch".
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20210318155519.1224118-4-armbru@redhat.com>
2021-03-18 16:55:11 +01:00
|
|
|
'returns': 'FeatureStruct1',
|
2019-10-18 10:14:52 +02:00
|
|
|
'features': [] }
|
2020-03-17 12:54:37 +01:00
|
|
|
|
2019-10-18 10:14:52 +02:00
|
|
|
{ 'command': 'test-command-features1',
|
2020-03-17 12:54:50 +01:00
|
|
|
'features': [ 'deprecated' ] }
|
2019-10-18 10:14:52 +02:00
|
|
|
{ 'command': 'test-command-features3',
|
qapi: New special feature flag "unstable"
By convention, names starting with "x-" are experimental. The parts
of external interfaces so named may be withdrawn or changed
incompatibly in future releases.
The naming convention makes unstable interfaces easy to recognize.
Promoting something from experimental to stable involves a name
change. Client code needs to be updated. Occasionally bothersome.
Worse, the convention is not universally observed:
* QOM type "input-barrier" has properties "x-origin", "y-origin".
Looks accidental, but it's ABI since 4.2.
* QOM types "memory-backend-file", "memory-backend-memfd",
"memory-backend-ram", and "memory-backend-epc" have a property
"x-use-canonical-path-for-ramblock-id" that is documented to be
stable despite its name.
We could document these exceptions, but documentation helps only
humans. We want to recognize "unstable" in code, like "deprecated".
So support recognizing it the same way: introduce new special feature
flag "unstable". It will be treated specially by the QAPI generator,
like the existing feature flag "deprecated", and unlike regular
feature flags.
This commit updates documentation and prepares tests. The next commit
updates the QAPI schema. The remaining patches update the QAPI
generator and wire up -compat policy checking.
Management applications can then use query-qmp-schema and -compat to
manage or guard against use of unstable interfaces the same way as for
deprecated interfaces.
docs/devel/qapi-code-gen.txt no longer mandates the naming convention.
Using it anyway might help writers of programs that aren't
full-fledged management applications. Not using it can save us
bothersome renames. We'll see how that shakes out.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Message-Id: <20211028102520.747396-2-armbru@redhat.com>
2021-10-28 12:25:12 +02:00
|
|
|
'features': [ 'unstable', 'feature1', 'feature2' ] }
|
2019-10-18 10:14:52 +02:00
|
|
|
|
|
|
|
|
{ 'command': 'test-command-cond-features1',
|
2021-08-04 10:31:05 +02:00
|
|
|
'features': [ { 'name': 'feature1', 'if': 'TEST_IF_FEATURE_1'} ] }
|
2019-10-18 10:14:52 +02:00
|
|
|
{ 'command': 'test-command-cond-features2',
|
2021-08-04 10:31:05 +02:00
|
|
|
'features': [ { 'name': 'feature1', 'if': 'TEST_IF_FEATURE_1'},
|
|
|
|
|
{ 'name': 'feature2', 'if': 'TEST_IF_FEATURE_2'} ] }
|
2019-10-18 10:14:52 +02:00
|
|
|
{ 'command': 'test-command-cond-features3',
|
2021-08-04 10:31:01 +02:00
|
|
|
'features': [ { 'name': 'feature1',
|
2021-08-04 10:31:05 +02:00
|
|
|
'if': { 'all': [ 'TEST_IF_COND_1',
|
|
|
|
|
'TEST_IF_COND_2'] } } ] }
|
2020-03-17 12:54:37 +01:00
|
|
|
|
2021-03-23 10:40:10 +01:00
|
|
|
{ 'event': 'TEST_EVENT_FEATURES0',
|
2021-03-18 16:55:13 +01:00
|
|
|
'data': 'FeatureStruct1' }
|
|
|
|
|
|
2021-03-23 10:40:10 +01:00
|
|
|
{ 'event': 'TEST_EVENT_FEATURES1',
|
2020-03-17 12:54:50 +01:00
|
|
|
'features': [ 'deprecated' ] }
|
qapi: New special feature flag "unstable"
By convention, names starting with "x-" are experimental. The parts
of external interfaces so named may be withdrawn or changed
incompatibly in future releases.
The naming convention makes unstable interfaces easy to recognize.
Promoting something from experimental to stable involves a name
change. Client code needs to be updated. Occasionally bothersome.
Worse, the convention is not universally observed:
* QOM type "input-barrier" has properties "x-origin", "y-origin".
Looks accidental, but it's ABI since 4.2.
* QOM types "memory-backend-file", "memory-backend-memfd",
"memory-backend-ram", and "memory-backend-epc" have a property
"x-use-canonical-path-for-ramblock-id" that is documented to be
stable despite its name.
We could document these exceptions, but documentation helps only
humans. We want to recognize "unstable" in code, like "deprecated".
So support recognizing it the same way: introduce new special feature
flag "unstable". It will be treated specially by the QAPI generator,
like the existing feature flag "deprecated", and unlike regular
feature flags.
This commit updates documentation and prepares tests. The next commit
updates the QAPI schema. The remaining patches update the QAPI
generator and wire up -compat policy checking.
Management applications can then use query-qmp-schema and -compat to
manage or guard against use of unstable interfaces the same way as for
deprecated interfaces.
docs/devel/qapi-code-gen.txt no longer mandates the naming convention.
Using it anyway might help writers of programs that aren't
full-fledged management applications. Not using it can save us
bothersome renames. We'll see how that shakes out.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Message-Id: <20211028102520.747396-2-armbru@redhat.com>
2021-10-28 12:25:12 +02:00
|
|
|
|
|
|
|
|
{ 'event': 'TEST_EVENT_FEATURES2',
|
|
|
|
|
'features': [ 'unstable' ] }
|
