Fix sphinx warnings in c-info.beyond-basics.

Author: cmarmo

doc/source/reference/c-api/array.rst

@@ -1278,6 +1278,14 @@ New data types
     registered (checked only by the address of the pointer), then
     return the previously-assigned type-number.
 
+.. c:function:: int PyArray_TypeNumFromName( \
+        char const *str)
+
+   Given a string return the type-number for the data-type with that string as
+   the type-object name.
+   Returns NPY_NOTYPE without setting an error if no type can be found.
+   Only works for user-defined data-types.
+
 .. c:function:: int PyArray_RegisterCastFunc( \
         PyArray_Descr* descr, int totype, PyArray_VectorUnaryFunc* castfunc)
 
@@ -2555,6 +2563,10 @@ Broadcasting (multi-iterators)
     through all of the elements (of the broadcasted result), otherwise
     it evaluates FALSE.
 
+.. c:function:: int PyArray_MultiIter_SIZE(PyObject* multi)
+
+    Returne the size of the multi-iterator object.
+
 .. c:function:: int PyArray_Broadcast(PyArrayMultiIterObject* mit)
 
     This function encapsulates the broadcasting rules. The *mit*

doc/source/user/c-info.beyond-basics.rst

@@ -172,7 +172,7 @@ iterators so that all that needs to be done to advance to the next element in
 each array is for PyArray_ITER_NEXT to be called for each of the inputs. This
 incrementing is automatically performed by
 :c:func:`PyArray_MultiIter_NEXT` ( ``obj`` ) macro (which can handle a
-multiterator ``obj`` as either a :c:expr:`PyArrayMultiObject *` or a
+multiterator ``obj`` as either a :c:expr:`PyArrayMultiIterObject *` or a
 :c:expr:`PyObject *`). The data from input number ``i`` is available using
 :c:func:`PyArray_MultiIter_DATA` ( ``obj``, ``i`` ) and the total (broadcasted)
 size as :c:func:`PyArray_MultiIter_SIZE` ( ``obj``). An example of using this
@@ -330,7 +330,7 @@ function :c:func:`PyArray_RegisterCanCast` (from_descr, totype_number,
 scalarkind) should be used to specify that the data-type object
 from_descr can be cast to the data-type with type number
 totype_number. If you are not trying to alter scalar coercion rules,
-then use :c:data:`NPY_NOSCALAR` for the scalarkind argument.
+then use :c:enumerator:`NPY_NOSCALAR` for the scalarkind argument.
 
 If you want to allow your new data-type to also be able to share in
 the scalar coercion rules, then you need to specify the scalarkind
@@ -340,7 +340,7 @@ available to that function). Then, you can register data-types that
 can be cast to separately for each scalar kind that may be returned
 from your user-defined data-type. If you don't register scalar
 coercion handling, then all of your user-defined data-types will be
-seen as :c:data:`NPY_NOSCALAR`.
+seen as :c:enumerator:`NPY_NOSCALAR`.
 
 
 Registering a ufunc loop
@@ -472,7 +472,7 @@ The __array_finalize\__ method
    members are filled in. Finally, the :obj:`~numpy.class.__array_finalize__`
    attribute is looked-up in the object dictionary. If it is present
    and not None, then it can be either a CObject containing a pointer
-   to a :c:func:`PyArray_FinalizeFunc` or it can be a method taking a
+   to a ``PyArray_FinalizeFunc`` or it can be a method taking a
    single argument (which could be None).
 
    If the :obj:`~numpy.class.__array_finalize__` attribute is a CObject, then the pointer

numpy/core/include/numpy/ndarraytypes.h

@@ -1308,6 +1308,8 @@ typedef struct {
 #define PyArray_MultiIter_NOTDONE(multi)                \
         (_PyMIT(multi)->index < _PyMIT(multi)->size)
 
+#define PyArray_MultiIter_SIZE(multi)                \
+        _PyMIT(multi)->size
 
 /*
  * Store the information needed for fancy-indexing over an array. The