Type inference problem with literal unroll

[luk-f-a]

I am getting a strange typing error when using literal_unroll:

from numba import njit, literal_unroll
import numpy as np


points = np.arange(20)
mapper = (1,2)
vect = np.zeros(20)

@njit
def foo(points, out, mapper):

    t_start = points[0]
    assert t_start == 0
    t_end = points[-1]

    for idx in literal_unroll(mapper):
        aux = np.zeros(t_end - t_start + 1, np.float64)
    return out

foo(points, vect, mapper)

yields (on v.0.50)

TypingError: Failed in nopython mode pipeline (step: nopython frontend)
Type of variable 'aux.69' cannot be determined, operation: $60call_method.11.68, location: <ipython-input-9-ac1b4e60e276> (17)

File "<ipython-input-9-ac1b4e60e276>", line 17:
def foo(points, out, mapper):
    <source elided>
    for idx in literal_unroll(mapper):
        aux = np.zeros(t_end - t_start + 1, np.float64)

What is very strange is that the problem disappears if the assert line is removed.
I tracked the type inference with NUMBA_DEBUG_TYPEINFER and found that initially the variable is correctly typed, but at a later point it is marked as <undecided>. It might be related to SSA, because aux is correctly typed but aux.69 is not.

[stuartarchibald]

Thanks for the report. I think there's likely more than one thing being a problem here.

1. The CFG simplification function that runs in the tail of the loop canonicaliser that literal_unroll is using is erroneously wiping out the assert exit block. it's not that, blocks just get massively reordered, they are still there.
2. With the pass patched to prevent 1., there's something weird going on in typing that's preventing the tuple type of mapper being discovered through the literal_unroll call.