Graham Markall

What do you think the benefit of adding a test that checks for the current failing behaviour is? IIUC the discussion in #8997 suggested that the test should be added...

We need to rework the way we get source line info to use `inspect.getsourcelines()` (as the error reporting and caching mechanisms use) to be able to get the source line...

Thanks for making changes. For future changes - please could you avoid force-pushing as this tends to confuse the Github review interface - many thanks in advance!

Having skimmed over the latest revision, I'm not going to be able to spend more time reviewing this PR in its current form - I think it would be helpful...

Thanks for the report and reproducer - I don't think this is limited to the CUDA target, but is a general issue: ```python from numba import cuda, njit # type:...

I think the following demonstrates a potential workaround: ```python from numba import cuda, njit, types # type: ignore from numba.core import cgutils from numba.core.extending import lower_builtin import numpy as np...

Labelling as "good first issue", as it could be fixed by taking the above workaround and upstreaming it into `numba/np/arrayobj.py`, alongside the addition of tests.

Removing "good first issue" in case there is extra complexity here as discussed in the triage meeting on 15 Jan.

Is there somewhere in the docs you've seen that it's stated that raising exceptions from within threads has unspecified behaviour? I'm not clear about whether this should be a bug...

Many thanks for the info! I'll mention this at the triage meeting on Jan 16th.