docs/qapi-code-gen: add cross-references

Add clickables to many places.

Signed-off-by: John Snow <jsnow@redhat.com>
Message-Id: <20210720235619.2048797-4-jsnow@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Markus Armbruster <armbru@redhat.com>

1 files changed, 58 insertions, 49 deletions

diff --git a/docs/devel/qapi-code-gen.rst b/docs/devel/qapi-code-gen.rst
index 07b11e2a40..26c62b0e7b 100644
--- a/docs/devel/qapi-code-gen.rst
+++ b/docs/devel/qapi-code-gen.rst
@@ -156,6 +156,7 @@ from making a forward reference to a type that is only introduced by
 an outer file.  The parser may be made stricter in the future to
 prevent incomplete include files.
 
+.. _pragma:
 
 Pragma directives
 -----------------
@@ -186,6 +187,7 @@ Pragma 'member-name-exceptions' takes a list of types whose member
 names may contain uppercase letters, and ``"_"`` instead of ``"-"``.
 Default is none.
 
+.. _ENUM-VALUE:
 
 Enumeration types
 -----------------
@@ -228,13 +230,15 @@ additional enumeration constant PREFIX__MAX with value N.
 Do not use string or an integer type when an enumeration type can do
 the job satisfactorily.
 
-The optional 'if' member specifies a conditional.  See "Configuring
-the schema" below for more on this.
+The optional 'if' member specifies a conditional.  See `Configuring the
+schema`_ below for more on this.
 
-The optional 'features' member specifies features.  See "Features"
+The optional 'features' member specifies features.  See Features_
 below for more on this.
 
 
+.. _TYPE-REF:
+
 Type references and array types
 -------------------------------
 
@@ -269,11 +273,13 @@ Member 'struct' names the struct type.
 
 Each MEMBER of the 'data' object defines a member of the struct type.
 
+.. _MEMBERS:
+
 The MEMBER's STRING name consists of an optional ``*`` prefix and the
 struct member name.  If ``*`` is present, the member is optional.
 
 The MEMBER's value defines its properties, in particular its type.
-The form TYPE-REF is shorthand for :code:`{ 'type': TYPE-REF }`.
+The form TYPE-REF_ is shorthand for :code:`{ 'type': TYPE-REF }`.
 
 Example::
 
@@ -300,10 +306,10 @@ both members like this::
  { "file": "/some/place/my-image",
    "backing": "/some/place/my-backing-file" }
 
-The optional 'if' member specifies a conditional.  See "Configuring
-the schema" below for more on this.
+The optional 'if' member specifies a conditional.  See `Configuring
+the schema`_ below for more on this.
 
-The optional 'features' member specifies features.  See "Features"
+The optional 'features' member specifies features.  See Features_
 below for more on this.
 
 
@@ -337,7 +343,7 @@ union must have at least one branch.
 The BRANCH's STRING name is the branch name.
 
 The BRANCH's value defines the branch's properties, in particular its
-type.  The form TYPE-REF is shorthand for :code:`{ 'type': TYPE-REF }`.
+type.  The form TYPE-REF_ is shorthand for :code:`{ 'type': TYPE-REF }`.
 
 A simple union type defines a mapping from automatic discriminator
 values to data types like in this example::
@@ -368,12 +374,12 @@ Flat unions permit arbitrary common members that occur in all variants
 of the union, not just a discriminator.  Their discriminators need not
 be named 'type'.  They also avoid nesting on the wire.
 
-The 'base' member defines the common members.  If it is a MEMBERS
+The 'base' member defines the common members.  If it is a MEMBERS_
 object, it defines common members just like a struct type's 'data'
 member defines struct type members.  If it is a STRING, it names a
 struct type whose members are the common members.
 
-All flat union branches must be of struct type.
+All flat union branches must be `Struct types`_.
 
 In the Client JSON Protocol, a flat union is represented by an object
 with the common members (from the base type) and the selected branch's
@@ -425,10 +431,10 @@ is identical on the wire to::
  { 'union': 'Flat', 'base': { 'type': 'Enum' }, 'discriminator': 'type',
    'data': { 'one': 'Branch1', 'two': 'Branch2' } }
 
-The optional 'if' member specifies a conditional.  See "Configuring
-the schema" below for more on this.
+The optional 'if' member specifies a conditional.  See `Configuring
+the schema`_ below for more on this.
 
-The optional 'features' member specifies features.  See "Features"
+The optional 'features' member specifies features.  See Features_
 below for more on this.
 
 
@@ -481,10 +487,10 @@ following example objects::
              "read-only": false,
              "filename": "/tmp/mydisk.qcow2" } }
 
-The optional 'if' member specifies a conditional.  See "Configuring
-the schema" below for more on this.
+The optional 'if' member specifies a conditional.  See `Configuring
+the schema`_ below for more on this.
 
-The optional 'features' member specifies features.  See "Features"
+The optional 'features' member specifies features.  See Features_
 below for more on this.
 
 
@@ -511,10 +517,10 @@ Syntax::
 
 Member 'command' names the command.
 
