internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: numba/numba

Issue:
Wrong dtype of array inside reflected list
When trying to overload a numpy function that expects a list or tuple of boolean arrays there's a funny asymmetric behaviour going on. It looks like a bug, although maybe it's intended to be like this. When trying to query the dtype of the array, in one case it is `reflected list(array(int64, 1d, C))` and in the other one is `int64`. I think the second case should be the right answer in both cases.

```python
from numba import njit
from numba.extending import overload

@overload(np.select)
def np_select(arg):
    print('arg type', type(arg), '\narg[0] type', type(arg[0]), '\narg[0].dtype', arg[0].dtype)

@nb.njit
def test(arg):
    return np.select(arg)

test([np.arange(3)])
```
out when passing a list:
```python
arg type <class 'numba.types.containers.List'> 
arg[0] type <class 'numba.types.npytypes.Array'> 
arg[0].dtype reflected list(array(int64, 1d, C))
```
When passing a tuple
```
test((np.arange(3),))
```
out:
```python
arg type <class 'numba.types.containers.UniTuple'> 
arg[0] type <class 'numba.types.npytypes.Array'> 
arg[0].dtype int64
```
 




Discussion:
Thanks for the report. I think this is a bug in the type system class hierarchy. The `types.List` class should override the abstract `Type` class `__getitem__` to return a `self.dtype`.
@stuartarchibald, thanks for looking into it. I need it working to address #1313, so if you think it's easy I might have a go at it.
@luk-f-a great, thanks. I think it's just a question of doing literally the above, perhaps give it a try as it's only a couple of lines and see if that fixes it? Relevant file is `numba/types/containers.py` and the `List` class. I'm not sure if there'd be any unexpected side-effects :) !

Resolving patch:
diff --git a/numba/types/containers.py b/numba/types/containers.py
--- a/numba/types/containers.py
+++ b/numba/types/containers.py
@@ -359,6 +359,12 @@ def iterator_type(self):
     def is_precise(self):
         return self.dtype.is_precise()
 
+    def __getitem__(self, args):
+        """
+        Overrides the default __getitem__ from Type.
+        """
+        return self.dtype
+
 
 class ListIter(BaseContainerIterator):
     """


Test patch:
diff --git a/numba/tests/test_types.py b/numba/tests/test_types.py
--- a/numba/tests/test_types.py
+++ b/numba/tests/test_types.py
@@ -211,6 +211,12 @@ def test_call_notation(self):
         self.assertPreciseEqual(ty(5), np.timedelta64(5))
         self.assertPreciseEqual(ty('NaT'), np.timedelta64('NaT'))
 
+    def test_list_type_getitem(self):
+        for listty in (types.int64, types.Array(types.float64, 1, 'C')):
+            l_int = types.List(listty)
+            self.assertTrue(isinstance(l_int, types.List))
+            self.assertTrue(isinstance(l_int[0], type(listty)))
+
 
 class TestNumbers(TestCase):
     """
@@ -576,5 +582,6 @@ def impl():
         jit_impl = jit(nopython=True)(impl)
         self.assertEqual(impl(), jit_impl())
 
+
 if __name__ == '__main__':
     unittest.main()
Repository: numba/numba

Issue:
Make type.Optional string representation more friendly
<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

For e.g.  `types.Optional(types.float64)` the current `str()` is `?float64` which is fine, but it may be more helpful for users to produce something like:
 `OptionalType(float64) i.e. type 'float64 or None'`
such that an error message might read e.g.:
```
Dict.value_type cannot be of type OptionalType(float64) i.e. type 'float64 or None'
```
instead of:
```
Dict.value_type cannot be of type ?float64
```

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->



Discussion:
Hi @stuartarchibald, I will work on this issue. 

Regards
@guilhermeleobas great, thanks very much!

Resolving patch:
diff --git a/numba/types/misc.py b/numba/types/misc.py
--- a/numba/types/misc.py
+++ b/numba/types/misc.py
@@ -209,7 +209,7 @@ def __init__(self, typ):
         assert not isinstance(typ, (Optional, NoneType))
         typ = unliteral(typ)
         self.type = typ
-        name = "?%s" % typ
+        name = "OptionalType(%s) i.e. the type '%s or None'" % (typ, typ)
         super(Optional, self).__init__(name)
 
     @property


