gh-107091: Fix the use of some C domain roles

Doc/c-api/buffer.rst

@@ -42,7 +42,7 @@
 underlying buffer in byte-oriented form.  Other forms are possible; for example,
 the elements exposed by an :class:`array.array` can be multi-byte values.
 
 An example consumer of the buffer interface is the :meth:`~io.BufferedIOBase.write`
 method of file objects: any object that can export a series of bytes through
 the buffer interface can be written to a file.  While :meth:`write` only
 needs read-only access to the internal contents of the object passed to it,
@@ -160,7 +160,7 @@
       a scalar. In this case, :c:member:`~Py_buffer.shape`, :c:member:`~Py_buffer.strides`
       and :c:member:`~Py_buffer.suboffsets` MUST be ``NULL``.
 
       The macro :c:macro:`PyBUF_MAX_NDIM` limits the maximum number of dimensions
       to 64. Exporters MUST respect this limit, consumers of multi-dimensional
       buffers SHOULD be able to handle up to :c:macro:`PyBUF_MAX_NDIM` dimensions.
 
@@ -225,7 +225,7 @@
 structure of the memory can vary drastically, the consumer uses the *flags*
 argument to specify the exact buffer type it can handle.
 
-All :c:data:`Py_buffer` fields are unambiguously defined by the request
+All :c:type:`Py_buffer` fields are unambiguously defined by the request
 type.
 
 request-independent fields
@@ -436,7 +436,7 @@
 
 .. c:function:: int PyObject_GetBuffer(PyObject *exporter, Py_buffer *view, int flags)
 
    Send a request to *exporter* to fill in *view* as specified by  *flags*.
    If the exporter cannot provide a buffer of the exact type, it MUST raise
    :c:data:`PyExc_BufferError`, set ``view->obj`` to ``NULL`` and
    return ``-1``.
@@ -446,7 +446,7 @@
    that redirect requests to a single object, ``view->obj`` MAY
    refer to this object instead of *exporter* (See :ref:`Buffer Object Structures <buffer-structs>`).
 
    Successful calls to :c:func:`PyObject_GetBuffer` must be paired with calls
    to :c:func:`PyBuffer_Release`, similar to :c:func:`malloc` and :c:func:`free`.
    Thus, after the consumer is done with the buffer, :c:func:`PyBuffer_Release`
    must be called exactly once.
@@ -464,7 +464,7 @@
 
 .. c:function:: Py_ssize_t PyBuffer_SizeFromFormat(const char *format)
 
-   Return the implied :c:data:`~Py_buffer.itemsize` from :c:data:`~Py_buffer.format`.
+   Return the implied :c:member:`~Py_buffer.itemsize` from :c:member:`~Py_buffer.format`.
    On error, raise an exception and return -1.
 
    .. versionadded:: 3.9
@@ -523,7 +523,7 @@
    *view* as specified by flags, unless *buf* has been designated as read-only
    and :c:macro:`PyBUF_WRITABLE` is set in *flags*.
 
    On success, set ``view->obj`` to a new reference to *exporter* and
    return 0. Otherwise, raise :c:data:`PyExc_BufferError`, set
    ``view->obj`` to ``NULL`` and return ``-1``;
 

Doc/c-api/method.rst

@@ -7,8 +7,8 @@ Instance Method Objects
 
 .. index:: pair: object; instancemethod
 
-An instance method is a wrapper for a :c:data:`PyCFunction` and the new way
-to bind a :c:data:`PyCFunction` to a class object. It replaces the former call
+An instance method is a wrapper for a :c:type:`PyCFunction` and the new way
+to bind a :c:type:`PyCFunction` to a class object. It replaces the former call
 ``PyMethod_New(func, NULL, class)``.
 
 

Doc/c-api/module.rst

@@ -37,7 +37,7 @@
       single: __package__ (module attribute)
       single: __loader__ (module attribute)
 
    Return a new module object with the :attr:`__name__` attribute set to *name*.
    The module's :attr:`__name__`, :attr:`__doc__`, :attr:`__package__`, and
    :attr:`__loader__` attributes are filled in (all but :attr:`__name__` are set
    to ``None``); the caller is responsible for providing a :attr:`__file__`
@@ -119,7 +119,7 @@
    encoded to 'utf-8'.
 
    .. deprecated:: 3.2
       :c:func:`PyModule_GetFilename` raises :c:type:`UnicodeEncodeError` on
       unencodable filenames, use :c:func:`PyModule_GetFilenameObject` instead.
 
 
@@ -143,9 +143,9 @@
    a module object. There is usually only one statically initialized variable
    of this type for each module.
 
    .. c:member:: PyModuleDef_Base m_base
 
-      Always initialize this member to :c:data:`PyModuleDef_HEAD_INIT`.
+      Always initialize this member to :c:macro:`PyModuleDef_HEAD_INIT`.
 
    .. c:member:: const char *m_name
 

Doc/c-api/type.rst

@@ -215,7 +215,7 @@ Type Objects
    ``Py_TYPE(self)`` may be a *subclass* of the intended class, and subclasses
    are not necessarily defined in the same module as their superclass.
    See :c:type:`PyCMethod` to get the class that defines the method.
-   See :c:func:`PyType_GetModuleByDef` for cases when ``PyCMethod`` cannot
+   See :c:func:`PyType_GetModuleByDef` for cases when :c:type:`!PyCMethod` cannot
    be used.
 
    .. versionadded:: 3.9

