1. 13 10月, 2015 1 次提交
    • E
      qapi: Test for various name collisions · d220fbcd
      Eric Blake 提交于
      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 d90675fa, 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: NEric 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: NMarkus Armbruster <armbru@redhat.com>
      d220fbcd
  2. 06 5月, 2015 3 次提交
    • E
      qapi: Use 'alternate' to replace anonymous union · ab916fad
      Eric Blake 提交于
      Previous patches have led up to the point where I create the
      new meta-type "'alternate':'Foo'".  See the previous patches
      for documentation; I intentionally split as much work into
      earlier patches to minimize the size of this patch, but a lot
      of it is churn due to testsuite fallout after updating to the
      new type.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      ab916fad
    • E
      qapi: Tighten checking of unions · 44bd1276
      Eric Blake 提交于
      Previous commits demonstrated that the generator had several
      flaws with less-than-perfect unions:
      - a simple union that listed the same branch twice (or two variant
      names that map to the same C enumerator, including the implicit
      MAX sentinel) ended up generating invalid C code
      - an anonymous union that listed two branches with the same qtype
      ended up generating invalid C code
      - the generator crashed on anonymous union attempts to use an
      array type
      - the generator was silently ignoring a base type for anonymous
      unions
      - the generator allowed unknown types or nested anonymous unions
      as a branch in an anonymous union
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      44bd1276
    • E
      qapi: Add some union tests · 3d0c4829
      Eric 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: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      3d0c4829