1. 19 6月, 2017 1 次提交
  2. 31 5月, 2017 2 次提交
    • M
      qapi: Reject alternates that can't work with keyval_parse() · c0644771
      Markus Armbruster 提交于
      Alternates are sum types like unions, but use the JSON type on the
      wire / QType in QObject instead of an explicit tag.  That's why we
      require alternate members to have distinct QTypes.
      
      The recently introduced keyval_parse() (commit d454dbe0) can only
      produce string scalars.  The qobject_input_visitor_new_keyval() input
      visitor mostly hides the difference, so code using a QObject input
      visitor doesn't have to care whether its input was parsed from JSON or
      KEY=VALUE,...  The difference leaks for alternates, as noted in commit
      0ee9ae7c: a non-string, non-enum scalar alternate value can't currently
      be expressed.
      
      In part, this is just our insufficiently sophisticated implementation.
      Consider alternate type 'GuestFileWhence'.  It has an integer member
      and a 'QGASeek' member.  The latter is an enumeration with values
      'set', 'cur', 'end'.  The meaning of b=set, b=cur, b=end, b=0, b=1 and
      so forth is perfectly obvious.  However, our current implementation
      falls apart at run time for b=0, b=1, and so forth.  Fixable, but not
      today; add a test case and a TODO comment.
      
      Now consider an alternate type with a string and an integer member.
      What's the meaning of a=42?  Is it the string "42" or the integer 42?
      Whichever meaning you pick makes the other inexpressible.  This isn't
      just an implementation problem, it's fundamental.  Our current
      implementation will pick string.
      
      So far, we haven't needed such alternates.  To make sure we stop and
      think before we add one that cannot sanely work with keyval_parse(),
      let's require alternate members to have sufficiently distinct
      representation in KEY=VALUE,... syntax:
      
      * A string member clashes with any other scalar member
      
      * An enumeration member clashes with bool members when it has value
        'on' or 'off'.
      
      * An enumeration member clashes with numeric members when it has a
        value that starts with '-', '+', or a decimal digit.  This is a
        rather lazy approximation of the actual number syntax accepted by
        the visitor.
      
        Note that enumeration values starting with '-' and '+' are rejected
        elsewhere already, but better safe than sorry.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Message-Id: <1495471335-23707-5-git-send-email-armbru@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      c0644771
    • M
      tests/qapi-schema: Avoid 'str' in alternate test cases · 8168ca8e
      Markus Armbruster 提交于
      The next commit is going to make alternate members of type 'str'
      conflict with other scalar types.  Would break a few test cases that
      don't actually require 'str'.  Flip them from 'str' to 'bool' or
      'EnumOne'.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Message-Id: <1495471335-23707-4-git-send-email-armbru@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      8168ca8e
  3. 21 3月, 2017 3 次提交
  4. 16 3月, 2017 16 次提交
  5. 16 1月, 2017 1 次提交
    • M
      qapi: add qapi2texi script · 3313b612
      Marc-André Lureau 提交于
      As the name suggests, the qapi2texi script converts JSON QAPI
      description into a texi file suitable for different target
      formats (info/man/txt/pdf/html...).
      
      It parses the following kind of blocks:
      
      Free-form:
      
        ##
        # = Section
        # == Subsection
        #
        # Some text foo with *emphasis*
        # 1. with a list
        # 2. like that
        #
        # And some code:
        # | $ echo foo
        # | -> do this
        # | <- get that
        #
        ##
      
      Symbol description:
      
        ##
        # @symbol:
        #
        # Symbol body ditto ergo sum. Foo bar
        # baz ding.
        #
        # @param1: the frob to frobnicate
        # @param2: #optional how hard to frobnicate
        #
        # Returns: the frobnicated frob.
        #          If frob isn't frobnicatable, GenericError.
        #
        # Since: version
        # Notes: notes, comments can have
        #        - itemized list
        #        - like this
        #
        # Example:
        #
        # -> { "execute": "quit" }
        # <- { "return": {} }
        #
        ##
      
      That's roughly following the following EBNF grammar:
      
      api_comment = "##\n" comment "##\n"
      comment = freeform_comment | symbol_comment
      freeform_comment = { "# " text "\n" | "#\n" }
      symbol_comment = "# @" name ":\n" { member | tag_section | freeform_comment }
      member = "# @" name ':' [ text ] "\n" freeform_comment
      tag_section = "# " ( "Returns:", "Since:", "Note:", "Notes:", "Example:", "Examples:" ) [ text ]  "\n" freeform_comment
      text = free text with markup
      
      Note that the grammar is ambiguous: a line "# @foo:\n" can be parsed
      both as freeform_comment and as symbol_comment.  The actual parser
      recognizes symbol_comment.
      
      See docs/qapi-code-gen.txt for more details.
      
      Deficiencies and limitations:
      - the generated QMP documentation includes internal types
      - union type support is lacking
      - type information is lacking in generated documentation
      - doc comment error message positions are imprecise, they point
        to the beginning of the comment.
      - a few minor issues, all marked TODO/FIXME in the code
      Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      Message-Id: <20170113144135.5150-16-marcandre.lureau@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      [test-qapi.py tweaked to avoid trailing empty lines in .out]
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      3313b612
  6. 19 7月, 2016 4 次提交
    • E
      qapi: Implement boxed types for commands/events · c818408e
      Eric Blake 提交于
      Turn on the ability to pass command and event arguments in
      a single boxed parameter, which must name a non-empty type
      (although the type can be a struct with all optional members).
      For structs, it makes it possible to pass a single qapi type
      instead of a breakout of all struct members (useful if the
      arguments are already in a struct or if the number of members
      is large); for other complex types, it is now possible to use
      a union or alternate as the data for a command or event.
      
      The empty type may be technically feasible if needed down the
      road, but it's easier to forbid it now and relax things to allow
      it later, than it is to allow it now and have to special case
      how the generated 'q_empty' type is handled (see commit 7ce106a9
      for reasons why nothing is generated for the empty type).  An
      alternate type is never considered empty, but now that a boxed
      type can be either an object or an alternate, we have to provide
      a trivial QAPISchemaAlternateType.is_empty().  The new call to
      arg_type.is_empty() during QAPISchemaCommand.check() requires
      that we first check the type in question; but there is no chance
      of introducing a cycle since objects do not refer back to commands.
      
      We still have a split in syntax checking between ad-hoc parsing
      up front (merely validates that 'boxed' has a sane value) and
      during .check() methods (if 'boxed' is set, then 'data' must name
      a non-empty user-defined type).
      
      Generated code is unchanged, as long as no client uses the
      new feature.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1468468228-27827-10-git-send-email-eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      [Test files renamed to *-boxed-*]
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      c818408e
    • E
      qapi: Plumb in 'boxed' to qapi generator lower levels · 48825ca4
      Eric Blake 提交于
      The next patch will add support for passing a qapi union type
      as the 'data' of a command.  But to do that, the user function
      for implementing the command, as called by the generated
      marshal command, must take the corresponding C struct as a
      single boxed pointer, rather than a breakdown into one
      parameter per member.  Even without a union, being able to use
      a C struct rather than a list of parameters can make it much
      easier to handle coding with QAPI.
      
      This patch adds the internal plumbing of a 'boxed' flag
      associated with each command and event.  In several cases,
      this means adding indentation, with one new dead branch and
      the remaining branch being the original code more deeply
      nested; this was done so that the new implementation in the
      next patch is easier to review without also being mixed with
      indentation changes.
      
      For this patch, no behavior or generated output changes, other
      than the testsuite outputting the value of the new flag
      (always False for now).
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1468468228-27827-9-git-send-email-eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      [Identifier box renamed to boxed in two places]
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      48825ca4
    • E
      qapi: Hide tag_name data member of variants · da9cb193
      Eric Blake 提交于
      Clean up the only remaining external use of the tag_name field of
      QAPISchemaObjectTypeVariants, by explicitly listing the generated
      'type' tag for all variants in the testsuite (you can still tell
      simple unions by the -wrapper types).  Then we can mark the
      tag_name field as private by adding a leading underscore to prevent
      any further use.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1468468228-27827-5-git-send-email-eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      da9cb193
    • E
      qapi: Require all branches of flat union enum to be covered · d0b18239
      Eric Blake 提交于
      We were previously enforcing that all flat union branches were
      found in the corresponding enum, but not that all enum values
      were covered by branches.  The resulting generated code would
      abort() if the user passes the uncovered enum value.
      
      We don't automatically treat non-present branches in a flat
      union as empty types, for symmetry with simple unions (there,
      the enum type is generated from the list of all branches, so
      there is no way to omit a branch but still have it be part of
      the union).
      
      A later patch will add shorthand so that branches that are empty
      in flat unions can be declared as 'branch':{} instead of
      'branch':'Empty', to avoid the need for an otherwise useless
      explicit empty type.  [Such shorthand for simple unions is a bit
      harder to justify, since we would still have to generate a
      wrapper type that parses 'data':{}, rather than truly being an
      empty branch with no additional siblings to the 'type' member.]
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1468468228-27827-3-git-send-email-eblake@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      d0b18239
  7. 18 3月, 2016 3 次提交
    • E
      qapi: Allow anonymous base for flat union · ac4338f8
      Eric Blake 提交于
      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: NEric Blake <eblake@redhat.com>
      Message-Id: <1458254921-17042-15-git-send-email-eblake@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      ac4338f8
    • E
      qapi: Adjust names of implicit types · 7599697c
      Eric Blake 提交于
      The original choice of ':obj-' as the prefix for implicit types
      made it obvious that we weren't going to clash with any user-defined
      names, which cannot contain ':'.  But now we want to create structs
      for implicit types, to get rid of special cases in the generators,
      and our use of ':' in implicit names needs a tweak to produce valid
      C code.
      
      We could transliterate ':' to '_', except that C99 mandates that
      "identifiers that begin with an underscore are always reserved for
      use as identifiers with file scope in both the ordinary and tag name
      spaces".  So it's time to change our naming convention: we can
      instead use the 'q_' prefix that we reserved for ourselves back in
      commit 9fb081e0.  Technically, since we aren't planning on exposing
      the empty type in generated code, we could keep the name ':empty',
      but renaming it to 'q_empty' makes the check for startswith('q_')
      cover all implicit types, whether or not code is generated for them.
      
      As long as we don't declare 'empty' or 'obj' ticklish, it shouldn't
      clash with c_name() prepending 'q_' to the user's ticklish names.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1458254921-17042-5-git-send-email-eblake@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      7599697c
    • E
      qapi: Fix command with named empty argument type · 972a1101
      Eric Blake 提交于
      The generator special-cased
      
       { 'command':'foo', 'data': {} }
      
      to avoid emitting a visitor variable, but failed to see that
      
       { 'struct':'NamedEmptyType, 'data': {} }
       { 'command':'foo', 'data':'NamedEmptyType' }
      
      needs the same treatment.  There, the generator happily generates a
      visitor to get no arguments, and a visitor to destroy no arguments;
      and the compiler isn't happy with that, as demonstrated by the updated
      qapi-schema-test.json:
      
        tests/test-qmp-marshal.c: In function ‘qmp_marshal_user_def_cmd0’:
        tests/test-qmp-marshal.c:264:14: error: variable ‘v’ set but not used [-Werror=unused-but-set-variable]
             Visitor *v;
                      ^
      
      No change to generated code except for the testsuite addition.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1458254921-17042-3-git-send-email-eblake@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      972a1101
  8. 05 3月, 2016 2 次提交
  9. 19 2月, 2016 4 次提交
    • E
      qapi: Add tests of complex objects within alternate · 68d07839
      Eric Blake 提交于
      Upcoming patches will adjust how we visit an object branch of an
      alternate; but we were completely lacking testsuite coverage.
      Rectify this, so that the future patches will be able to highlight
      the changes and still prove that we avoided regressions.
      
      In particular, the use of a flat union UserDefFlatUnion rather
      than a simple struct UserDefA as the branch will give us coverage
      of an object with variants.  And visiting an alternate as both
      the top level and as a nested member gives confidence in correct
      memory allocation handling, especially if the test is run under
      valgrind.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1455778109-6278-5-git-send-email-eblake@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      68d07839
    • E
      qapi: Forbid 'any' inside an alternate · 46534309
      Eric Blake 提交于
      The whole point of an alternate is to allow some type-safety while
      still accepting more than one JSON type.  Meanwhile, the 'any'
      type exists to bypass type-safety altogether.  The two are
      incompatible: you can't accept every type, and still tell which
      branch of the alternate to use for the parse; fix this to give a
      sane error instead of a Python stack trace.
      
      Note that other types that can't be alternate members are caught
      earlier, by check_type().
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1455778109-6278-4-git-send-email-eblake@redhat.com>
      [Commit message tweaked]
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      46534309
    • E
      qapi: Forbid empty unions and useless alternates · 02a57ae3
      Eric Blake 提交于
      Empty unions serve no purpose, and while we compile with gcc
      which permits them, strict C99 forbids them.  We happen to inject
      a dummy 'void *data' member into the C unions that represent QAPI
      unions and alternates, but we want to get rid of that member (it
      pollutes the namespace for no good reason), which would leave us
      with an empty union if the user didn't provide any branches.  While
      empty structs make sense in QAPI, empty unions don't add any
      expressiveness to the QMP language.  So prohibit them at parse
      time.  Update the documentation and testsuite to match.
      
      Note that the documentation already mentioned that alternates
      should have "two or more JSON data types"; so this also fixes
      the code to enforce that.  However, we have existing uses of a
      union type with only one branch, so the 2-or-more strictness
      is intentionally limited to alternates.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1455778109-6278-3-git-send-email-eblake@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      02a57ae3
    • E
      qapi-visit: Honor prefix of discriminator enum · 9d3524b3
      Eric Blake 提交于
      When we added support for a user-specified prefix for an enum
      type (commit 351d36e4), we forgot to teach the qapi-visit code
      to honor that prefix in the case of using a prefixed enum as
      the discriminator for a flat union.  While there is still some
      on-list debate on whether we want to keep prefixes, we should
      at least make it work as long as it is still part of the code
      base.
      Reported-by: NDaniel P. Berrange <berrange@redhat.com>
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1455665965-27638-1-git-send-email-eblake@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      9d3524b3
  10. 17 12月, 2015 4 次提交
    • E
      qapi: Detect base class loops · bac5429c
      Eric Blake 提交于
      It should be fairly obvious that qapi base classes need to
      form an acyclic graph, since QMP cannot specify the same
      key more than once, while base classes are included as flat
      members alongside other members added by the child.  But the
      old check_member_clash() parser function was not prepared to
      check for this, and entered an infinite recursion (at least
      until Python gives up, complaining about nesting too deep).
      
      Now that check_member_clash() has been recently removed,
      attempts at self-inheritance trigger an assertion failure
      introduced by commit ac88219a.  The obvious fix is to turn
      the assertion into a conditional.
      
      This patch includes both the tests (base-cycle-direct and
      base-cycle-indirect) and the fix, since the .err file output
      for the unfixed case is not useful (particularly when it was
      warning about unbounded recursion, as that limit may be
      platform-specific).
      
      We don't need to worry about cycles in flat unions (neither
      the base type nor the type of a variant can be a union) nor
      in alternates (alternate branches cannot themselves be an
      alternate).  But if we later allow a union type as a variant,
      we will still be okay, as QAPISchemaObjectTypeVariants.check()
      triggers the same QAPISchemaObjectType.check() that will
      detect any loops.
      
      Likewise, we need not worry about the case of diamond
      inheritance where the same class is used for a flat union base
      class and one of its variants; either both uses will introduce
      a collision in trying to insert the same member name twice, or
      the shared type is empty and changes nothing.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1449033659-25497-16-git-send-email-eblake@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      bac5429c
    • E
      qapi: Move duplicate collision checks to schema check() · 01cfbaa4
      Eric Blake 提交于
      With the recent commit 'qapi: Detect collisions in C member
      names', we have two different locations for detecting clashes -
      one at parse time, and another at QAPISchema*.check() time.
      Remove all of the ad hoc parser checks, and delete associated
      code (for example, the global check_member_clash() method is
      no longer needed).
      
      Testing this showed that the test union-bad-branch wasn't adding
      much: union-clash-branches also exposes the error message when
      branches collide, and we've recently fixed things to avoid an
      implicit collision with max.  Likewise, the error for
      enum-clash-member changes to report our new detection of
      upper case in a value name, unless we modify the test to use
      all lower case.
      
      The wording of several error messages has changed, but the
      change is generally an improvement rather than a regression.
      
      No change to generated code.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1449033659-25497-15-git-send-email-eblake@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      01cfbaa4
    • E
      qapi: Enforce (or whitelist) case conventions on qapi members · 893e1f2c
      Eric Blake 提交于
      We document that members of enums and objects should be
      'lower-case', although we were not enforcing it.  We have to
      whitelist a few pre-existing entities that violate the norms.
      Add three new tests to expose the new error message, each of
      which first uses the whitelisted name 'UuidInfo' to prove the
      whitelist works, then triggers the failure (this is the same
      pattern used in the existing returns-whitelist.json test).
      
      Note that by adding this check, we have effectively forbidden
      an entity with a case-insensitive clash of member names, for
      any entity that is not on the whitelist (although there is
      still the possibility to clash via '-' vs. '_').
      
      Not done here: a future patch should also add naming convention
      support and whitelist exceptions for command, event, and type
      names.
      
      The additions to QAPISchemaMember.check_clash() check whether
      info['name'] is in the whitelist (the top-most entity name at
      the point 'info' tracks), rather than self.owner (the type,
      possibly implicit, that directly owns the member), because it
      is easier to maintain the whitelist by the names actually in
      the user's .json file, rather than worrying about the names
      of implicit types.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1449033659-25497-14-git-send-email-eblake@redhat.com>
      [Simplified a bit as per discussion with Eric]
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      893e1f2c
    • E
      qapi: Simplify visiting of alternate types · 0426d53c
      Eric Blake 提交于
      Previously, working with alternates required two lookup arrays
      and some indirection: for type Foo, we created Foo_qtypes[]
      which maps each qtype to a value of the generated FooKind enum,
      then look up that value in FooKind_lookup[] like we do for other
      union types.
      
      This has a couple of subtle bugs.  First, the generator was
      creating a call with a parameter '(int *) &(*obj)->type' where
      type is an enum type; this is unsafe if the compiler chooses
      to store the enum type in a different size than int, where
      assigning through the wrong size pointer can corrupt data or
      cause a SIGBUS.
      
      Related bug, not not fixed in this patch: qapi-visit.py's
      gen_visit_enum() generates a cast of its enum * argument to
      int *. Marked FIXME.
      
      Second, since the values of the FooKind enum start at zero, all
      entries of the Foo_qtypes[] array that were not explicitly
      initialized will map to the same branch of the union as the
      first member of the alternate, rather than triggering a desired
      failure in visit_get_next_type().  Fortunately, the bug seldom
      bites; the very next thing the input visitor does is try to
      parse the incoming JSON with the wrong parser, which normally
      fails; the output visitor is not used with a C struct in that
      state, and the dealloc visitor has nothing to clean up (so
      there is no leak).
      
      However, the second bug IS observable in one case: parsing an
      integer causes unusual behavior in an alternate that contains
      at least a 'number' member but no 'int' member, because the
      'number' parser accepts QTYPE_QINT in addition to the expected
      QTYPE_QFLOAT (that is, since 'int' is not a member, the type
      QTYPE_QINT accidentally maps to FooKind 0; if this enum value
      is the 'number' branch the integer parses successfully, but if
      the 'number' branch is not first, some other branch tries to
      parse the integer and rejects it).  A later patch will worry
      about fixing alternates to always parse all inputs that a
      non-alternate 'number' would accept, for now this is still
      marked FIXME in the updated test-qmp-input-visitor.c, to
      merely point out that new undesired behavior of 'ans' matches
      the existing undesired behavior of 'asn'.
      
      This patch fixes the default-initialization bug by deleting the
      indirection, and modifying get_next_type() to directly assign a
      QTypeCode parameter.  This in turn fixes the type-casting bug,
      as we are no longer casting a pointer to enum to a questionable
      size. There is no longer a need to generate an implicit FooKind
      enum associated with the alternate type (since the QMP wire
      format never uses the stringized counterparts of the C union
      member names).  Since the updated visit_get_next_type() does not
      know which qtypes are expected, the generated visitor is
      modified to generate an error statement if an unexpected type is
      encountered.
      
      Callers now have to know the QTYPE_* mapping when looking at the
      discriminator; but so far, only the testsuite was even using the
      C struct of an alternate types.  I considered the possibility of
      keeping the internal enum FooKind, but initialized differently
      than most generated arrays, as in:
        typedef enum FooKind {
            FOO_KIND_A = QTYPE_QDICT,
            FOO_KIND_B = QTYPE_QINT,
        } FooKind;
      to create nicer aliases for knowing when to use foo->a or foo->b
      when inspecting foo->type; but it turned out to add too much
      complexity, especially without a client.
      
      There is a user-visible side effect to this change, but I
      consider it to be an improvement. Previously,
      the invalid QMP command:
        {"execute":"blockdev-add", "arguments":{"options":
          {"driver":"raw", "id":"a", "file":true}}}
      failed with:
        {"error": {"class": "GenericError",
          "desc": "Invalid parameter type for 'file', expected: QDict"}}
      (visit_get_next_type() succeeded, and the error comes from the
      visit_type_BlockdevOptions() expecting {}; there is no mention of
      the fact that a string would also work).  Now it fails with:
        {"error": {"class": "GenericError",
          "desc": "Invalid parameter type for 'file', expected: BlockdevRef"}}
      (the error when the next type doesn't match any expected types for
      the overall alternate).
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Message-Id: <1449033659-25497-5-git-send-email-eblake@redhat.com>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      0426d53c