qemu/tests/qapi-schema/doc-good.json

201 lines
3.2 KiB
JSON
Raw Normal View History

# -*- Mode: Python -*-
# vim: filetype=python
#
# Positive QAPI doc comment tests
{ 'pragma': { 'doc-required': true } }
##
# = Section
#
# == Subsection
#
# *with emphasis*
# @var {in braces}
#
# * List item one
# * Two, multiple
# lines
#
# * Three
# Still in list
#
# Not in list
#
# - Second list
# Note: still in list
#
# Note: not in list
#
# 1. Third list
# is numbered
#
# 2. another item
#
# Returns: the King
# Since: the first age
# Notes:
#
# 1. Lorem ipsum dolor sit amet
#
# 2. Ut enim ad minim veniam
#
# Duis aute irure dolor
#
# Example:
#
# -> in
# <- out
# Examples:
# - *verbatim*
# - {braces}
##
##
# @Enum:
#
# @one: The _one_ {and only}, description on the same line
#
# Features:
# @enum-feat: Also _one_ {and only}
# @enum-member-feat: a member feature
#
# @two is undocumented
##
{ 'enum': 'Enum',
'data': [ { 'name': 'one', 'if': 'IFONE',
'features': [ 'enum-member-feat' ] },
'two' ],
'features': [ 'enum-feat' ],
'if': 'IFCOND' }
##
# @Base:
#
# @base1:
# description starts on a new line,
# not indented
##
{ 'struct': 'Base', 'data': { 'base1': 'Enum' },
'if': { 'all': ['IFALL1', 'IFALL2'] } }
##
# @Variant1:
#
# A paragraph
#
# Another paragraph
#
# @var1 is undocumented
#
# Features:
# @variant1-feat: a feature
# @member-feat: a member feature
##
{ 'struct': 'Variant1',
'features': [ 'variant1-feat' ],
'data': { 'var1': { 'type': 'str',
'features': [ 'member-feat' ],
'if': 'IFSTR' } } }
##
# @Variant2:
#
##
{ 'struct': 'Variant2', 'data': {} }
##
# @Object:
#
# Features:
# @union-feat1: a feature
##
{ 'union': 'Object',
'features': [ 'union-feat1' ],
'base': 'Base',
'discriminator': 'base1',
'data': { 'one': 'Variant1',
'two': { 'type': 'Variant2',
'if': { 'any': ['IFONE', 'IFTWO'] } } } }
##
# @Alternate:
#
# @i: description starts on the same line
# remainder indented the same
# @b is undocumented
#
# Features:
# @alt-feat: a feature
##
{ 'alternate': 'Alternate',
'features': [ 'alt-feat' ],
'data': { 'i': 'int', 'b': 'bool' },
'if': { 'not': { 'any': [ 'IFONE', 'IFTWO' ] } } }
##
# == Another subsection
##
##
# @cmd:
#
# @arg1:
# description starts on a new line,
# indented
#
qapi: Relax doc string @name: description indentation rules The QAPI schema doc comment language provides special syntax for command and event arguments, struct and union members, alternate branches, enumeration values, and features: descriptions starting with "@name:". By convention, we format them like this: # @name: Lorem ipsum dolor sit amet, consectetur adipiscing elit, # sed do eiusmod tempor incididunt ut labore et dolore # magna aliqua. Okay for names as short as "name", but we have much longer ones. Their description gets squeezed against the right margin, like this: # @dirty-sync-missed-zero-copy: Number of times dirty RAM synchronization could # not avoid copying dirty pages. This is between # 0 and @dirty-sync-count * @multifd-channels. # (since 7.1) The description text is effectively just 50 characters wide. Easy enough to read, but can be cumbersome to write. The awkward squeeze against the right margin makes people go beyond it, which produces two undesirables: arguments about style, and descriptions that are unnecessarily hard to read, like this one: # @postcopy-vcpu-blocktime: list of the postcopy blocktime per vCPU. This is # only present when the postcopy-blocktime migration capability # is enabled. (Since 3.0) We could instead format it like # @postcopy-vcpu-blocktime: # list of the postcopy blocktime per vCPU. This is only present # when the postcopy-blocktime migration capability is # enabled. (Since 3.0) or, since the commit before previous, like # @postcopy-vcpu-blocktime: # list of the postcopy blocktime per vCPU. This is only present # when the postcopy-blocktime migration capability is # enabled. (Since 3.0) However, I'd rather have # @postcopy-vcpu-blocktime: list of the postcopy blocktime per vCPU. # This is only present when the postcopy-blocktime migration # capability is enabled. (Since 3.0) because this is how rST field and option lists work. To get this, we need to let the first non-blank line after the "@name:" line determine expected indentation. This fills up the indentation pitfall mentioned in docs/devel/qapi-code-gen.rst. A related pitfall still exists. Update the text to show it. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20230428105429.1687850-14-armbru@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> [Work around lack of walrus operator in Python 3.7 and older]
2023-04-28 13:54:25 +03:00
# @arg2: description starts on the same line
# remainder indented differently
#
# Features:
# @cmd-feat1: a feature
# @cmd-feat2: another feature
# Note: @arg3 is undocumented
# Returns: @Object
# TODO: frobnicate
# Notes:
#
# - Lorem ipsum dolor sit amet
# - Ut enim ad minim veniam
#
# Duis aute irure dolor
# Example:
#
# -> in
# <- out
# Examples:
# - *verbatim*
# - {braces}
# Since: 2.10
##
{ 'command': 'cmd',
'data': { 'arg1': 'int', '*arg2': 'str', 'arg3': 'bool' },
'returns': 'Object',
'features': [ 'cmd-feat1', 'cmd-feat2' ] }
##
# @cmd-boxed:
# If you're bored enough to read this, go see a video of boxed cats
# Features:
# @cmd-feat1: a feature
# @cmd-feat2: another feature
# Example:
#
# -> in
#
# <- out
##
{ 'command': 'cmd-boxed', 'boxed': true,
'data': 'Object',
'features': [ 'cmd-feat1', 'cmd-feat2' ] }
##
# @EVT_BOXED:
#
# Features:
# @feat3: a feature
##
{ 'event': 'EVT_BOXED', 'boxed': true,
'features': [ 'feat3' ],
'data': 'Object' }