Siu Kwan Lam

Do we have a test for this for both loop and branch restructing?

I can confirm that the reproducer breaks on the interpolation:HEAD with numba:HEAD and works with numba:0.59.1

As we have guessed in the triage meeting, it is indeed caused by defaulting to new_style error. First bad commit: c8789f7910fb41dfd7fc1fd1b594a4d91c684d40. Problem also exist with `NUMBA_CAPTURED_ERRORS=new_style` on 0.59.1

Interpolation needs to be patched. The best practice for using literal types is to set `prefer_literal=True` on the `@overload`. Old-style error hides the problem due to the fallback. Numba tries...

To Debug: Test is failing because fastest changing stride can be zero even when array layout is C or F.

The problem is demonstrated by: ```python import numpy as np from numba import njit @njit def foo(out): return out arr = np.random.rand(0, 3) out = foo(arr) assert arr is out...

Conclusion from triage discussion: Options: 1. put stride store code in a optnone function to prevent `llvm.assume` setting it to a constant. 1. change boxing code to make set stride...

@max-sixty, can you add a news fragment for this PR? It will then be part of the release note. See https://github.com/numba/numba/tree/main/docs/upcoming_changes for README and examples.

@dlee992, after discussing in today's triage, we think that target-extension API can fulfill the same needs. See https://github.com/numba/numba/blob/556545c5b2b162574c600490a855ba8856255154/numba/tests/test_target_extension.py#L387-L394 for an example. The other problem with proposed API of `@overload(.., override=True)`...

I'd classify this as a feature request to expand support to `typing.NamedTuple`. All tuple/namedtuple support predates that.