OpenE2K
/
qemu-e2k
13
4
Fork 0
Code Issues 4 Pull Requests Projects 2 Releases Activity
qemu-e2k/tests/qapi-schema/reserved-type-list.json

6 lines
241 B
JSON
Raw Normal View History

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
# Potential C name collision
qapi: Reserve '*List' type names for list types Type names ending in 'List' can clash with qapi list types in generated C. We don't currently use such names. It is easier to outlaw them now than to worry about how to resolve such a clash in the future. For precedence, see commit 4dc2e69, which did the same for names ending in 'Kind' versus implicit enum types for qapi unions. Update the testsuite to match. Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <1445898903-12082-5-git-send-email-eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com>
2015-10-26 23:34:43 +01:00
# We reserve names ending in 'List' for use by array types.
# TODO - we could choose array names to avoid collision with user types,
# in order to let this compile
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
{ 'struct': 'FooList', 'data': { 's': 'str' } }