pythongh-107091: Fix the use of some C domain roles (python#107092)

Author: serhiy-storchaka

Doc/c-api/buffer.rst

@@ -225,7 +225,7 @@ object via :c:func:`PyObject_GetBuffer`. Since the complexity of the logical
 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
@@ -464,7 +464,7 @@ Buffer-related functions
 
 .. 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

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

@@ -145,7 +145,7 @@ or request "multi-phase initialization" by returning the definition struct itsel
 
    .. 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.
 
 ..