gh-107091: Fix some uses of :c:type: role

Doc/c-api/tuple.rst

@@ -114,6 +114,8 @@
    raises :exc:`MemoryError` or :exc:`SystemError`.
 
 
+.. _struct-sequence-objects:
+
 Struct Sequence Objects
 -----------------------
 
@@ -163,7 +165,7 @@
 
 .. c:type:: PyStructSequence_Field
 
    Describes a field of a struct sequence. As a struct sequence is modeled as a
    tuple, all fields are typed as :c:expr:`PyObject*`.  The index in the
    :attr:`fields` array of the :c:type:`PyStructSequence_Desc` determines which
    field of the struct sequence is described.

Doc/c-api/typeobj.rst

@@ -163,9 +163,9 @@
 
 .. [#cols] Columns:
 
-   **"O"**:  set on :c:type:`PyBaseObject_Type`
+   **"O"**:  set on :c:data:`PyBaseObject_Type`
 
-   **"T"**:  set on :c:type:`PyType_Type`
+   **"T"**:  set on :c:data:`PyType_Type`
 
    **"D"**:  default (if slot is set to ``NULL``)
 
@@ -484,7 +484,7 @@
 PyObject Slots
 --------------
 
 The type object structure extends the :c:type:`PyVarObject` structure. The
 :attr:`ob_size` field is used for dynamic types (created by :func:`type_new`,
 usually called from a class statement). Note that :c:data:`PyType_Type` (the
 metatype) initializes :c:member:`~PyTypeObject.tp_itemsize`, which means that its instances (i.e.
@@ -493,7 +493,7 @@
 
 .. c:member:: Py_ssize_t PyObject.ob_refcnt
 
    This is the type object's reference count, initialized to ``1`` by the
    ``PyObject_HEAD_INIT`` macro.  Note that for :ref:`statically allocated type
    objects <static-types>`, the type's instances (objects whose :attr:`ob_type`
    points back to the type) do *not* count as references.  But for
@@ -518,7 +518,7 @@
 
       Foo_Type.ob_type = &PyType_Type;
 
    This should be done before any instances of the type are created.
    :c:func:`PyType_Ready` checks if :attr:`ob_type` is ``NULL``, and if so,
    initializes it to the :attr:`ob_type` field of the base class.
    :c:func:`PyType_Ready` will not change this field if it is non-zero.
@@ -540,7 +540,7 @@
    allocated objects <heap-types>`, these two fields are used to link the
    object into a doubly linked list of *all* live objects on the heap.
 
    This could be used for various debugging purposes; currently the only uses
    are the :func:`sys.getobjects` function and to print the objects that are
    still alive at the end of a run when the environment variable
    :envvar:`PYTHONDUMPREFS` is set.
@@ -567,10 +567,10 @@
 PyTypeObject Slots
 ------------------
 
 Each slot has a section describing inheritance.  If :c:func:`PyType_Ready`
 may set a value when the field is set to ``NULL`` then there will also be
-a "Default" section.  (Note that many fields set on :c:type:`PyBaseObject_Type`
-and :c:type:`PyType_Type` effectively act as defaults.)
+a "Default" section.  (Note that many fields set on :c:data:`PyBaseObject_Type`
+and :c:data:`PyType_Type` effectively act as defaults.)
 
 .. c:member:: const char* PyTypeObject.tp_name
 
@@ -964,7 +964,7 @@
 
    **Default:**
 
-   :c:type:`PyBaseObject_Type` uses :c:func:`PyObject_GenericGetAttr`.
+   :c:data:`PyBaseObject_Type` uses :c:func:`PyObject_GenericGetAttr`.
 
 
 .. c:member:: setattrofunc PyTypeObject.tp_setattro
@@ -990,7 +990,7 @@
 
    **Default:**
 
-   :c:type:`PyBaseObject_Type` uses :c:func:`PyObject_GenericSetAttr`.
+   :c:data:`PyBaseObject_Type` uses :c:func:`PyObject_GenericSetAttr`.
 
 
 .. c:member:: PyBufferProcs* PyTypeObject.tp_as_buffer
@@ -1031,7 +1031,7 @@
 
    **Default:**
 
-   :c:type:`PyBaseObject_Type` uses
+   :c:data:`PyBaseObject_Type` uses
    ``Py_TPFLAGS_DEFAULT | Py_TPFLAGS_BASETYPE``.
 
    **Bit Masks:**
@@ -1556,7 +1556,7 @@
 
    **Default:**
 
-   :c:type:`PyBaseObject_Type` provides a :attr:`tp_richcompare`
+   :c:data:`PyBaseObject_Type` provides a :attr:`tp_richcompare`
    implementation, which may be inherited.  However, if only
    :attr:`tp_hash` is defined, not even the inherited function is used
    and instances of the type will not be able to participate in any
@@ -1878,7 +1878,7 @@
    :c:func:`PyType_GenericAlloc`, to force a standard heap
    allocation strategy.
 
-   For static subtypes, :c:type:`PyBaseObject_Type` uses
+   For static subtypes, :c:data:`PyBaseObject_Type` uses
    :c:func:`PyType_GenericAlloc`.  That is the recommended value
    for all statically defined types.
 
@@ -1941,7 +1941,7 @@
    match :c:func:`PyType_GenericAlloc` and the value of the
    :c:macro:`Py_TPFLAGS_HAVE_GC` flag bit.
 
-   For static subtypes, :c:type:`PyBaseObject_Type` uses PyObject_Del.
+   For static subtypes, :c:data:`PyBaseObject_Type` uses :c:func:`PyObject_Del`.
 
 
 .. c:member:: inquiry PyTypeObject.tp_is_gc

Doc/conf.py

@@ -90,6 +90,10 @@
     ('c:type', 'uintmax_t'),
     ('c:type', 'va_list'),
     ('c:type', 'wchar_t'),
+    ('c:struct', 'in6_addr'),
+    ('c:struct', 'in_addr'),
+    ('c:struct', 'stat'),
+    ('c:struct', 'statvfs'),
     # Standard C macros
     ('c:macro', 'LLONG_MAX'),
     ('c:macro', 'LLONG_MIN'),

Doc/library/os.rst

@@ -2420,13 +2420,13 @@ features:
 .. function:: major(device, /)
 
    Extract the device major number from a raw device number (usually the
-   :attr:`st_dev` or :attr:`st_rdev` field from :c:type:`stat`).
+   :attr:`st_dev` or :attr:`st_rdev` field from :c:struct:`stat`).
 
 
 .. function:: minor(device, /)
 
    Extract the device minor number from a raw device number (usually the
-   :attr:`st_dev` or :attr:`st_rdev` field from :c:type:`stat`).
+   :attr:`st_dev` or :attr:`st_rdev` field from :c:struct:`stat`).
 
 
 .. function:: makedev(major, minor, /)
@@ -2937,7 +2937,7 @@ features:
 .. class:: stat_result
 
    Object whose attributes correspond roughly to the members of the
-   :c:type:`stat` structure. It is used for the result of :func:`os.stat`,
+   :c:struct:`stat` structure. It is used for the result of :func:`os.stat`,
    :func:`os.fstat` and :func:`os.lstat`.
 
    Attributes:
@@ -3117,12 +3117,12 @@ features:
       See the ``IO_REPARSE_TAG_*`` constants in the :mod:`stat` module.
 
    The standard module :mod:`stat` defines functions and constants that are
-   useful for extracting information from a :c:type:`stat` structure. (On
+   useful for extracting information from a :c:struct:`stat` structure. (On
    Windows, some items are filled with dummy values.)
 
    For backward compatibility, a :class:`stat_result` instance is also
    accessible as a tuple of at least 10 integers giving the most important (and
-   portable) members of the :c:type:`stat` structure, in the order
+   portable) members of the :c:struct:`stat` structure, in the order
    :attr:`st_mode`, :attr:`st_ino`, :attr:`st_dev`, :attr:`st_nlink`,
    :attr:`st_uid`, :attr:`st_gid`, :attr:`st_size`, :attr:`st_atime`,
    :attr:`st_mtime`, :attr:`st_ctime`. More items may be added at the end by
@@ -3174,7 +3174,7 @@ features:
 
    Perform a :c:func:`statvfs` system call on the given path.  The return value is
    an object whose attributes describe the filesystem on the given path, and
-   correspond to the members of the :c:type:`statvfs` structure, namely:
+   correspond to the members of the :c:struct:`statvfs` structure, namely:
    :attr:`f_bsize`, :attr:`f_frsize`, :attr:`f_blocks`, :attr:`f_bfree`,
    :attr:`f_bavail`, :attr:`f_files`, :attr:`f_ffree`, :attr:`f_favail`,
    :attr:`f_flag`, :attr:`f_namemax`, :attr:`f_fsid`.

Doc/whatsnew/2.4.rst

@@ -1491,7 +1491,7 @@ Some of the changes to Python's build process and to the C API are:
   though that processor architecture doesn't call that register "the TSC
   register".  (Contributed by Jeremy Hylton.)
 
-* The :c:type:`tracebackobject` type has been renamed to
+* The :c:type:`!tracebackobject` type has been renamed to
   :c:type:`PyTracebackObject`.
 
 .. ======================================================================

Doc/whatsnew/3.2.rst

@@ -566,7 +566,7 @@ Some smaller changes made to the core Python language are:
 
   (See :issue:`4617`.)
 
-* The internal :c:type:`structsequence` tool now creates subclasses of tuple.
+* :ref:`Struct sequence types <struct-sequence-objects>` are now subclasses of tuple.
   This means that C structures like those returned by :func:`os.stat`,
   :func:`time.gmtime`, and :data:`sys.version_info` now work like a
   :term:`named tuple` and now work with functions and methods that

Doc/whatsnew/3.3.rst

@@ -2195,7 +2195,7 @@ Changes to Python's build process and to the C API include:
     * :c:func:`PyUnicode_AsUCS4`, :c:func:`PyUnicode_AsUCS4Copy`
     * :c:macro:`PyUnicode_DATA`, :c:macro:`PyUnicode_1BYTE_DATA`,
       :c:macro:`PyUnicode_2BYTE_DATA`, :c:macro:`PyUnicode_4BYTE_DATA`
-    * :c:macro:`PyUnicode_KIND` with :c:type:`PyUnicode_Kind` enum:
+    * :c:macro:`PyUnicode_KIND` with :c:enum:`PyUnicode_Kind` enum:
       :c:data:`PyUnicode_WCHAR_KIND`, :c:data:`PyUnicode_1BYTE_KIND`,
       :c:data:`PyUnicode_2BYTE_KIND`, :c:data:`PyUnicode_4BYTE_KIND`
     * :c:macro:`PyUnicode_READ`, :c:macro:`PyUnicode_READ_CHAR`, :c:macro:`PyUnicode_WRITE`

Doc/whatsnew/3.7.rst

@@ -1677,7 +1677,7 @@ module imports.
 The fields :c:member:`name` and :c:member:`doc` of structures
 :c:type:`PyMemberDef`, :c:type:`PyGetSetDef`,
 :c:type:`PyStructSequence_Field`, :c:type:`PyStructSequence_Desc`,
-and :c:type:`wrapperbase` are now of type ``const char *`` rather of
+and :c:struct:`wrapperbase` are now of type ``const char *`` rather of
 ``char *``.  (Contributed by Serhiy Storchaka in :issue:`28761`.)
 
 The result of :c:func:`PyUnicode_AsUTF8AndSize` and :c:func:`PyUnicode_AsUTF8`

Misc/NEWS.d/3.10.0a7.rst

@@ -215,8 +215,8 @@ a non-Python signal handler.
 .. nonce: VouZjn
 .. section: Core and Builtins
 
-Add ``__match_args__`` to :c:type:`structsequence` based classes. Patch by
-Pablo Galindo.
+Add ``__match_args__`` to :ref:`struct sequence objects <struct-sequence-objects>`.
+Patch by Pablo Galindo.
 
 ..