aboutsummaryrefslogtreecommitdiff
path: root/tests/qapi-schema/union-base-no-discriminator.err
AgeCommit message (Collapse)Author
2015-09-04qapi: Drop one of two "simple union must not have base" checksMarkus Armbruster
The first check ensures the second one can't trigger. Drop the first one, because the second one is in a more logical place, and emits a nicer error message. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com>
2015-05-05qapi: Forbid base without discriminator in unionsEric Blake
None of the existing QMP or QGA interfaces uses a union with a base type but no discriminator; it is easier to avoid this in the generator to save room for other future extensions more likely to be useful. An earlier commit added a union-base-no-discriminator test to ensure that we eventually give a decent error message; likewise, removing UserDefUnion outright is okay, because we moved all the tests we wish to keep into the tests of the simple union UserDefNativeListUnion in the previous commit. Now is the time to actually forbid simple union with base, and remove the last vestiges from the testsuite. 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-05qapi: Add some union testsEric Blake
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>