gh-93738: Documentation C syntax (:c:type:<C type> -> :c:expr:<C type>) (#97768)

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

Co-authored-by: Łukasz Langa <lukasz@langa.pl>

9 files changed, 29 insertions, 29 deletions

diff --git a/Doc/whatsnew/2.2.rst b/Doc/whatsnew/2.2.rst
index 9355c1b..bfb2aac 100644
--- a/Doc/whatsnew/2.2.rst
+++ b/Doc/whatsnew/2.2.rst
@@ -983,7 +983,7 @@ New and Improved Modules
   Jun-ichiro "itojun" Hagino.)
 
 * Two new format characters were added to the :mod:`struct` module for 64-bit
-  integers on platforms that support the C :c:type:`long long` type.  ``q`` is for
+  integers on platforms that support the C :c:expr:`long long` type.  ``q`` is for
   a signed 64-bit integer, and ``Q`` is for an unsigned one.  The value is
   returned in Python's long integer type.  (Contributed by Tim Peters.)
 
diff --git a/Doc/whatsnew/2.3.rst b/Doc/whatsnew/2.3.rst
index 27a0756..c6e2003 100644
--- a/Doc/whatsnew/2.3.rst
+++ b/Doc/whatsnew/2.3.rst
@@ -1905,8 +1905,8 @@ Changes to Python's build process and to the C API include:
   "")`` instead, but this will be slower than using :const:`METH_NOARGS`.
 
 * :c:func:`PyArg_ParseTuple` accepts new format characters for various sizes of
-  unsigned integers: ``B`` for :c:type:`unsigned char`, ``H`` for :c:type:`unsigned
-  short int`,  ``I`` for :c:type:`unsigned int`,  and ``K`` for :c:type:`unsigned
+  unsigned integers: ``B`` for :c:expr:`unsigned char`, ``H`` for :c:expr:`unsigned
+  short int`,  ``I`` for :c:expr:`unsigned int`,  and ``K`` for :c:expr:`unsigned
   long long`.
 
 * A new function, ``PyObject_DelItemString(mapping, char *key)`` was added
diff --git a/Doc/whatsnew/2.4.rst b/Doc/whatsnew/2.4.rst
index 61f9eb4..63e8198 100644
--- a/Doc/whatsnew/2.4.rst
+++ b/Doc/whatsnew/2.4.rst
@@ -472,7 +472,7 @@ PEP 327: Decimal Data Type
 ==========================
 
 Python has always supported floating-point (FP) numbers, based on the underlying
-C :c:type:`double` type, as a data type.  However, while most programming
+C :c:expr:`double` type, as a data type.  However, while most programming
 languages provide a floating-point type, many people (even programmers) are
 unaware that floating-point numbers don't represent certain decimal fractions
 accurately.  The new :class:`Decimal` type can represent these fractions
@@ -501,7 +501,7 @@ mantissa is multiplied by 4 (2 to the power of the exponent 2); 1.25 \* 4 equals
 5.
 
 Modern systems usually provide floating-point support that conforms to a
-standard called IEEE 754.  C's :c:type:`double` type is usually implemented as a
+standard called IEEE 754.  C's :c:expr:`double` type is usually implemented as a
 64-bit IEEE 754 number, which uses 52 bits of space for the mantissa.  This
 means that numbers can only be specified to 52 bits of precision.  If you're
 trying to represent numbers whose expansion repeats endlessly, the expansion is
@@ -750,10 +750,10 @@ The solution described in the PEP is to add three new functions to the Python
 API that perform ASCII-only conversions, ignoring the locale setting:
 
 * ``PyOS_ascii_strtod(str, ptr)``  and ``PyOS_ascii_atof(str, ptr)``
-  both convert a string to a C :c:type:`double`.
+  both convert a string to a C :c:expr:`double`.
 
 * ``PyOS_ascii_formatd(buffer, buf_len, format, d)`` converts a
-  :c:type:`double` to an ASCII string.
+  :c:expr:`double` to an ASCII string.
 
 The code for these functions came from the GLib library
 (https://developer.gnome.org/glib/stable/), whose developers kindly
diff --git a/Doc/whatsnew/2.5.rst b/Doc/whatsnew/2.5.rst
index dfa8f7e..0aca2fe 100644
--- a/Doc/whatsnew/2.5.rst
+++ b/Doc/whatsnew/2.5.rst
@@ -872,18 +872,18 @@ PEP 353: Using ssize_t as the index type
 ========================================
 
 A wide-ranging change to Python's C API, using a new  :c:type:`Py_ssize_t` type
-definition instead of :c:type:`int`,  will permit the interpreter to handle more
+definition instead of :c:expr:`int`,  will permit the interpreter to handle more
 data on 64-bit platforms. This change doesn't affect Python's capacity on 32-bit
 platforms.
 
-Various pieces of the Python interpreter used C's :c:type:`int` type to store
+Various pieces of the Python interpreter used C's :c:expr:`int` type to store
 sizes or counts; for example, the number of items in a list or tuple were stored
-in an :c:type:`int`.  The C compilers for most 64-bit platforms still define
-:c:type:`int` as a 32-bit type, so that meant that lists could only hold up to
+in an :c:expr:`int`.  The C compilers for most 64-bit platforms still define
+:c:expr:`int` as a 32-bit type, so that meant that lists could only hold up to
 ``2**31 - 1`` = 2147483647 items. (There are actually a few different
 programming models that 64-bit C compilers can use -- see
 https://unix.org/version2/whatsnew/lp64_wp.html for a discussion -- but the
-most commonly available model leaves :c:type:`int` as 32 bits.)
+most commonly available model leaves :c:expr:`int` as 32 bits.)
 
 A limit of 2147483647 items doesn't really matter on a 32-bit platform because
 you'll run out of memory before hitting the length limit. Each list item
@@ -895,7 +895,7 @@ It's possible to address that much memory on a 64-bit platform, however.  The
 pointers for a list that size would only require 16 GiB of space, so it's not
 unreasonable that Python programmers might construct lists that large.
 Therefore, the Python interpreter had to be changed to use some type other than
-:c:type:`int`, and this will be a 64-bit type on 64-bit platforms.  The change
+:c:expr:`int`, and this will be a 64-bit type on 64-bit platforms.  The change
 will cause incompatibilities on 64-bit machines, so it was deemed worth making
 the transition now, while the number of 64-bit users is still relatively small.
 (In 5 or 10 years, we may *all* be on 64-bit machines, and the transition would
@@ -909,7 +909,7 @@ may therefore need to have some variables changed to :c:type:`Py_ssize_t`.
 
 The :c:func:`PyArg_ParseTuple` and :c:func:`Py_BuildValue` functions have a new
 conversion code, ``n``, for :c:type:`Py_ssize_t`.   :c:func:`PyArg_ParseTuple`'s
-``s#`` and ``t#`` still output :c:type:`int` by default, but you can define the
+``s#`` and ``t#`` still output :c:expr:`int` by default, but you can define the
 macro  :c:macro:`PY_SSIZE_T_CLEAN` before including :file:`Python.h`  to make
 them return :c:type:`Py_ssize_t`.
 
@@ -1695,7 +1695,7 @@ attributes of the :class:`CDLL` object.   ::
    result = libc.printf("Line of output\n")
 
 Type constructors for the various C types are provided: :func:`c_int`,
-:func:`c_float`, :func:`c_double`, :func:`c_char_p` (equivalent to :c:type:`char
+:func:`c_float`, :func:`c_double`, :func:`c_char_p` (equivalent to :c:expr:`char
 \*`), and so forth.  Unlike Python's types, the C versions are all mutable; you
 can assign to their :attr:`value` attribute to change the wrapped value.  Python
 integers and strings will be automatically converted to the corresponding C
