Issue #18589: fix hyperlinking of type slots (tp_*)

Doc/c-api/allocation.rst

@@ -32,7 +32,7 @@ Allocating Objects on the Heap
    Allocate a new Python object using the C structure type *TYPE* and the
    Python type object *type*.  Fields not defined by the Python object header
    are not initialized; the object's reference count will be one.  The size of
-   the memory allocation is determined from the :attr:`tp_basicsize` field of
+   the memory allocation is determined from the :c:member:`~PyTypeObject.tp_basicsize` field of
    the type object.
 
 
@@ -41,7 +41,7 @@ Allocating Objects on the Heap
    Allocate a new Python object using the C structure type *TYPE* and the
    Python type object *type*.  Fields not defined by the Python object header
    are not initialized.  The allocated memory allows for the *TYPE* structure
-   plus *size* fields of the size given by the :attr:`tp_itemsize` field of
+   plus *size* fields of the size given by the :c:member:`~PyTypeObject.tp_itemsize` field of
    *type*.  This is useful for implementing objects like tuples, which are
    able to determine their size at construction time.  Embedding the array of
    fields into the same allocation decreases the number of allocations,
@@ -52,7 +52,7 @@ Allocating Objects on the Heap
 
    Releases memory allocated to an object using :c:func:`PyObject_New` or
    :c:func:`PyObject_NewVar`.  This is normally called from the
-   :attr:`tp_dealloc` handler specified in the object's type.  The fields of
+   :c:member:`~PyTypeObject.tp_dealloc` handler specified in the object's type.  The fields of
    the object should not be accessed after this call as the memory is no
    longer a valid Python object.
 

Doc/c-api/exceptions.rst

@@ -607,28 +607,28 @@ recursion depth automatically).
    Ends a :c:func:`Py_EnterRecursiveCall`.  Must be called once for each
    *successful* invocation of :c:func:`Py_EnterRecursiveCall`.
 
-Properly implementing :attr:`tp_repr` for container types requires
+Properly implementing :c:member:`~PyTypeObject.tp_repr` for container types requires
 special recursion handling.  In addition to protecting the stack,
-:attr:`tp_repr` also needs to track objects to prevent cycles.  The
+:c:member:`~PyTypeObject.tp_repr` also needs to track objects to prevent cycles.  The
 following two functions facilitate this functionality.  Effectively,
 these are the C equivalent to :func:`reprlib.recursive_repr`.
 
 .. c:function:: int Py_ReprEnter(PyObject *object)
 
-   Called at the beginning of the :attr:`tp_repr` implementation to
+   Called at the beginning of the :c:member:`~PyTypeObject.tp_repr` implementation to
    detect cycles.
 
    If the object has already been processed, the function returns a
-   positive integer.  In that case the :attr:`tp_repr` implementation
+   positive integer.  In that case the :c:member:`~PyTypeObject.tp_repr` implementation
    should return a string object indicating a cycle.  As examples,
    :class:`dict` objects return ``{...}`` and :class:`list` objects
    return ``[...]``.
 
    The function will return a negative integer if the recursion limit
-   is reached.  In that case the :attr:`tp_repr` implementation should
+   is reached.  In that case the :c:member:`~PyTypeObject.tp_repr` implementation should
    typically return ``NULL``.
 
-   Otherwise, the function returns zero and the :attr:`tp_repr`
+   Otherwise, the function returns zero and the :c:member:`~PyTypeObject.tp_repr`
    implementation can continue normally.
 
 .. c:function:: void Py_ReprLeave(PyObject *object)

Doc/c-api/gcsupport.rst

@@ -12,10 +12,10 @@ other objects, or which only store references to atomic types (such as numbers
 or strings), do not need to provide any explicit support for garbage
 collection.
 
-To create a container type, the :attr:`tp_flags` field of the type object must
+To create a container type, the :c:member:`~PyTypeObject.tp_flags` field of the type object must
 include the :const:`Py_TPFLAGS_HAVE_GC` and provide an implementation of the
-:attr:`tp_traverse` handler.  If instances of the type are mutable, a
-:attr:`tp_clear` implementation must also be provided.
+:c:member:`~PyTypeObject.tp_traverse` handler.  If instances of the type are mutable, a
+:c:member:`~PyTypeObject.tp_clear` implementation must also be provided.
 
 
 .. data:: Py_TPFLAGS_HAVE_GC
