Here we actually get bugs fixed! At many sites, mp_parse_arg_all's
first argument was the number of positional arguments required, rather
than the number actually supplied.
This fixes e.g., the bug where the linspace third positional argument
was not used as the "num" argmuent, and where too many positional args
were not treated as an error:
>>> ulab.linspace(0, 1, 9)
array([0.0, 0.125, 0.25, 0.375, 0.5, 0.625, 0.75, 0.875, 1.0], dtype=float)
>>> ulab.linspace(0, 1, 1, 1)
TypeError: extra positional arguments given
In the case of argmin/argmax of an iterable, it is now signaled to the user
that only the axis=None case is supported, instead of giving a wrong
result.
A declaration of a local variable can "shadow" a parameter or another
local variable declared in an outer scope.
Since this can create confusion about which variable is referred to, it
is better to fix these diagnostics.
A variety of changes were made:
- Add curly braces to reduce the scope of a variable (ndarray_unary_op)
so that its scope has ended before the next scope where it is used
- be consistent about whether a variable is declared with for-loop scope
or not (ndarray_print_row)
- remove a declaration so that the outer variable is used, after verifying
this will function properly (insert_slice_list)
- rename a variable introduced by a macro (RUN_SUM, RUN_STD) so it does
not shadow another variable
This diagnostic flag, enabled by default in CircuitPython, requires that
nonstatic functions have a previous prototype. Since placing prototypes
in header files is the only way that mismatched arguments between function
definition and use sites can be detected, this is a valuable warning.
In the case of ulab, the majority of the changes required were to mark
functions as "static" that were used only in a single C source file.
In CircuitPython (only), a the slice assignment to [-1👎-3] of an
ndarray of length 1 caused a crash. This appears to be because in
CircuitPython, the internal pointer of an empty array was NULL rather than
pointing at some memory which happened to be valid and assignable.
This appears to be a corner case of how integer promotion rules work in C.
The expression `slice.stop - slice.start + (slice.step + correction)`
is type `unsigned long` and on a LP64 platform its value is
18446744073709551614. This led to the function returning that this slice
had length 1 instead, during the automated tests.
By casting to signed types capable of holding indices and sizes, the
problem is corrected on both platforms.