@@ -2093,7 +2093,7 @@ Changes to Python's build process and to the C API include:
 
 * The largest change to the C API came from :pep:`353`, which modifies the
   interpreter to use a :c:type:`Py_ssize_t` type definition instead of
-  :c:type:`int`.  See the earlier section :ref:`pep-353` for a discussion of this
+  :c:expr:`int`.  See the earlier section :ref:`pep-353` for a discussion of this
   change.
 
 * The design of the bytecode compiler has changed a great deal,  no longer
@@ -2264,7 +2264,7 @@ code:
   Setting  :attr:`rpc_paths` to ``None`` or an empty tuple disables  this path
   checking.
 
-* C API: Many functions now use :c:type:`Py_ssize_t`  instead of :c:type:`int` to
+* C API: Many functions now use :c:type:`Py_ssize_t`  instead of :c:expr:`int` to
   allow processing more data on 64-bit machines.  Extension code may need to make
   the same change to avoid warnings and to support 64-bit machines.  See the
   earlier section :ref:`pep-353` for a discussion of this change.
diff --git a/Doc/whatsnew/2.6.rst b/Doc/whatsnew/2.6.rst
index 5a3c103..731ce6a 100644
--- a/Doc/whatsnew/2.6.rst
+++ b/Doc/whatsnew/2.6.rst
@@ -2389,7 +2389,7 @@ changes, or look through the Subversion logs for all the details.
   has been updated from version 2.3.2 in Python 2.5 to
   version 2.4.1.
 
-* The :mod:`struct` module now supports the C99 :c:type:`_Bool` type,
+* The :mod:`struct` module now supports the C99 :c:expr:`_Bool` type,
   using the format character ``'?'``.
   (Contributed by David Remahl.)
 
diff --git a/Doc/whatsnew/2.7.rst b/Doc/whatsnew/2.7.rst
index 01f140d..e8f701d 100644
--- a/Doc/whatsnew/2.7.rst
+++ b/Doc/whatsnew/2.7.rst
@@ -2144,7 +2144,7 @@ Changes to Python's build process and to the C API include:
 
 * New functions: :c:func:`PyLong_AsLongAndOverflow` and
   :c:func:`PyLong_AsLongLongAndOverflow`  approximates a Python long