@@ -57,7 +57,7 @@ Constructors for container types must conform to two rules:
    Adds the object *op* to the set of container objects tracked by the
    collector.  The collector can run at unexpected times so objects must be
    valid while being tracked.  This should be called once all the fields
-   followed by the :attr:`tp_traverse` handler become valid, usually near the
+   followed by the :c:member:`~PyTypeObject.tp_traverse` handler become valid, usually near the
    end of the constructor.
 
 
@@ -86,8 +86,8 @@ rules:
    Remove the object *op* from the set of container objects tracked by the
    collector.  Note that :c:func:`PyObject_GC_Track` can be called again on
    this object to add it back to the set of tracked objects.  The deallocator
-   (:attr:`tp_dealloc` handler) should call this for the object before any of
-   the fields used by the :attr:`tp_traverse` handler become invalid.
+   (:c:member:`~PyTypeObject.tp_dealloc` handler) should call this for the object before any of
+   the fields used by the :c:member:`~PyTypeObject.tp_traverse` handler become invalid.
 
 
 .. c:function:: void _PyObject_GC_UNTRACK(PyObject *op)
@@ -95,19 +95,19 @@ rules:
    A macro version of :c:func:`PyObject_GC_UnTrack`.  It should not be used for
    extension modules.
 
-The :attr:`tp_traverse` handler accepts a function parameter of this type:
+The :c:member:`~PyTypeObject.tp_traverse` handler accepts a function parameter of this type:
 
 
 .. c:type:: int (*visitproc)(PyObject *object, void *arg)
 
-   Type of the visitor function passed to the :attr:`tp_traverse` handler.
+   Type of the visitor function passed to the :c:member:`~PyTypeObject.tp_traverse` handler.
    The function should be called with an object to traverse as *object* and
-   the third parameter to the :attr:`tp_traverse` handler as *arg*.  The
+   the third parameter to the :c:member:`~PyTypeObject.tp_traverse` handler as *arg*.  The
    Python core uses several visitor functions to implement cyclic garbage
    detection; it's not expected that users will need to write their own
    visitor functions.
 
-The :attr:`tp_traverse` handler must have the following type:
+The :c:member:`~PyTypeObject.tp_traverse` handler must have the following type:
 
 
 .. c:type:: int (*traverseproc)(PyObject *self, visitproc visit, void *arg)
@@ -119,15 +119,15 @@ The :attr:`tp_traverse` handler must have the following type:
    object argument.  If *visit* returns a non-zero value that value should be
    returned immediately.
 
-To simplify writing :attr:`tp_traverse` handlers, a :c:func:`Py_VISIT` macro is
-provided.  In order to use this macro, the :attr:`tp_traverse` implementation
+To simplify writing :c:member:`~PyTypeObject.tp_traverse` handlers, a :c:func:`Py_VISIT` macro is
+provided.  In order to use this macro, the :c:member:`~PyTypeObject.tp_traverse` implementation
 must name its arguments exactly *visit* and *arg*:
 
 
 .. c:function:: void Py_VISIT(PyObject *o)
 
    Call the *visit* callback, with arguments *o* and *arg*. If *visit* returns
-   a non-zero value, then return it.  Using this macro, :attr:`tp_traverse`
+   a non-zero value, then return it.  Using this macro, :c:member:`~PyTypeObject.tp_traverse`
    handlers look like::
 
       static int
@@ -138,7 +138,7 @@ must name its arguments exactly *visit* and *arg*:
           return 0;
       }
 
-The :attr:`tp_clear` handler must be of the :c:type:`inquiry` type, or *NULL*
+The :c:member:`~PyTypeObject.tp_clear` handler must be of the :c:type:`inquiry` type, or *NULL*
 if the object is immutable.
 
 

Doc/c-api/type.rst

@@ -37,10 +37,10 @@ Type Objects
 
 .. c:function:: long PyType_GetFlags(PyTypeObject* type)
 
-   Return the :attr:`tp_flags` member of *type*. This function is primarily
+   Return the :c:member:`~PyTypeObject.tp_flags` member of *type*. This function is primarily
    meant for use with `Py_LIMITED_API`; the individual flag bits are
    guaranteed to be stable across Python releases, but access to
-   :attr:`tp_flags` itself is not part of the limited API.
+   :c:member:`~PyTypeObject.tp_flags` itself is not part of the limited API.
 
    .. versionadded:: 3.2
 
@@ -70,14 +70,14 @@ Type Objects
 
 .. c:function:: PyObject* PyType_GenericAlloc(PyTypeObject *type, Py_ssize_t nitems)
 
