Windows with AVX512F is failing a typing test

[mattip]

From the numpy-wheels repo, see this comment. The windows runs have been failing since Feb 14. The failing test is in static typing:

with pytest.raises(np.ComplexWarning):
>       np.einsum("i,i->i", AR_LIKE_U, AR_LIKE_U, dtype=float, casting="unsafe", out=OUT_c)
E       Failed: DID NOT RAISE <class 'numpy.ComplexWarning'>

and occurs with an Azure machine that reports

NumPy CPU features: SSE SSE2 SSE3 SSSE3* SSE41* POPCNT* SSE42* AVX* F16C* \
    FMA3* AVX2* AVX512F* AVX512CD* AVX512_SKX* AVX512_CLX? AVX512_CNL?

where the machines in the regular CI report

NumPy CPU features: SSE SSE2 SSE3 SSSE3* SSE41* POPCNT* SSE42* AVX* F16C* \
    FMA3* AVX2* AVX512F? AVX512CD? AVX512_SKX? AVX512_CLX? AVX512_CNL?

Note the AVX512F, AVX512CD, AVX512_SKX difference.

@seiko2plus, @BvB93 ideas? Is there a way to reproduce this with concrete types?

I am not sure what the difference is between the CI configuration and why they are getting different machines. A successful run log is here, a failure is here

[BvB93]

The test in question seems to fail at runtime (see the simplified version below).

It could be modified such that it no longer uses the complex out array (which is not strictly necessary here),
but it does nevertheless raise the question why no ComplexWarning is issued in the numpy-wheels tests.

import numpy as np
import pytest

AR_LIKE_U = ["1", "2", "3"]
OUT_c = np.empty(3, dtype=np.complex128)

with pytest.raises(np.ComplexWarning):
    np.einsum("i,i->i", AR_LIKE_U, AR_LIKE_U, dtype=float, casting="unsafe", out=OUT_c)

[charris]

Probably want to keep the issue open even if the typing test is fixed.

[seberg]

So one potential issue is that the test would make more sense to me if it used pytest.warns. pytest.warns should set up the warning fitlers to "always" to ensure the warning cannot be set to ignore (similar to warnings.catch_warnings). But pytest.raises likely will not bother with "fixing" the warning filters.
The problem is that if this warning – for whatever weird reason – was ignored elsewhere and the warning-filters were not "reset" properly (which probably should not happen, but it might be that e.g. pytest relies on the fact that the warnings are "reset" whenever a warning test is entered), then it will remain "ignored" on the raises context.

Basically, to use pytest.raises correctly, you probably have to first make sure that this warning is turned into an error. That said, there may well be more weirdness going on.