Doc/c-api/typeobj.rst

@@ -2255,8 +2255,8 @@ Number Object Structures
 
    .. note::
 
-      The :c:data:`nb_reserved` field should always be ``NULL``.  It
-      was previously called :c:data:`nb_long`, and was renamed in
+      The :c:member:`~PyNumberMethods.nb_reserved` field should always be ``NULL``.  It
+      was previously called :c:member:`!nb_long`, and was renamed in
       Python 3.0.1.
 
 .. c:member:: binaryfunc PyNumberMethods.nb_add

Doc/extending/extending.rst

@@ -237,10 +237,10 @@ Note that the Python name for the exception object is :exc:`spam.error`.  The
 being :exc:`Exception` (unless another class is passed in instead of ``NULL``),
 described in :ref:`bltin-exceptions`.
 
-Note also that the :c:data:`SpamError` variable retains a reference to the newly
+Note also that the :c:data:`!SpamError` variable retains a reference to the newly
 created exception class; this is intentional!  Since the exception could be
 removed from the module by external code, an owned reference to the class is
-needed to ensure that it will not be discarded, causing :c:data:`SpamError` to
+needed to ensure that it will not be discarded, causing :c:data:`!SpamError` to
 become a dangling pointer. Should it become a dangling pointer, C code which
 raises the exception could cause a core dump or other unintended side effects.
 
@@ -281,17 +281,17 @@ statement::
 It returns ``NULL`` (the error indicator for functions returning object pointers)
 if an error is detected in the argument list, relying on the exception set by
 :c:func:`PyArg_ParseTuple`.  Otherwise the string value of the argument has been
-copied to the local variable :c:data:`command`.  This is a pointer assignment and
+copied to the local variable :c:data:`!command`.  This is a pointer assignment and
 you are not supposed to modify the string to which it points (so in Standard C,
-the variable :c:data:`command` should properly be declared as ``const char
+the variable :c:data:`!command` should properly be declared as ``const char
 *command``).
 
 The next statement is a call to the Unix function :c:func:`system`, passing it
 the string we just got from :c:func:`PyArg_ParseTuple`::
 
    sts = system(command);
 
-Our :func:`spam.system` function must return the value of :c:data:`sts` as a
+Our :func:`!spam.system` function must return the value of :c:data:`!sts` as a
 Python object.  This is done using the function :c:func:`PyLong_FromLong`. ::
 
    return PyLong_FromLong(sts);

Doc/howto/isolating-extensions.rst

@@ -483,14 +483,14 @@ to get the state::
         return NULL;
     }
 
-``PyType_GetModuleByDef`` works by searching the
+:c:func:`!PyType_GetModuleByDef` works by searching the
 :term:`method resolution order` (i.e. all superclasses) for the first
 superclass that has a corresponding module.
 
 .. note::
 
    In very exotic cases (inheritance chains spanning multiple modules
-   created from the same definition), ``PyType_GetModuleByDef`` might not
+   created from the same definition), :c:func:`!PyType_GetModuleByDef` might not
    return the module of the true defining class. However, it will always
    return a module with the same definition, ensuring a compatible
    C memory layout.

Doc/whatsnew/3.11.rst

@@ -2227,7 +2227,7 @@ New Features
 
   (Contributed by Christian Heimes in :issue:`45459`.)
 
-* Added the :c:data:`PyType_GetModuleByDef` function, used to get the module
+* Added the :c:func:`PyType_GetModuleByDef` function, used to get the module
   in which a method was defined, in cases where this information is not
   available directly (via :c:type:`PyCMethod`).
   (Contributed by Petr Viktorin in :issue:`46613`.)

Doc/whatsnew/3.9.rst

@@ -1276,7 +1276,7 @@ New Features
 * :pep:`573`: Added :c:func:`PyType_FromModuleAndSpec` to associate
   a module with a class; :c:func:`PyType_GetModule` and
   :c:func:`PyType_GetModuleState` to retrieve the module and its state; and
-  :c:data:`PyCMethod` and :c:macro:`METH_METHOD` to allow a method to
+  :c:type:`PyCMethod` and :c:macro:`METH_METHOD` to allow a method to
   access the class it was defined in.
   (Contributed by Marcel Plch and Petr Viktorin in :issue:`38787`.)
 

Misc/NEWS.d/3.10.0a2.rst

@@ -847,8 +847,8 @@ Victor Stinner.
 .. section: C API
 
 Fix potential crash in deallocating method objects when dynamically
-allocated `PyMethodDef`'s lifetime is managed through the ``self`` argument
-of a `PyCFunction`.
+allocated :c:type:`PyMethodDef`'s lifetime is managed through the ``self`` argument
+of a :c:type:`PyCFunction`.
 
 ..
 

Misc/NEWS.d/3.12.0a1.rst

@@ -5934,7 +5934,7 @@ not override :c:member:`~PyTypeObject.tp_call` now inherit the
 .. nonce: aiRSgr
 .. section: C API
 
-Creating :c:data:`immutable types <Py_TPFLAGS_IMMUTABLETYPE>` with mutable
+Creating :c:macro:`immutable types <Py_TPFLAGS_IMMUTABLETYPE>` with mutable
 bases is deprecated and is planned to be disabled in Python 3.14.
 
 ..