-Member 'data' defines the arguments.  It defaults to an empty MEMBERS
+Member 'data' defines the arguments.  It defaults to an empty MEMBERS_
 object.
 
-If 'data' is a MEMBERS object, then MEMBERS defines arguments just
+If 'data' is a MEMBERS_ object, then MEMBERS defines arguments just
 like a struct type's 'data' defines struct type members.
 
 If 'data' is a STRING, then STRING names a complex type whose members
@@ -553,7 +559,7 @@ which would validate this Client JSON Protocol transaction::
 
 The generator emits a prototype for the C function implementing the
 command.  The function itself needs to be written by hand.  See
-section "Code generated for commands" for examples.
+section `Code generated for commands`_ for examples.
 
 The function returns the return type.  When member 'boxed' is absent,
 it takes the command arguments as arguments one by one, in QAPI schema
@@ -660,10 +666,10 @@ for a command.  We don't currently have a use case for both together and
 without a use case, it's not entirely clear what the semantics should
 be.
 
-The optional 'if' member specifies a conditional.  See "Configuring
-the schema" below for more on this.
+The optional 'if' member specifies a conditional.  See `Configuring
+the schema`_ below for more on this.
 
-The optional 'features' member specifies features.  See "Features"
+The optional 'features' member specifies features.  See Features_
 below for more on this.
 
 
@@ -708,15 +714,17 @@ Resulting in this JSON object::
 The generator emits a function to send the event.  When member 'boxed'
 is absent, it takes event-specific data one by one, in QAPI schema
 order.  Else it takes them wrapped in the C struct generated for the
-complex type.  See section "Code generated for events" for examples.
+complex type.  See section `Code generated for events`_ for examples.
 
-The optional 'if' member specifies a conditional.  See "Configuring
-the schema" below for more on this.
+The optional 'if' member specifies a conditional.  See `Configuring
+the schema`_ below for more on this.
 
-The optional 'features' member specifies features.  See "Features"
+The optional 'features' member specifies features.  See Features_
 below for more on this.
 
 
+.. _FEATURE:
+
 Features
 --------
 
@@ -735,8 +743,8 @@ For this purpose, a list of features can be specified for a command or
 struct type.  Each list member can either be ``{ 'name': STRING, '*if':
 COND }``, or STRING, which is shorthand for ``{ 'name': STRING }``.
 
-The optional 'if' member specifies a conditional.  See "Configuring
-the schema" below for more on this.
+The optional 'if' member specifies a conditional.  See `Configuring
+the schema`_ below for more on this.
 
 Example::
 
@@ -745,7 +753,7 @@ Example::
    'features': [ 'allow-negative-numbers' ] }
 
 The feature strings are exposed to clients in introspection, as
-explained in section "Client JSON Protocol introspection".
+explained in section `Client JSON Protocol introspection`_.
 
 Intended use is to have each feature string signal that this build of
 QEMU shows a certain behaviour.
@@ -764,7 +772,7 @@ Naming rules and reserved names
 All names must begin with a letter, and contain only ASCII letters,
 digits, hyphen, and underscore.  There are two exceptions: enum values
 may start with a digit, and names that are downstream extensions (see
-section Downstream extensions) start with underscore.
+section `Downstream extensions`_) start with underscore.
 
 Names beginning with ``q_`` are reserved for the generator, which uses
 them for munging QMP names that resemble C keywords or other
@@ -794,8 +802,9 @@ Any name (command, event, type, member, or enum value) beginning with
 ``x-`` is marked experimental, and may be withdrawn or changed
 incompatibly in a future release.
 
-Pragmas ``command-name-exceptions`` and ``member-name-exceptions`` let you
-violate naming rules.  Use for new code is strongly discouraged.
+Pragmas ``command-name-exceptions`` and ``member-name-exceptions`` let
+you violate naming rules.  Use for new code is strongly discouraged. See
+`Pragma directives`_ for details.
 
 
 Downstream extensions
@@ -851,7 +860,7 @@ member 'bar' ::
 A union's discriminator may not be conditional.
 
 Likewise, individual enumeration values be conditional.  This requires
-the longhand form of ENUM-VALUE.
+the longhand form of ENUM-VALUE_.
 
 Example: an enum type with unconditional value 'foo' and conditional
 value 'bar' ::
@@ -861,7 +870,7 @@ value 'bar' ::
      { 'name' : 'bar', 'if': 'defined(IFCOND)' } ] }
 
 Likewise, features can be conditional.  This requires the longhand
-form of FEATURE.
+form of FEATURE_.
 
 Example: a struct with conditional feature 'allow-negative-numbers' ::
 
@@ -893,7 +902,7 @@ If the documentation comment starts like ::
 it documents the definition of SYMBOL, else it's free-form
 documentation.
 
-See below for more on definition documentation.
+See below for more on `Definition documentation`_.
 
 Free-form documentation may be used to provide additional text and
 structuring content.
@@ -984,7 +993,7 @@ Definition documentation
 Definition documentation, if present, must immediately precede the
 definition it documents.
 
