1. 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
  2. 19 7月, 2016 1 次提交
    • 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