Bug C backend: For loops u64

[ronnuriel]

Error in for loop:

from lpython import (
    i8, i16, u16, i32, i64, u64, u16,
    ccall, ccallback, overload,
    CPtr, c_p_pointer, Pointer,
    packed, dataclass, sizeof,
)
t: u64 = u64(10)
num_iters: u64 = t
i: u64
for i in range(num_iters):
    print(i)

Error:

semantic error: Type mismatch in loop start and loop end values, the types must be compatible
  --> testlpython.py:10:1 - 11:12
   |
10 |    for i in range(num_iters):
   |    ^^^^^^^^^^^^^^^^^^^^^^^^^^...
...
   |
11 |        print(i)
   | ...^^^^^^^^^^^^ type mismatch ('i64' and 'u64')
   |
10 | for i in range(num_iters):
   |                ^^^^^^^^^ type mismatch ('i64' and 'u64')

[certik]

Currently range returns and accepts i64, so you have to use i64 as the loop iterator as well as the argument to range().

There are two issues here:

• Using unsigned integers as loop iterators
• "overload" range to also accept unsigned integers

So far we decided not to allow unsigned integers for either. We can change it, although in that case we need to figure out a consistent design for unsigned integers regarding the usage.

@ronnuriel for now just use i64 for both range and a loop iterator.

[rebcabin]

Because regular Python (CPython) doesn't have unsigned ints, I recommend we stay with unsigned ints for all non-numerical work: indexes, ranges, etc.

[certik]

I would be even stricter: we recommend to use unsigned to interface with C and for storage, say u16 is quite common. But for numerical work as well as non-numerical work like indices, ranges, loop iterators, always use signed integers. If you don't know what to use, use signed.

Only use unsigned for:

• interfacing with C if C uses unsigned
• when you NEED to use the range 0-255 or 0-65535 and you are limited on space.

All other times, use the default integer, which is i32, or if you need larger integers, use i64.