-When documentation is required (see pragma 'doc-required'), every
+When documentation is required (see pragma_ 'doc-required'), every
 definition must have documentation.
 
 Definition documentation starts with a line naming the definition,
@@ -1181,7 +1190,7 @@ the wire then.
 Each command or event defined with 'data' as MEMBERS object in the
 QAPI schema implicitly defines an object type.
 
-Example: the SchemaInfo for EVENT_C from section Events ::
+Example: the SchemaInfo for EVENT_C from section Events_ ::
 
     { "name": "EVENT_C", "meta-type": "event",
       "arg-type": "q_obj-EVENT_C-arg" }
@@ -1205,7 +1214,7 @@ extensions.  The "members" array is in no particular order; clients
 must search the entire object when learning whether a particular
 member is supported.
 
-Example: the SchemaInfo for MyType from section Struct types ::
+Example: the SchemaInfo for MyType from section `Struct types`_ ::
 
     { "name": "MyType", "meta-type": "object",
       "members": [
@@ -1216,7 +1225,7 @@ Example: the SchemaInfo for MyType from section Struct types ::
 "features" exposes the command's feature strings as a JSON array of
 strings.
 
-Example: the SchemaInfo for TestType from section Features::
+Example: the SchemaInfo for TestType from section Features_::
 
     { "name": "TestType", "meta-type": "object",
       "members": [
@@ -1232,7 +1241,7 @@ that provides the variant members for this type tag value).  The
 list cases in the same order as the corresponding "tag" enum type.
 
 Example: the SchemaInfo for flat union BlockdevOptions from section
-Union types ::
+`Union types`_ ::
 
     { "name": "BlockdevOptions", "meta-type": "object",
       "members": [
@@ -1247,13 +1256,13 @@ Note that base types are "flattened": its members are included in the
 "members" array.
 
 A simple union implicitly defines an enumeration type for its implicit
-discriminator (called "type" on the wire, see section Union types).
+discriminator (called "type" on the wire, see section `Union types`_).
 
 A simple union implicitly defines an object type for each of its
 variants.
 
 Example: the SchemaInfo for simple union BlockdevOptionsSimple from section
-Union types ::
+`Union types`_ ::
 
     { "name": "BlockdevOptionsSimple", "meta-type": "object",
       "members": [
@@ -1273,7 +1282,7 @@ a JSON object with member "type", which names a type.  Values of the
 alternate type conform to exactly one of its member types.  There is
 no guarantee on the order in which "members" will be listed.
 
-Example: the SchemaInfo for BlockdevRef from section Alternate types ::
+Example: the SchemaInfo for BlockdevRef from section `Alternate types`_ ::
 
     { "name": "BlockdevRef", "meta-type": "alternate",
       "members": [
@@ -1297,13 +1306,13 @@ variant member "values".  The values are listed in no particular
 order; clients must search the entire enum when learning whether a
 particular value is supported.
 
-Example: the SchemaInfo for MyEnum from section Enumeration types ::
+Example: the SchemaInfo for MyEnum from section `Enumeration types`_ ::
 
     { "name": "MyEnum", "meta-type": "enum",
       "values": [ "value1", "value2", "value3" ] }
 
 The SchemaInfo for a built-in type has the same name as the type in
-the QAPI schema (see section Built-in Types), with one exception
+the QAPI schema (see section `Built-in Types`_), with one exception
 detailed below.  It has variant member "json-type" that shows how
 values of this type are encoded on the wire.
 
@@ -1505,7 +1514,7 @@ Example::
 
     [Uninteresting stuff omitted...]
 
-For a modular QAPI schema (see section Include directives), code for
+For a modular QAPI schema (see section `Include directives`_), code for
 each sub-module SUBDIR/SUBMODULE.json is actually generated into ::
 
  SUBDIR/$(prefix)qapi-types-SUBMODULE.h
@@ -1643,7 +1652,7 @@ Example::
 
     [Uninteresting stuff omitted...]
 
-For a modular QAPI schema (see section Include directives), code for
+For a modular QAPI schema (see section `Include directives`_), code for
 each sub-module SUBDIR/SUBMODULE.json is actually generated into ::
 
  SUBDIR/$(prefix)qapi-visit-SUBMODULE.h
@@ -1773,7 +1782,7 @@ Example::
     }
     [Uninteresting stuff omitted...]
 
-For a modular QAPI schema (see section Include directives), code for
+For a modular QAPI schema (see section `Include directives`_), code for
 each sub-module SUBDIR/SUBMODULE.json is actually generated into::
 
  SUBDIR/$(prefix)qapi-commands-SUBMODULE.h
@@ -1862,7 +1871,7 @@ Example::
 
     [Uninteresting stuff omitted...]
 
-For a modular QAPI schema (see section Include directives), code for
+For a modular QAPI schema (see section `Include directives`_), code for
 each sub-module SUBDIR/SUBMODULE.json is actually generated into ::
 
  SUBDIR/$(prefix)qapi-events-SUBMODULE.h