Add constant lowering support for SliceTypes - #6996

I noticed an issue with ndarray indexing while testing these changes:

import numpy as np
import numba


ts = slice(None, None, None)

@numba.njit
def test():
    return np.array([[1, 2], [3, 4]])[ts]


test_array = np.array([[1, 2], [3, 4]])
# Succeeds
assert np.array_equal(test(), test_array[ts])


ts2 = slice(1, None, None)

@numba.njit
def test2():
    return np.array([[1, 2], [3, 4]])[ts2]


# Fails
assert np.array_equal(test2(), test_array[ts2])

This doesn't appear to be caused by an obvious problem with slice constant lowering, because the following seems to confirm the expected changes between constant slice values:

import numpy as np
import numba


ts = slice(None, None, None)


@numba.njit
def test():
    return ts.start, ts.stop, ts.step


test()
# (0, 9223372036854775807, 1)

ts = slice(1, None, None)


@numba.njit
def test2():
    return ts.start, ts.stop, ts.step


test2()
# (1, 9223372036854775807, 1)

Any ideas?

I noticed this line in the test2.inspect_types() output:

    #   $22load_global.10 = global(ts: slice(1, None, None))  :: Literal[slice](slice(None, None, None))

I further traced the discrepancy implied by the comment above to the lower_cast from SliceLiteral to SliceType. My implementation is probably doing something wrong and—for example—equating a general type with more specific ones (e.g. via some sort of caching of which I'm presently unaware).

The issue is that the _typecache considers a Literal[slice](slice(1, None, None)) and Literal[slice](slice(None, None, None)) to be the same, due to SliceLiteral's use of SliceType.key (i.e. self.members).

All right, the issue with SliceLiteral has been fixed, and an explicit test was added.

Thanks very much for the PR, I've queued it for review.

I've added another commit relocating the tests and removing the unnecessary asserts. Tell me if you want me to squash/rebase these commits.

I'm assuming that someone will squash these commits; otherwise, adding commits that only fix earlier commits is quite painful.

@brandonwillard thank you for updating.