• E
    tests/qapi-schema: Test for reserved names, empty struct · 19767083
    Eric Blake 提交于
    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: NEric Blake <eblake@redhat.com>
    Message-Id: <1445898903-12082-2-git-send-email-eblake@redhat.com>
    [Commit message tweaked slightly]
    Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
    19767083
Makefile 29.9 KB