riscv
/
qemu
mirror of https://gitea.goldendeliverer.com/riscv/qemu.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
QEMU main repository: Please see https://www.qemu.org/docs/master/devel/submitting-a-patch.html for how to submit changes to QEMU. Pull Requests are ignored. Please only use release tarballs from the QEMU website. http://www.qemu.org
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
118766 Commits
68 Branches
448 Tags
581 MiB
Tree: 43ab3fb375
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '43ab3fb375'
${ noResults }
qemu/tests/qapi-schema/union-bad-base.json

13 lines
406 B
Raw Normal View History

qapi: Allow anonymous base for flat union Rather than requiring all flat unions to explicitly create a separate base struct, we can allow the qapi schema to specify the common members via an inline dictionary. This is similar to how commands can specify an inline anonymous type for its 'data'. We already have several struct types that only exist to serve as a single flat union's base; the next commit will clean them up. In particular, this patch's change to the BlockdevOptions example in qapi-code-gen.txt will actually be done in the real QAPI schema. Now that anonymous bases are legal, we need to rework the flat-union-bad-base negative test (as previously written, it forms what is now valid QAPI; tweak it to now provide coverage of a new error message path), and add a positive test in qapi-schema-test to use an anonymous base (making the integer argument optional, for even more coverage). Note that this patch only allows anonymous bases for flat unions; simple unions are already enough syntactic sugar that we do not want to burden them further. Meanwhile, while it would be easy to also allow an anonymous base for structs, that would be quite redundant, as the members can be put right into the struct instead. Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1458254921-17042-15-git-send-email-eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
10 years ago
# we allow anonymous base, but enforce no duplicate keys
qapi: Add some union tests Demonstrate that the qapi generator doesn't deal well with unions that aren't up to par. Later patches will update the expected reseults as the generator is made stricter. A few tests work as planned, but most show poor or missing error messages. Of particular note, qapi-code-gen.txt documents 'base' only for flat unions, but the tests here demonstrate that we currently allow a 'base' to a simple union, although it is exercised only in the testsuite. Later patches will remove this undocumented feature, to give us more flexibility in adding other future extensions to union types. For example, one possible extension is the idea of a type-safe simple enum, where added fields tie the discriminator to a user-defined enum type rather than creating an implicit enum from the names in 'data'. But adding such safety on top of a simple enum with a base type could look ambiguous with a flat enum; besides, the documentation also mentions how any simple union can be represented by an equivalent flat union. So it will be simpler to just outlaw support for something we aren't using. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
11 years ago
{ 'enum': 'TestEnum',
'data': [ 'value1', 'value2' ] }
qapi: Use 'struct' instead of 'type' in schema Referring to "type" as both a meta-type (built-in, enum, union, alternate, or struct) and a specific type (the name that the schema uses for declaring structs) is confusing. Do the bulk of the conversion to "struct" in qapi schema, with a fairly mechanical: for f in `find -name '*.json'; do sed -i "s/'type'/'struct'/"; done followed by manually filtering out the places where we have a 'type' embedded in 'data'. Then tweak a couple of tests whose output changes slightly due to longer lines. I also verified that the generated files for QMP and QGA (such as qmp-commands.h) are the same before and after, as assurance that I didn't leave in any accidental member name changes. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
11 years ago
{ 'struct': 'TestTypeA',
qapi: Add some union tests Demonstrate that the qapi generator doesn't deal well with unions that aren't up to par. Later patches will update the expected reseults as the generator is made stricter. A few tests work as planned, but most show poor or missing error messages. Of particular note, qapi-code-gen.txt documents 'base' only for flat unions, but the tests here demonstrate that we currently allow a 'base' to a simple union, although it is exercised only in the testsuite. Later patches will remove this undocumented feature, to give us more flexibility in adding other future extensions to union types. For example, one possible extension is the idea of a type-safe simple enum, where added fields tie the discriminator to a user-defined enum type rather than creating an implicit enum from the names in 'data'. But adding such safety on top of a simple enum with a base type could look ambiguous with a flat enum; besides, the documentation also mentions how any simple union can be represented by an equivalent flat union. So it will be simpler to just outlaw support for something we aren't using. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
11 years ago
'data': { 'string': 'str' } }
qapi: Use 'struct' instead of 'type' in schema Referring to "type" as both a meta-type (built-in, enum, union, alternate, or struct) and a specific type (the name that the schema uses for declaring structs) is confusing. Do the bulk of the conversion to "struct" in qapi schema, with a fairly mechanical: for f in `find -name '*.json'; do sed -i "s/'type'/'struct'/"; done followed by manually filtering out the places where we have a 'type' embedded in 'data'. Then tweak a couple of tests whose output changes slightly due to longer lines. I also verified that the generated files for QMP and QGA (such as qmp-commands.h) are the same before and after, as assurance that I didn't leave in any accidental member name changes. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
11 years ago
{ 'struct': 'TestTypeB',
qapi: Add some union tests Demonstrate that the qapi generator doesn't deal well with unions that aren't up to par. Later patches will update the expected reseults as the generator is made stricter. A few tests work as planned, but most show poor or missing error messages. Of particular note, qapi-code-gen.txt documents 'base' only for flat unions, but the tests here demonstrate that we currently allow a 'base' to a simple union, although it is exercised only in the testsuite. Later patches will remove this undocumented feature, to give us more flexibility in adding other future extensions to union types. For example, one possible extension is the idea of a type-safe simple enum, where added fields tie the discriminator to a user-defined enum type rather than creating an implicit enum from the names in 'data'. But adding such safety on top of a simple enum with a base type could look ambiguous with a flat enum; besides, the documentation also mentions how any simple union can be represented by an equivalent flat union. So it will be simpler to just outlaw support for something we aren't using. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
11 years ago
'data': { 'integer': 'int' } }
{ 'union': 'TestUnion',
qapi: Allow anonymous base for flat union Rather than requiring all flat unions to explicitly create a separate base struct, we can allow the qapi schema to specify the common members via an inline dictionary. This is similar to how commands can specify an inline anonymous type for its 'data'. We already have several struct types that only exist to serve as a single flat union's base; the next commit will clean them up. In particular, this patch's change to the BlockdevOptions example in qapi-code-gen.txt will actually be done in the real QAPI schema. Now that anonymous bases are legal, we need to rework the flat-union-bad-base negative test (as previously written, it forms what is now valid QAPI; tweak it to now provide coverage of a new error message path), and add a positive test in qapi-schema-test to use an anonymous base (making the integer argument optional, for even more coverage). Note that this patch only allows anonymous bases for flat unions; simple unions are already enough syntactic sugar that we do not want to burden them further. Meanwhile, while it would be easy to also allow an anonymous base for structs, that would be quite redundant, as the members can be put right into the struct instead. Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1458254921-17042-15-git-send-email-eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
10 years ago
'base': { 'enum1': 'TestEnum', 'string': 'str' },
qapi: Add some union tests Demonstrate that the qapi generator doesn't deal well with unions that aren't up to par. Later patches will update the expected reseults as the generator is made stricter. A few tests work as planned, but most show poor or missing error messages. Of particular note, qapi-code-gen.txt documents 'base' only for flat unions, but the tests here demonstrate that we currently allow a 'base' to a simple union, although it is exercised only in the testsuite. Later patches will remove this undocumented feature, to give us more flexibility in adding other future extensions to union types. For example, one possible extension is the idea of a type-safe simple enum, where added fields tie the discriminator to a user-defined enum type rather than creating an implicit enum from the names in 'data'. But adding such safety on top of a simple enum with a base type could look ambiguous with a flat enum; besides, the documentation also mentions how any simple union can be represented by an equivalent flat union. So it will be simpler to just outlaw support for something we aren't using. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
11 years ago
'discriminator': 'enum1',
'data': { 'value1': 'TestTypeA',
'value2': 'TestTypeB' } }