Test patch:
diff --git a/numba/tests/test_dicts.py b/numba/tests/test_dicts.py
--- a/numba/tests/test_dicts.py
+++ b/numba/tests/test_dicts.py
@@ -137,7 +137,7 @@ def foo(choice):
         with self.assertRaises(TypingError) as raises:
             foo(True)
         self.assertIn(
-            "Dict.value_type cannot be of type ?float64",
+            "Dict.value_type cannot be of type OptionalType(float64)",
             str(raises.exception),
         )
 
@@ -151,7 +151,7 @@ def foo(choice):
         with self.assertRaises(TypingError) as raises:
             foo(True)
         self.assertIn(
-            "Dict.key_type cannot be of type ?float64",
+            "Dict.key_type cannot be of type OptionalType(float64)",
             str(raises.exception),
         )
Repository: numba/numba

Issue:
Depend on enum34 using PEP 508 environment markers
<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

<!--

Please include details of the bug here, including, if applicable, what you
expected to happen!

-->

This is a straight up copy of https://github.com/numba/llvmlite/pull/483 

Looks like the offending lines are https://github.com/numba/numba/blob/master/setup.py#L309-L312 as mentioned by @esc 



Discussion:

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -306,10 +306,9 @@ def rec(path, pkg_name):
 build_requires = ['numpy']
 
 install_requires = ['llvmlite>=0.29.0dev0', 'numpy']
