BUG: Include Python.h before system headers.

[DWesl]

Reference issue

Closes #20491

What does this implement/fix?

Python.h needs to be included before any system header: _fmm_core.hpp does, but is not first.

Additional information

The script from #20149 would not catch this. I might need to add pybind11:: to the regex.

[j-bowhay]

cc @alugowski

[tylerjereddy]

Glancing at the includes at the top of fast_matrix_market/types.hpp this seems obviously correct since https://docs.python.org/3/c-api/intro.html#include-files clearly notes:

Since Python may define some pre-processor definitions which affect the standard headers on some systems, you must include Python.h before any standard headers are included.

Since the author of this C++ source actively helps us and has been pinged I'll leave it open for a bit.

[DWesl]

Found a few more trying to get everything built on Cygwin.

[DWesl]

DWesl#5 has a script to check for this and sets up a CI job to do so. I've dropped the most likely false positives, leaving one instance in highspy that has since been removed in the upstream repository. Should I add those changes to this PR, replace this PR with that one (possibly after telling it to ignore highspy), squash-merge that PR onto the branch for this one, or something else?

This includes all changes DWesl#7 needed to get SciPy installed and most tests passing on the 1.13 branch.

[rgommers]

Thanks @DWesl! Could you please rebase?

Cc @steppi @izaid for visibility, since most of the issues were recently introduced in scipy.special. Please keep in mind that Python.h must always be included before any system headers.

[ev-br]

Just bumped into this recently: clang-format reorders the includes, and puts Python.h somewhere in the middle. At least with the .clang-format file from scope/special/special

[izaid]

Just bumped into this recently: clang-format reorders the includes, and puts Python.h somewhere in the middle. At least with the .clang-format file from scope/special/special

Yep, unless there is a line break between Python.h and other includes. Then it doesn't get reordering.

[rgommers]

Something is still unhappy:

[125/1443] Compiling C++ object scipy/special/_special_ufuncs.cp310-win_amd64.pyd.p/_special_ufuncs.cpp.obj
FAILED: scipy/special/_special_ufuncs.cp310-win_amd64.pyd.p/_special_ufuncs.cpp.obj 
"c++" "-Iscipy\special\_special_ufuncs.cp310-win_amd64.pyd.p" "-Iscipy\special" "-I..\scipy\special" "-Iscipy\_lib" "-I..\scipy\_lib" "-I..\scipy\_build_utils\src" "-IC:\hostedtoolcache\windows\Python\3.10.11\x64\lib\site-packages\numpy\core\include" "-IC:\hostedtoolcache\windows\Python\3.10.11\x64\Include" "-fvisibility=hidden" "-fvisibility-inlines-hidden" "-fdiagnostics-color=always" "-D_GLIBCXX_ASSERTIONS=1" "-D_FILE_OFFSET_BITS=64" "-Wall" "-Winvalid-pch" "-std=c++17" "-O2" "-g" "-D__USE_MINGW_ANSI_STDIO=1" "-DMS_WIN64=" "-DNPY_NO_DEPRECATED_API=NPY_1_9_API_VERSION" "-DSP_SPECFUN_ERROR" -MD -MQ scipy/special/_special_ufuncs.cp310-win_amd64.pyd.p/_special_ufuncs.cpp.obj -MF "scipy\special\_special_ufuncs.cp310-win_amd64.pyd.p\_special_ufuncs.cpp.obj.d" -o scipy/special/_special_ufuncs.cp310-win_amd64.pyd.p/_special_ufuncs.cpp.obj "-c" ../scipy/special/_special_ufuncs.cpp
In file included from ../scipy/special/_special_ufuncs.cpp:6:
../scipy/special/ufunc.h:19:13: error: redefinition of 'bool SpecFun_Initialize()'

[DWesl]

Redefinition of function errors tend to mean a header gets executed twice. I removed the second include from the mentioned file and stuck a header guard in in case there's another.

The recent trend seems to be toward #pragma once as a header guard, rather than #ifndef SPECIAL_UFUNC_H/#define SPECIAL_UFUNC_H, correct? Does the style guide prefer one over the other?

[izaid]

Redefinition of function errors tend to mean a header gets executed twice. I removed the second include from the mentioned file and stuck a header guard in in case there's another.

The recent trend seems to be toward #pragma once as a header guard, rather than #ifndef SPECIAL_UFUNC_H/#define SPECIAL_UFUNC_H, correct? Does the style guide prefer one over the other?

Yes, that's correct. I don't know where ufunc.h is getting included twice, but if putting #pragma once at the top fixes it then great.

[DWesl]

I don't know where ufunc.h is getting included twice, but if putting #pragma once at the top fixes it then great.

It was special/_special_ufuncs.cpp, but that's gone now. I could likely adapt the script in DWesl#5 to check for duplicate includes.

[charris]

clang-format reorders the includes

NumPy .clang-format deals with putting the includes in the correct order. It is messy.

[rgommers]

LGTM and CI is all green now - in it goes. Thanks @DWesl & reviewers.