-  integer as a C :c:type:`long` or :c:type:`long long`.
+  integer as a C :c:expr:`long` or :c:expr:`long long`.
   If the number is too large to fit into
   the output type, an *overflow* flag is set and returned to the caller.
   (Contributed by Case Van Horsen; :issue:`7528` and :issue:`7767`.)
@@ -2202,7 +2202,7 @@ Changes to Python's build process and to the C API include:
 * New format codes: the :c:func:`PyFormat_FromString`,
   :c:func:`PyFormat_FromStringV`, and :c:func:`PyErr_Format` functions now
   accept ``%lld`` and ``%llu`` format codes for displaying
-  C's :c:type:`long long` types.
+  C's :c:expr:`long long` types.
   (Contributed by Mark Dickinson; :issue:`7228`.)
 
 * The complicated interaction between threads and process forking has
diff --git a/Doc/whatsnew/3.3.rst b/Doc/whatsnew/3.3.rst
index 609370b..fef1a8a 100644
--- a/Doc/whatsnew/3.3.rst
+++ b/Doc/whatsnew/3.3.rst
@@ -932,7 +932,7 @@ it can now be used as a class decorator (:issue:`10868`).
 array
 -----
 
-The :mod:`array` module supports the :c:type:`long long` type using ``q`` and
+The :mod:`array` module supports the :c:expr:`long long` type using ``q`` and
 ``Q`` type codes.
 
 (Contributed by Oren Tirosh and Hirokazu Yamamoto in :issue:`1172711`.)
diff --git a/Doc/whatsnew/3.7.rst b/Doc/whatsnew/3.7.rst
index 908f268..f06cf29 100644
--- a/Doc/whatsnew/3.7.rst
+++ b/Doc/whatsnew/3.7.rst
@@ -290,21 +290,21 @@ PEP 539: New C API for Thread-Local Storage
 
 While Python provides a C API for thread-local storage support; the existing
 :ref:`Thread Local Storage (TLS) API <thread-local-storage-api>` has used
-:c:type:`int` to represent TLS keys across all platforms.  This has not
+:c:expr:`int` to represent TLS keys across all platforms.  This has not
 generally been a problem for officially support platforms, but that is neither
 POSIX-compliant, nor portable in any practical sense.
 
 :pep:`539` changes this by providing a new :ref:`Thread Specific Storage (TSS)
 API <thread-specific-storage-api>` to CPython which supersedes use of the
 existing TLS API within the CPython interpreter, while deprecating the existing
-API.  The TSS API uses a new type :c:type:`Py_tss_t` instead of :c:type:`int`
+API.  The TSS API uses a new type :c:type:`Py_tss_t` instead of :c:expr:`int`
 to represent TSS keys--an opaque type the definition of which may depend on
 the underlying TLS implementation.  Therefore, this will allow to build CPython
 on platforms where the native TLS key is defined in a way that cannot be safely
-cast to :c:type:`int`.
+cast to :c:expr:`int`.
 
 Note that on platforms where the native TLS key is defined in a way that cannot
-be safely cast to :c:type:`int`, all functions of the existing TLS API will be
+be safely cast to :c:expr:`int`, all functions of the existing TLS API will be
 no-op and immediately return failure. This indicates clearly that the old API
 is not supported on platforms where it cannot be used reliably, and that no
 effort will be made to add such support.
@@ -1708,12 +1708,12 @@ Contributed by Paul Ganssle in :issue:`10381`.
 
 The type of results of :c:func:`PyThread_start_new_thread` and
 :c:func:`PyThread_get_thread_ident`, and the *id* parameter of
-:c:func:`PyThreadState_SetAsyncExc` changed from :c:type:`long` to
-:c:type:`unsigned long`.
+:c:func:`PyThreadState_SetAsyncExc` changed from :c:expr:`long` to
+:c:expr:`unsigned long`.
 (Contributed by Serhiy Storchaka in :issue:`6532`.)
 
 :c:func:`PyUnicode_AsWideCharString` now raises a :exc:`ValueError` if the
-second argument is ``NULL`` and the :c:type:`wchar_t*` string contains null
+second argument is ``NULL`` and the :c:expr:`wchar_t*` string contains null
 characters.  (Contributed by Serhiy Storchaka in :issue:`30708`.)
 
 Changes to the startup sequence and the management of dynamic memory
diff --git a/Doc/whatsnew/3.9.rst b/Doc/whatsnew/3.9.rst
index 6deaede..ff01a65 100644
--- a/Doc/whatsnew/3.9.rst
+++ b/Doc/whatsnew/3.9.rst
@@ -773,7 +773,7 @@ Optimizations
   Stinner in :issue:`38061`.)
 
 * :c:func:`PyLong_FromDouble` is now up to 1.87x faster for values that
-  fit into :c:type:`long`.
+  fit into :c:expr:`long`.
   (Contributed by Sergey Fedoseev in :issue:`37986`.)
 
 * A number of Python builtins (:class:`range`, :class:`tuple`, :class:`set`,