chore: get PyPy 3.7 wheels using NumPy 1.20

[henryiii]

Description

PyPy 3.7 wheels are included with NumPy 1.20. But not 3.6 since they've dropped 3.6 support.

Suggested changelog entry:

Just tests.

[henryiii]

If we have expected warnings, they need to be wrapped in a pytest warns block.

home/runner/work/pybind11/pybind11/tests/test_builtin_casters.py:302: DeprecationWarning: an integer is required (got type Int). Implicit conversion to integers using __int__ is deprecated, and may be removed in a future version of Python.
assert convert(Int()) == 42
test_builtin_casters.py::test_numpy_int_convert
/home/runner/work/pybind11/pybind11/tests/test_builtin_casters.py:332: DeprecationWarning: an integer is required (got type numpy.float32). Implicit conversion to integers using __int__ is deprecated, and may be removed in a future version of Python.
assert convert(np.float32(3.14159)) == 3

anyway, the Intel failure is just an infrastructure failure. The vagrind one seems to be a multi threading failure?

[YannickJadoul]

If we have expected warnings, they need to be wrapped in a pytest warns block.

The warnings are a reminder that we still need to further clean up int casters. I had them ignored, but basically, they are a consequence of calling PyLong_AsLong (or similar) on a non-PyLong object; Python's warning that that's deprecated. To be fixed in #2802, but that was too big of a change to manage to get into #2801 and v2.6.2. (I had first ignored the errors in #2801, until I understood that they are correctly warned for.)

[henryiii]

If they are in a warns block, I can grep for warns blocks. Maybe add a TODO or FIXME comment. I don't think we should have unhandled warnings in our tests. I originally thought it was an issue with the changes in NumPy 1.20.

[henryiii]

Any idea why (just) the valgrind job is failing with NumPy 1.20? All Pythons 3.7-3.9 are getting 1.20 now.

[bstaletic]

Any idea why (just) the valgrind job is failing with NumPy 1.20? All Pythons 3.7-3.9 are getting 1.20 now.

Because the suppressions in valgrind-numpy.supp don't match correctly now with the new numpy version. Perhaps we should use looser suppression rules.

[YannickJadoul]

If they are in a warns block, I can grep for warns blocks. Maybe add a TODO or FIXME comment. I don't think we should have unhandled warnings in our tests. I originally thought it was an issue with the changes in NumPy 1.20.

Yep, but there's no "expected warning" thing, like with expected errors? Also, those warnings have been there for a long time, so I don'tt feel like just shutting them up was the right thing to do.

Though maybe we should pick up the habit of turning warnings into errors, then. I don't know how long these warnings have been there (probably since we started supporting 3.8, because they're from Python >=3.8), but no one notices when builds pass.

[YannickJadoul]

This ought to fix Valgrind finding leaks in the new version of NumPy. At least locally, it works.

[henryiii]

https://docs.pytest.org/en/stable/warnings.html#warns ?

[henryiii]

LGTM (can't add the green check mark in the app?)

[YannickJadoul]

https://docs.pytest.org/en/stable/warnings.html#warns ?

That's also an option, ofc. That's not filtering warnings, but asserting for them.

It does say that:

DeprecationWarning and PendingDeprecationWarning are treated differently; see Ensuring code triggers a deprecation warning.

If you want, I can still add that? But again, we've had these warnings for ages, I believe. (All old logs have expired, though; just checked.)

[YannickJadoul]

If you want, I can still add that? But again, we've had these warnings for ages, I believe. (All old logs have expired, though; just checked.)

Done in #2838. Let's not care about that for this PR?

[YannickJadoul]

Merge if you want, @henryiii.