-if sys.version_info < (3, 4):
-    install_requires.extend(['enum34', 'singledispatch'])
-if sys.version_info < (3, 3):
-    install_requires.append('funcsigs')
+install_requires.extend(['enum34; python_version < "3.4"'])
+install_requires.extend(['singledispatch; python_version < "3.4"'])
+install_requires.extend(['funcsigs; python_version < "3.3"'])
 
 metadata = dict(
     name='numba',


Test patch:
Repository: numba/numba

Issue:
np.int8 and np.unit8 doesn't work with np.bincount function.
<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the latest released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

Numba version: 0.44.0
Numpy version: 1.16.2


### Reproduction of an issue
```python
import numpy as np
from numba import njit

@njit()
def get_event_count1(grp, wgt):
    return np.bincount(grp, weights=wgt)


def get_event_count2(grp, wgt):
    return np.bincount(grp, weights=wgt)


np.random.seed(42)
N = 10000
group = np.random.randint(0, 10, N)
target = np.random.randint(0, 2, N).astype(np.uint8)

print(f'With njit: {sum(get_event_count1(grp=group, wgt=target))}\nWithout njit: {sum(get_event_count2(grp=group, wgt=target))}')
>>> With njit: 1449
>>> Without njit: 5033.0
```


Discussion:

Resolving patch:
diff --git a/numba/targets/arraymath.py b/numba/targets/arraymath.py
--- a/numba/targets/arraymath.py
+++ b/numba/targets/arraymath.py
@@ -2951,7 +2951,9 @@ def np_bincount(a, weights=None):
 
     if weights not in (None, types.none):
         validate_1d_array_like("bincount", weights)
-        out_dtype = weights.dtype
+        # weights is promoted to double in C impl
+        # https://github.com/numpy/numpy/blob/maintenance/1.16.x/numpy/core/src/multiarray/compiled_base.c#L93-L95
+        out_dtype = np.float64
 
         @register_jitable
         def validate_inputs(a, weights):


Test patch:
diff --git a/numba/tests/test_np_functions.py b/numba/tests/test_np_functions.py
--- a/numba/tests/test_np_functions.py
+++ b/numba/tests/test_np_functions.py
@@ -520,8 +520,8 @@ def test_bincount2(self):
         cfunc = jit(nopython=True)(pyfunc)
         for seq in self.bincount_sequences():
             w = [math.sqrt(x) - 2 for x in seq]
-            # weights as list, then array
-            for weights in (w, np.array(w)):
+            # weights as list, then array, mixed types, check upcast is ok
+            for weights in (w, np.array(w), seq, np.array(seq)):
                 expected = pyfunc(seq, weights)
                 got = cfunc(seq, weights)
                 self.assertPreciseEqual(expected, got)
Repository: numba/numba

Issue:
Make it so that the `numba.__version__` ends up in the reportable error message copy-paste sections.
<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Feature request

Make it so that the `numba.__version__` ends up in the reportable error message copy-paste sections.

<!--

Please include details of the feature you would like to see, why you would
like to see it/the use case

-->



Discussion:
https://github.com/numba/numba/commit/11a00b87136e79d54074fbfdc888db4948b52f52 does this, but for help messages.

Resolving patch:
diff --git a/numba/__init__.py b/numba/__init__.py
--- a/numba/__init__.py
+++ b/numba/__init__.py
@@ -8,6 +8,10 @@
 import sys
 import warnings
 
+from ._version import get_versions
+__version__ = get_versions()['version']
+del get_versions
+
 from . import config, errors, _runtests as runtests, types
 
 # Re-export typeof
@@ -174,7 +178,3 @@ def _try_enable_svml():
 Is set to True if Intel SVML is in use.
 """
 config.USING_SVML = _try_enable_svml()
-
-from ._version import get_versions
-__version__ = get_versions()['version']
-del get_versions
diff --git a/numba/errors.py b/numba/errors.py
--- a/numba/errors.py
+++ b/numba/errors.py
@@ -345,8 +345,9 @@ def termcolor():
 reportable_issue_info = """
 -------------------------------------------------------------------------------
 This should not have happened, a problem has occurred in Numba's internals.
+You are currently using Numba version %s.
 %s
-""" % feedback_details
+""" % (numba.__version__, feedback_details)
 
 error_extras = dict()
 error_extras['unsupported_error'] = unsupported_error_info


Test patch:
Repository: numba/numba

Issue:
Potential regression in _analyze_op_call_numpy_reshape
The Numba intgration testing project may have revealed a regression in `_analyze_op_call_numpy_reshape` by testing pygbm.

https://github.com/numba/numba-integration-testing/pull/14

Full log output can be found attached to the pull-request mentioned above, there are  58 (about 1/3) of the tests that failed and they all seem to be pointing to `_analyze_op_call_numpy_reshape`.

@DrTodd13 I saw via `git blame` that you were the last person to modify that function, could you perhaps take a quick look?


Discussion:

Resolving patch:
diff --git a/numba/array_analysis.py b/numba/array_analysis.py
--- a/numba/array_analysis.py
+++ b/numba/array_analysis.py
@@ -1727,7 +1727,7 @@ def _analyze_op_call_numpy_reshape(self, scope, equiv_set, args, kws):
                 stmts.append(div_calc)
                 calc_size_var = div_calc_size_var
             # Put the calculated value back into the reshape arguments, replacing the negative.
-            args[neg_one_index] = div_calc_size_var
+            args[neg_one_index] = calc_size_var
 
         return tuple(args[1:]), stmts
 


Test patch:
Repository: numba/numba

Issue:
Use different cuOccupancyMaxPotentialBlockSize call?
As per https://github.com/numba/numba/pull/4581#issuecomment-532880510, we should investigate if there is a different call we can make that removes the need to create a cfunc that always returns zero.


Discussion:
Oh, the callback can be null and the dyanmic-shared-memory size can be passed as a constant:

> If per-block dynamic shared memory allocation is needed, then if the dynamic shared memory size is constant regardless of block size, the size should be passed through dynamicSMemSize, and blockSizeToDynamicSMemSize should be NULL.

Resolving patch:
diff --git a/numba/cuda/compiler.py b/numba/cuda/compiler.py
--- a/numba/cuda/compiler.py
+++ b/numba/cuda/compiler.py
@@ -15,7 +15,6 @@
 from numba.typing.templates import AbstractTemplate, ConcreteTemplate
 from numba import funcdesc, typing, utils, serialize
 from numba.compiler_lock import global_compiler_lock
-from numba import cfunc
 
 from .cudadrv.autotune import AutoTuner
 from .cudadrv.devices import get_context
@@ -254,11 +253,6 @@ def __init__(self, name, sig):
         self.sig = sig
 
 
-@cfunc("uint64(int32)")
-def _b2d_func(tpb):
-    return 0
-
-
 class ForAll(object):
     def __init__(self, kernel, ntasks, tpb, stream, sharedmem):
         self.kernel = kernel
@@ -290,7 +284,7 @@ def _compute_thread_per_block(self, kernel):
             ctx = get_context()
             kwargs = dict(
                 func=kernel._func.get(),
-                b2d_func=_b2d_func.address,
+                b2d_func=0,     # dynamic-shared memory is constant to blksz
                 memsize=self.sharedmem,
                 blocksizelimit=1024,
             )
diff --git a/numba/cuda/cudadrv/driver.py b/numba/cuda/cudadrv/driver.py
--- a/numba/cuda/cudadrv/driver.py
+++ b/numba/cuda/cudadrv/driver.py
@@ -690,7 +690,10 @@ def get_active_blocks_per_multiprocessor(self, func, blocksize, memsize, flags=N
     def get_max_potential_block_size(self, func, b2d_func, memsize, blocksizelimit, flags=None):
         """Suggest a launch configuration with reasonable occupancy.
         :param func: kernel for which occupancy is calculated
-        :param b2d_func: function that calculates how much per-block dynamic shared memory 'func' uses based on the block size.
+        :param b2d_func: function that calculates how much per-block dynamic
+                         shared memory 'func' uses based on the block size.
+                         Can also be the address of a C function.
+                         Use `0` to pass `NULL` to the underlying CUDA API.
         :param memsize: per-block dynamic shared memory usage intended, in bytes
         :param blocksizelimit: maximum block size the kernel is designed to handle"""
 


Test patch:
Repository: numba/numba

Issue:
Python 3.7 warns on `from collections import Iterable`
[This line](https://github.com/numba/numba/blob/master/numba/types/containers.py#L3) in `containers.py` is causing a `DeprecationWarning` on python3.7. Is that a known issue? The message is `Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working`


Discussion:
Good catch.  We should fix this in our next patch release which is adding Python 3.8 support anyway.

Resolving patch:
diff --git a/numba/six.py b/numba/six.py
--- a/numba/six.py
+++ b/numba/six.py
@@ -780,9 +780,11 @@ def wrapper(f):
 
 
 if sys.version_info[:2] < (3, 3):
-    from collections import Mapping, MutableMapping, Sequence, MutableSequence
+    from collections import (Mapping, MutableMapping, Sequence,
+                             MutableSequence, Iterable)
 else:
-    from collections.abc import Mapping, MutableMapping, Sequence, MutableSequence
+    from collections.abc import (Mapping, MutableMapping, Sequence,
+                                 MutableSequence, Iterable)
 
 
 def with_metaclass(meta, *bases):
diff --git a/numba/types/containers.py b/numba/types/containers.py
--- a/numba/types/containers.py
+++ b/numba/types/containers.py
@@ -1,7 +1,6 @@
 from __future__ import print_function, division, absolute_import
 
-from collections import Iterable
-
+from ..six import Iterable
 from .abstract import (ConstSized, Container, Hashable, MutableSequence,
                        Sequence, Type, TypeRef)
 from .common import Buffer, IterableType, SimpleIterableType, SimpleIteratorType


Test patch:
Repository: numba/numba

Issue:
Numba 0.46.0 depends on pkg_resources but does not declare a setuptools dependency
Results in this CI failure on a system without any `setuptools` installation:

https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=85208

Stack trace is:

```
    import numba
  File "/home/conda/feedstock_root/build_artifacts/clifford_1572349688184/.../lib/python3.7/site-packages/numba/__init__.py", line 30, in <module>
    from .decorators import (autojit, cfunc, generated_jit, jit, njit, stencil,
  File "/home/conda/feedstock_root/build_artifacts/clifford_1572349688184/.../lib/python3.7/site-packages/numba/decorators.py", line 14, in <module>
    from .targets import registry
  File "/home/conda/feedstock_root/build_artifacts/clifford_1572349688184/.../lib/python3.7/site-packages/numba/targets/registry.py", line 5, in <module>
    from . import cpu
  File "/home/conda/feedstock_root/build_artifacts/clifford_1572349688184/.../lib/python3.7/site-packages/numba/targets/cpu.py", line 20, in <module>
    import numba.entrypoints
  File "/home/conda/feedstock_root/build_artifacts/clifford_1572349688184/.../lib/python3.7/site-packages/numba/entrypoints.py", line 3, in <module>
    from pkg_resources import iter_entry_points
ModuleNotFoundError: No module named 'pkg_resources'
```

cc @hugohadfield


Discussion:
Good catch.  We should fix this in our planned patch release.
Note this is already fixed in numba 0.46.0_1 on conda-forge

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -308,7 +308,7 @@ def rec(path, pkg_name):
 
 build_requires = ['numpy']
 
-install_requires = ['llvmlite>=0.30.0dev0', 'numpy']
+install_requires = ['llvmlite>=0.30.0dev0', 'numpy', 'setuptools']
 install_requires.extend(['enum34; python_version < "3.4"'])
 install_requires.extend(['singledispatch; python_version < "3.4"'])
 install_requires.extend(['funcsigs; python_version < "3.3"'])


Test patch:
Repository: numba/numba

Issue:
semantic constant prop needs to run before static* rewrites
<!--

Thanks for opening an issue! To help the Numba team handle your information
efficiently, please first ensure that there is no other issue present that
already describes the issue you have
(search at https://github.com/numba/numba/issues?&q=is%3Aissue).

For more general "how do I do X?" type questions, please speak to us in real
time on https://gitter.im/numba/numba or post to the Numba mailing list
https://groups.google.com/a/continuum.io/forum/#!forum/numba-users.

-->

## Reporting a bug

<!--

Before submitting a bug report please ensure that you can check off these boxes:

-->

- [x] I am using the ~master~ released version of Numba (most recent is visible in
 the change log (https://github.com/numba/numba/blob/master/CHANGE_LOG).
- [x] I have included below a minimal working reproducer (if you are unsure how
 to write one see http://matthewrocklin.com/blog/work/2018/02/28/minimal-bug-reports).

```python
from numba import generated_jit
import numpy as np

@generated_jit(nopython=True)
def f(a, b):
    def specialize(a, b):
        return a.shape[:b.ndim] # <-- b.ndim get's rewritten to "2" but it's too late as the generic const-expr rewrite has already happened
    return specialize

print(f(np.zeros((5, 4, 3, 2)), np.zeros((1, 1))))
```
the semantic rewrite pass runs after the `rewrites` (which includes the rewrite for `getitem`->`static_getitem`), as a result the above fails as the `b.nim` const isn't present. I think the fix is probably to just switch the order of these passes as it makes sense for as many constants to be in the IR ahead of the static rewriting phase.


Discussion:

Resolving patch:
diff --git a/numba/compiler.py b/numba/compiler.py
--- a/numba/compiler.py
+++ b/numba/compiler.py
@@ -441,9 +441,9 @@ def define_nopython_pipeline(state, name='nopython'):
 
         # pre typing
         if not state.flags.no_rewrites:
-            pm.add_pass(GenericRewrites, "nopython rewrites")
             pm.add_pass(RewriteSemanticConstants, "rewrite semantic constants")
             pm.add_pass(DeadBranchPrune, "dead branch pruning")
+            pm.add_pass(GenericRewrites, "nopython rewrites")
 
         pm.add_pass(InlineClosureLikes,
                     "inline calls to locally defined closures")


Test patch:
diff --git a/numba/tests/test_analysis.py b/numba/tests/test_analysis.py
--- a/numba/tests/test_analysis.py
+++ b/numba/tests/test_analysis.py
@@ -633,3 +633,14 @@ def impl(fa):
         FakeArrayType = types.NamedUniTuple(types.int64, 1, FakeArray)
         self.assert_prune(impl, (FakeArrayType,), [None], fa,
                           flags=enable_pyobj_flags)
+
+    def test_semantic_const_propagates_before_static_rewrites(self):
+        # see issue #5015, the ndim needs writing in as a const before
+        # the rewrite passes run to make e.g. getitems static where possible
+        @njit
+        def impl(a, b):
+            return a.shape[:b.ndim]
+
+        args = (np.zeros((5, 4, 3, 2)), np.zeros((1, 1)))
+
+        self.assertPreciseEqual(impl(*args), impl.py_func(*args))
Repository: numba/numba

Issue:
bump max llvmlite version to accept 0.32.0
Now that llvmlite 0.32.0rc1 is released. We need to bump the accepted version to `0.33.0.dev0`


Discussion:

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -12,7 +12,7 @@
 min_numpy_build_version = "1.11"
 min_numpy_run_version = "1.15"
 min_llvmlite_version = "0.31.0.dev0"
-max_llvmlite_version = "0.32.0.dev0"
+max_llvmlite_version = "0.33.0.dev0"
 
 if sys.platform.startswith('linux'):
     # Patch for #2555 to make wheels without libpython


Test patch: