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. 17 12月, 2015 1 次提交
    • 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