-   Generic handler for the :attr:`tp_alloc` slot of a type object.  Use
+   Generic handler for the :c:member:`~PyTypeObject.tp_alloc` slot of a type object.  Use
    Python's default memory allocation mechanism to allocate a new instance and
    initialize all its contents to *NULL*.
 
 .. c:function:: PyObject* PyType_GenericNew(PyTypeObject *type, PyObject *args, PyObject *kwds)
 
-   Generic handler for the :attr:`tp_new` slot of a type object.  Create a
-   new instance using the type's :attr:`tp_alloc` slot.
+   Generic handler for the :c:member:`~PyTypeObject.tp_new` slot of a type object.  Create a
+   new instance using the type's :c:member:`~PyTypeObject.tp_alloc` slot.
 
 .. c:function:: int PyType_Ready(PyTypeObject *type)
 

Doc/library/gc.rst

@@ -121,8 +121,8 @@ The :mod:`gc` module provides the following functions:
 
    Return a list of objects directly referred to by any of the arguments. The
    referents returned are those objects visited by the arguments' C-level
-   :attr:`tp_traverse` methods (if any), and may not be all objects actually
-   directly reachable.  :attr:`tp_traverse` methods are supported only by objects
+   :c:member:`~PyTypeObject.tp_traverse` methods (if any), and may not be all objects actually
+   directly reachable.  :c:member:`~PyTypeObject.tp_traverse` methods are supported only by objects
    that support garbage collection, and are only required to visit objects that may
    be involved in a cycle.  So, for example, if an integer is directly reachable
    from an argument, that integer object may or may not appear in the result list.

Doc/library/stdtypes.rst

@@ -751,7 +751,7 @@ support:
    iterators for those iteration types.  (An example of an object supporting
    multiple forms of iteration would be a tree structure which supports both
    breadth-first and depth-first traversal.)  This method corresponds to the
-   :attr:`tp_iter` slot of the type structure for Python objects in the Python/C
+   :c:member:`~PyTypeObject.tp_iter` slot of the type structure for Python objects in the Python/C
    API.
 
 The iterator objects themselves are required to support the following two
@@ -762,7 +762,7 @@ methods, which together form the :dfn:`iterator protocol`:
 
    Return the iterator object itself.  This is required to allow both containers
    and iterators to be used with the :keyword:`for` and :keyword:`in` statements.
-   This method corresponds to the :attr:`tp_iter` slot of the type structure for
+   This method corresponds to the :c:member:`~PyTypeObject.tp_iter` slot of the type structure for
    Python objects in the Python/C API.
 
 
@@ -770,7 +770,7 @@ methods, which together form the :dfn:`iterator protocol`:
 
    Return the next item from the container.  If there are no further items, raise
    the :exc:`StopIteration` exception.  This method corresponds to the
-   :attr:`tp_iternext` slot of the type structure for Python objects in the
+   :c:member:`~PyTypeObject.tp_iternext` slot of the type structure for Python objects in the
    Python/C API.
 
 Python defines several iterator objects to support iteration over general and

Doc/whatsnew/2.2.rst

@@ -450,9 +450,9 @@ signal that the iterator is done.
 Python classes can define an :meth:`__iter__` method, which should create and
 return a new iterator for the object; if the object is its own iterator, this
 method can just return ``self``.  In particular, iterators will usually be their
-own iterators.  Extension types implemented in C can implement a :attr:`tp_iter`
+own iterators.  Extension types implemented in C can implement a :c:member:`~PyTypeObject.tp_iter`
 function in order to return an iterator, and extension types that want to behave
-as iterators can define a :attr:`tp_iternext` function.
+as iterators can define a :c:member:`~PyTypeObject.tp_iternext` function.
 
 So, after all this, what do iterators actually do?  They have one required
 method, :meth:`next`, which takes no arguments and returns the next value.  When
@@ -478,7 +478,7 @@ there are no more values to be returned, calling :meth:`next` should raise the
 In 2.2, Python's :keyword:`for` statement no longer expects a sequence; it
 expects something for which :func:`iter` will return an iterator. For backward
 compatibility and convenience, an iterator is automatically constructed for
-sequences that don't implement :meth:`__iter__` or a :attr:`tp_iter` slot, so
+sequences that don't implement :meth:`__iter__` or a :c:member:`~PyTypeObject.tp_iter` slot, so
 ``for i in [1,2,3]`` will still work.  Wherever the Python interpreter loops
 over a sequence, it's been changed to use the iterator protocol.  This means you
 can do things like this::