2017-05-22 19:42:14 +03:00
|
|
|
alternate AltEnumBool
|
|
|
|
|
tag type
|
|
|
|
|
case e: EnumOne
|
|
|
|
|
case b: bool
|
|
|
|
|
alternate AltEnumInt
|
|
|
|
|
tag type
|
|
|
|
|
case e: EnumOne
|
|
|
|
|
case i: int
|
|
|
|
|
alternate AltEnumNum
|
|
|
|
|
tag type
|
|
|
|
|
case e: EnumOne
|
|
|
|
|
case n: number
|
|
|
|
|
alternate AltNumEnum
|
|
|
|
|
tag type
|
|
|
|
|
case n: number
|
|
|
|
|
case e: EnumOne
|
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 19:42:15 +03:00
|
|
|
alternate AltStrObj
|
2016-07-14 06:50:15 +03:00
|
|
|
tag type
|
2015-09-30 01:21:06 +03:00
|
|
|
case s: str
|
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 19:42:15 +03:00
|
|
|
case o: TestStruct
|
2015-09-16 14:06:08 +03:00
|
|
|
event EVENT_A None
|
2016-07-14 06:50:19 +03:00
|
|
|
boxed=False
|
2015-09-16 14:06:08 +03:00
|
|
|
event EVENT_B None
|
2016-07-14 06:50:19 +03:00
|
|
|
boxed=False
|
2016-03-18 01:48:29 +03:00
|
|
|
event EVENT_C q_obj_EVENT_C-arg
|
2016-07-14 06:50:19 +03:00
|
|
|
boxed=False
|
2016-03-18 01:48:29 +03:00
|
|
|
event EVENT_D q_obj_EVENT_D-arg
|
2016-07-14 06:50:19 +03:00
|
|
|
boxed=False
|
2016-07-14 06:50:20 +03:00
|
|
|
event EVENT_E UserDefZero
|
|
|
|
|
boxed=True
|
|
|
|
|
event EVENT_F UserDefAlternate
|
|
|
|
|
boxed=True
|
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-27 01:34:40 +03:00
|
|
|
object Empty1
|
|
|
|
|
object Empty2
|
|
|
|
|
base Empty1
|
2015-09-16 14:06:08 +03:00
|
|
|
enum EnumOne ['value1', 'value2', 'value3']
|
|
|
|
|
object EventStructOne
|
|
|
|
|
member struct1: UserDefOne optional=False
|
|
|
|
|
member string: str optional=False
|
|
|
|
|
member enum2: EnumOne optional=True
|
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 07:22:28 +03:00
|
|
|
object ForceArrays
|
|
|
|
|
member unused1: UserDefOneList optional=False
|
|
|
|
|
member unused2: UserDefTwoList optional=False
|
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 09:35:25 +03:00
|
|
|
member unused3: TestStructList optional=False
|
2015-10-13 07:22:24 +03:00
|
|
|
enum MyEnum []
|
2015-09-16 14:06:08 +03:00
|
|
|
object NestedEnumsOne
|
|
|
|
|
member enum1: EnumOne optional=False
|
|
|
|
|
member enum2: EnumOne optional=True
|
|
|
|
|
member enum3: EnumOne optional=False
|
|
|
|
|
member enum4: EnumOne optional=True
|
|
|
|
|
enum QEnumTwo ['value1', 'value2']
|
|
|
|
|
prefix QENUM_TWO
|
2017-06-07 19:35:58 +03:00
|
|
|
enum QType ['none', 'qnull', 'qnum', 'qstring', 'qdict', 'qlist', 'qbool']
|
qapi: Convert QType into QAPI built-in enum type
What's more meta than using qapi to define qapi? :)
Convert QType into a full-fledged[*] builtin qapi enum type, so
that a subsequent patch can then use it as the discriminator
type of qapi alternate types. Fortunately, the judicious use of
'prefix' in the qapi definition avoids churn to the spelling of
the enum constants.
To avoid circular definitions, we have to flip the order of
inclusion between "qobject.h" vs. "qapi-types.h". Back in commit
28770e0, we had the latter include the former, so that we could
use 'QObject *' for our implementation of 'any'. But that usage
also works with only a forward declaration, whereas the
definition of QObject requires QType to be a complete type.
[*] The type has to be builtin, rather than declared in
qapi/common.json, because we want to use it for alternates even
when common.json is not included. But since it is the first
builtin enum type, we have to add special cases to qapi-types
and qapi-visit to only emit definitions once, even when two
qapi files are being compiled into the same binary (the way we
already handled builtin list types like 'intList'). We may
need to revisit how multiple qapi files share common types,
but that's a project for another day.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1449033659-25497-4-git-send-email-eblake@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-12-02 08:20:47 +03:00
|
|
|
prefix QTYPE
|
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 09:35:25 +03:00
|
|
|
object TestStruct
|
|
|
|
|
member integer: int optional=False
|
|
|
|
|
member boolean: bool optional=False
|
|
|
|
|
member string: str optional=False
|
2015-09-16 14:06:08 +03:00
|
|
|
object UserDefA
|
|
|
|
|
member boolean: bool optional=False
|
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 01:21:03 +03:00
|
|
|
member a_b: int optional=True
|
2015-09-16 14:06:08 +03:00
|
|
|
alternate UserDefAlternate
|
2016-07-14 06:50:15 +03:00
|
|
|
tag type
|
2016-02-18 09:48:18 +03:00
|
|
|
case udfu: UserDefFlatUnion
|
2017-05-22 19:42:14 +03:00
|
|
|
case e: EnumOne
|
2015-09-16 14:06:08 +03:00
|
|
|
case i: int
|
2017-06-26 20:25:14 +03:00
|
|
|
case n: null
|
2015-09-16 14:06:08 +03:00
|
|
|
object UserDefB
|
|
|
|
|
member intb: int optional=False
|
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 01:21:03 +03:00
|
|
|
member a-b: bool optional=True
|
2015-09-16 14:06:08 +03:00
|
|
|
object UserDefC
|
|
|
|
|
member string1: str optional=False
|
|
|
|
|
member string2: str optional=False
|
|
|
|
|
object UserDefFlatUnion
|
|
|
|
|
base UserDefUnionBase
|
|
|
|
|
tag enum1
|
|
|
|
|
case value1: UserDefA
|
|
|
|
|
case value2: UserDefB
|
|
|
|
|
case value3: UserDefB
|
|
|
|
|
object UserDefFlatUnion2
|
2016-03-18 01:48:39 +03:00
|
|
|
base q_obj_UserDefFlatUnion2-base
|
2015-09-16 14:06:08 +03:00
|
|
|
tag enum1
|
|
|
|
|
case value1: UserDefC
|
|
|
|
|
case value2: UserDefB
|
|
|
|
|
object UserDefNativeListUnion
|
qapi: Track simple union tag in object.local_members
We were previously creating all unions with an empty list for
local_members. However, it will make it easier to unify struct
and union generation if we include the generated tag member in
local_members. That way, we can have a common code pattern:
visit the base (if any), visit the local members (if any), visit
the variants (if any). The local_members of a flat union
remains empty (because the discriminator is already visited as
part of the base). Then, by visiting tag_member.check() during
AlternateType.check(), we no longer need to call it during
Variants.check().
The various front end entities now exist as follows:
struct: optional base, optional local_members, no variants
simple union: no base, one-element local_members, variants with tag_member
from local_members
flat union: base, no local_members, variants with tag_member from base
alternate: no base, no local_members, variants
With the new local members, we require a bit of finesse to
avoid assertions in the clients.
No change to generated code.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1447836791-369-2-git-send-email-eblake@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-11-18 11:52:36 +03:00
|
|
|
member type: UserDefNativeListUnionKind optional=False
|
2016-07-14 06:50:15 +03:00
|
|
|
tag type
|
2016-03-18 01:48:29 +03:00
|
|
|
case integer: q_obj_intList-wrapper
|
|
|
|
|
case s8: q_obj_int8List-wrapper
|
|
|
|
|
case s16: q_obj_int16List-wrapper
|
|
|
|
|
case s32: q_obj_int32List-wrapper
|
|
|
|
|
case s64: q_obj_int64List-wrapper
|
|
|
|
|
case u8: q_obj_uint8List-wrapper
|
|
|
|
|
case u16: q_obj_uint16List-wrapper
|
|
|
|
|
case u32: q_obj_uint32List-wrapper
|
|
|
|
|
case u64: q_obj_uint64List-wrapper
|
|
|
|
|
case number: q_obj_numberList-wrapper
|
|
|
|
|
case boolean: q_obj_boolList-wrapper
|
|
|
|
|
case string: q_obj_strList-wrapper
|
|
|
|
|
case sizes: q_obj_sizeList-wrapper
|
|
|
|
|
case any: q_obj_anyList-wrapper
|
2015-09-16 14:06:24 +03:00
|
|
|
enum UserDefNativeListUnionKind ['integer', 's8', 's16', 's32', 's64', 'u8', 'u16', 'u32', 'u64', 'number', 'boolean', 'string', 'sizes', 'any']
|
2015-09-16 14:06:08 +03:00
|
|
|
object UserDefOne
|
|
|
|
|
base UserDefZero
|
|
|
|
|
member string: str optional=False
|
|
|
|
|
member enum1: EnumOne optional=True
|
|
|
|
|
object UserDefOptions
|
|
|
|
|
member i64: intList optional=True
|
|
|
|
|
member u64: uint64List optional=True
|
|
|
|
|
member u16: uint16List optional=True
|
|
|
|
|
member i64x: int optional=True
|
|
|
|
|
member u64x: uint64 optional=True
|
|
|
|
|
object UserDefTwo
|
|
|
|
|
member string0: str optional=False
|
|
|
|
|
member dict1: UserDefTwoDict optional=False
|
|
|
|
|
object UserDefTwoDict
|
|
|
|
|
member string1: str optional=False
|
|
|
|
|
member dict2: UserDefTwoDictDict optional=False
|
|
|
|
|
member dict3: UserDefTwoDictDict optional=True
|
|
|
|
|
object UserDefTwoDictDict
|
|
|
|
|
member userdef: UserDefOne optional=False
|
|
|
|
|
member string: str optional=False
|
|
|
|
|
object UserDefUnionBase
|
|
|
|
|
base UserDefZero
|
|
|
|
|
member string: str optional=False
|
|
|
|
|
member enum1: EnumOne optional=False
|
|
|
|
|
object UserDefZero
|
|
|
|
|
member integer: int optional=False
|
2016-02-18 09:48:18 +03:00
|
|
|
object WrapAlternate
|
|
|
|
|
member alt: UserDefAlternate optional=False
|
2015-09-16 14:06:08 +03:00
|
|
|
event __ORG.QEMU_X-EVENT __org.qemu_x-Struct
|
2016-07-14 06:50:19 +03:00
|
|
|
boxed=False
|
2015-09-16 14:06:08 +03:00
|
|
|
alternate __org.qemu_x-Alt
|
2016-07-14 06:50:15 +03:00
|
|
|
tag type
|
2015-09-16 14:06:08 +03:00
|
|
|
case __org.qemu_x-branch: str
|
|
|
|
|
case b: __org.qemu_x-Base
|
|
|
|
|
object __org.qemu_x-Base
|
|
|
|
|
member __org.qemu_x-member1: __org.qemu_x-Enum optional=False
|
|
|
|
|
enum __org.qemu_x-Enum ['__org.qemu_x-value']
|
|
|
|
|
object __org.qemu_x-Struct
|
|
|
|
|
base __org.qemu_x-Base
|
|
|
|
|
member __org.qemu_x-member2: str optional=False
|
2015-11-18 11:52:52 +03:00
|
|
|
member wchar-t: int optional=True
|
2015-09-16 14:06:08 +03:00
|
|
|
object __org.qemu_x-Struct2
|
|
|
|
|
member array: __org.qemu_x-Union1List optional=False
|
|
|
|
|
object __org.qemu_x-Union1
|
qapi: Track simple union tag in object.local_members
We were previously creating all unions with an empty list for
local_members. However, it will make it easier to unify struct
and union generation if we include the generated tag member in
local_members. That way, we can have a common code pattern:
visit the base (if any), visit the local members (if any), visit
the variants (if any). The local_members of a flat union
remains empty (because the discriminator is already visited as
part of the base). Then, by visiting tag_member.check() during
AlternateType.check(), we no longer need to call it during
Variants.check().
The various front end entities now exist as follows:
struct: optional base, optional local_members, no variants
simple union: no base, one-element local_members, variants with tag_member
from local_members
flat union: base, no local_members, variants with tag_member from base
alternate: no base, no local_members, variants
With the new local members, we require a bit of finesse to
avoid assertions in the clients.
No change to generated code.
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <1447836791-369-2-git-send-email-eblake@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-11-18 11:52:36 +03:00
|
|
|
member type: __org.qemu_x-Union1Kind optional=False
|
2016-07-14 06:50:15 +03:00
|
|
|
tag type
|
2016-03-18 01:48:29 +03:00
|
|
|
case __org.qemu_x-branch: q_obj_str-wrapper
|
2015-09-16 14:06:08 +03:00
|
|
|
enum __org.qemu_x-Union1Kind ['__org.qemu_x-branch']
|
|
|
|
|
object __org.qemu_x-Union2
|
|
|
|
|
base __org.qemu_x-Base
|
|
|
|
|
tag __org.qemu_x-member1
|
|
|
|
|
case __org.qemu_x-value: __org.qemu_x-Struct2
|
2016-03-18 01:48:29 +03:00
|
|
|
command __org.qemu_x-command q_obj___org.qemu_x-command-arg -> __org.qemu_x-Union1
|
2016-07-14 06:50:19 +03:00
|
|
|
gen=True success_response=True boxed=False
|
2016-07-14 06:50:20 +03:00
|
|
|
command boxed-struct UserDefZero -> None
|
|
|
|
|
gen=True success_response=True boxed=True
|
|
|
|
|
command boxed-union UserDefNativeListUnion -> None
|
|
|
|
|
gen=True success_response=True boxed=True
|
2016-03-18 01:48:29 +03:00
|
|
|
command guest-get-time q_obj_guest-get-time-arg -> int
|
2016-07-14 06:50:19 +03:00
|
|
|
gen=True success_response=True boxed=False
|
2016-03-18 01:48:29 +03:00
|
|
|
command guest-sync q_obj_guest-sync-arg -> any
|
2016-07-14 06:50:19 +03:00
|
|
|
gen=True success_response=True boxed=False
|
2016-03-18 01:48:29 +03:00
|
|
|
object q_empty
|
|
|
|
|
object q_obj_EVENT_C-arg
|
|
|
|
|
member a: int optional=True
|
|
|
|
|
member b: UserDefOne optional=True
|
|
|
|
|
member c: str optional=False
|
|
|
|
|
object q_obj_EVENT_D-arg
|
|
|
|
|
member a: EventStructOne optional=False
|
|
|
|
|
member b: str optional=False
|
|
|
|
|
member c: str optional=True
|
|
|
|
|
member enum3: EnumOne optional=True
|
2016-03-18 01:48:39 +03:00
|
|
|
object q_obj_UserDefFlatUnion2-base
|
|
|
|
|
member integer: int optional=True
|
|
|
|
|
member string: str optional=False
|
|
|
|
|
member enum1: QEnumTwo optional=False
|
2016-03-18 01:48:29 +03:00
|
|
|
object q_obj___org.qemu_x-command-arg
|
|
|
|
|
member a: __org.qemu_x-EnumList optional=False
|
|
|
|
|
member b: __org.qemu_x-StructList optional=False
|
|
|
|
|
member c: __org.qemu_x-Union2 optional=False
|
|
|
|
|
member d: __org.qemu_x-Alt optional=False
|
|
|
|
|
object q_obj_anyList-wrapper
|
|
|
|
|
member data: anyList optional=False
|
|
|
|
|
object q_obj_boolList-wrapper
|
|
|
|
|
member data: boolList optional=False
|
|
|
|
|
object q_obj_guest-get-time-arg
|
|
|
|
|
member a: int optional=False
|
|
|
|
|
member b: int optional=True
|
|
|
|
|
object q_obj_guest-sync-arg
|
|
|
|
|
member arg: any optional=False
|
|
|
|
|
object q_obj_int16List-wrapper
|
|
|
|
|
member data: int16List optional=False
|
|
|
|
|
object q_obj_int32List-wrapper
|
|
|
|
|
member data: int32List optional=False
|
|
|
|
|
object q_obj_int64List-wrapper
|
|
|
|
|
member data: int64List optional=False
|
|
|
|
|
object q_obj_int8List-wrapper
|
|
|
|
|
member data: int8List optional=False
|
|
|
|
|
object q_obj_intList-wrapper
|
|
|
|
|
member data: intList optional=False
|
|
|
|
|
object q_obj_numberList-wrapper
|
|
|
|
|
member data: numberList optional=False
|
|
|
|
|
object q_obj_sizeList-wrapper
|
|
|
|
|
member data: sizeList optional=False
|
|
|
|
|
object q_obj_str-wrapper
|
|
|
|
|
member data: str optional=False
|
|
|
|
|
object q_obj_strList-wrapper
|
|
|
|
|
member data: strList optional=False
|
|
|
|
|
object q_obj_uint16List-wrapper
|
|
|
|
|
member data: uint16List optional=False
|
|
|
|
|
object q_obj_uint32List-wrapper
|
|
|
|
|
member data: uint32List optional=False
|
|
|
|
|
object q_obj_uint64List-wrapper
|
|
|
|
|
member data: uint64List optional=False
|
|
|
|
|
object q_obj_uint8List-wrapper
|
|
|
|
|
member data: uint8List optional=False
|
|
|
|
|
object q_obj_user_def_cmd1-arg
|
|
|
|
|
member ud1a: UserDefOne optional=False
|
|
|
|
|
object q_obj_user_def_cmd2-arg
|
|
|
|
|
member ud1a: UserDefOne optional=False
|
|
|
|
|
member ud1b: UserDefOne optional=True
|
2015-09-16 14:06:08 +03:00
|
|
|
command user_def_cmd None -> None
|
2016-07-14 06:50:19 +03:00
|
|
|
gen=True success_response=True boxed=False
|
2016-03-18 01:48:27 +03:00
|
|
|
command user_def_cmd0 Empty2 -> Empty2
|
2016-07-14 06:50:19 +03:00
|
|
|
gen=True success_response=True boxed=False
|
2016-03-18 01:48:29 +03:00
|
|
|
command user_def_cmd1 q_obj_user_def_cmd1-arg -> None
|
2016-07-14 06:50:19 +03:00
|
|
|
gen=True success_response=True boxed=False
|
2016-03-18 01:48:29 +03:00
|
|
|
command user_def_cmd2 q_obj_user_def_cmd2-arg -> UserDefTwo
|
2016-07-14 06:50:19 +03:00
|
|
|
gen=True success_response=True boxed=False
|