[3.11] gh-93738: Documentation C syntax (:c:type:<C type> -> :c:expr:<C type>) (GH-97768) (#97924)

:c:type:`<C type>` -> :c:expr:`<C type>`

Co-authored-by: Łukasz Langa <lukasz@langa.pl>
(cherry picked from commit 0031e62973)

Co-authored-by: Adam Turner <9087854+AA-Turner@users.noreply.github.com>

Doc/extending/extending.rst

@@ -298,7 +298,7 @@ In this case, it will return an integer object.  (Yes, even integers are objects
 on the heap in Python!)
 
 If you have a C function that returns no useful argument (a function returning
-:c:type:`void`), the corresponding Python function must return ``None``.   You
+:c:expr:`void`), the corresponding Python function must return ``None``.   You
 need this idiom to do so (which is implemented by the :c:macro:`Py_RETURN_NONE`
 macro)::
 
@@ -1171,7 +1171,7 @@ other extension modules must be exported in a different way.
 
 Python provides a special mechanism to pass C-level information (pointers) from
 one extension module to another one: Capsules. A Capsule is a Python data type
-which stores a pointer (:c:type:`void \*`).  Capsules can only be created and
+which stores a pointer (:c:expr:`void \*`).  Capsules can only be created and
 accessed via their C API, but they can be passed around like any other Python
 object. In particular,  they can be assigned to a name in an extension module's
 namespace. Other extension modules can then import this module, retrieve the
@@ -1185,7 +1185,7 @@ different ways between the module providing the code and the client modules.
 
 Whichever method you choose, it's important to name your Capsules properly.
 The function :c:func:`PyCapsule_New` takes a name parameter
-(:c:type:`const char \*`); you're permitted to pass in a ``NULL`` name, but
+(:c:expr:`const char \*`); you're permitted to pass in a ``NULL`` name, but
 we strongly encourage you to specify a name.  Properly named Capsules provide
 a degree of runtime type-safety; there is no feasible way to tell one unnamed
 Capsule from another.
@@ -1203,7 +1203,7 @@ of certainty that the Capsule they load contains the correct C API.
 The following example demonstrates an approach that puts most of the burden on
 the writer of the exporting module, which is appropriate for commonly used
 library modules. It stores all C API pointers (just one in the example!) in an
-array of :c:type:`void` pointers which becomes the value of a Capsule. The header
+array of :c:expr:`void` pointers which becomes the value of a Capsule. The header
 file corresponding to the module provides a macro that takes care of importing
 the module and retrieving its C API pointers; client modules only have to call
 this macro before accessing the C API.

Doc/extending/newtypes.rst

@@ -207,7 +207,7 @@ a special case, for which the new value passed to the handler is ``NULL``.
 
 Python supports two pairs of attribute handlers; a type that supports attributes
 only needs to implement the functions for one pair.  The difference is that one
-pair takes the name of the attribute as a :c:type:`char\*`, while the other
+pair takes the name of the attribute as a :c:expr:`char\*`, while the other
 accepts a :c:type:`PyObject\*`.  Each type can use whichever pair makes more
 sense for the implementation's convenience. ::
 
@@ -339,8 +339,8 @@ of ``NULL`` is required.
 Type-specific Attribute Management
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-For simplicity, only the :c:type:`char\*` version will be demonstrated here; the
-type of the name parameter is the only difference between the :c:type:`char\*`
+For simplicity, only the :c:expr:`char\*` version will be demonstrated here; the
+type of the name parameter is the only difference between the :c:expr:`char\*`
 and :c:type:`PyObject\*` flavors of the interface. This example effectively does
 the same thing as the generic example above, but does not use the generic
 support added in Python 2.2.  It explains how the handler functions are