BLD: default to C17 rather than C99

[rgommers]

This update should be a safe bump, because C17 is a pure maintenance update of C11 with no new features; and C11 is mostly a maintenance/bugfix update of C99 with a few new features. Our toolchain roadmap, which was updated just days ago, says that we can use C17 given our minimum compiler versions.

I also note that in numpy#25072, the numpy default was updated from C99 to C11 and that went fine (the one change needed was a Cython bug fix, which went into Cython 3.0.6 - and our minimum version is currently 3.0.8).

Finally, another motivation to do this now is that under the --disable-gil build of CPython 3.13, Cython currently generates code that uses static_assert, which is a C11 feature. Hence our current default of -std=c99 doesn't build with that nogil build. (hat tip to @ngoldbaum for pointing out this problem). EDIT: PEP 7 is also relevant here, since it specifies what C standard version is used by CPython (see https://peps.python.org/pep-0007/#c-dialect). To be safe, be should be using >= the version used by CPython.

For a description of changes in C17, see https://gustedt.wordpress.com/2018/04/17/c17/.

Note: opening as draft until I've checked the CI logs for (the absence of) new warnings.

[rgommers]

Okay, nothing is ever a one line diff it seems .... the Windows failure is real (only with numpy 1.23.5):

[184/1446] Compiling C object scipy/linalg/_flapack.cp310-win_amd64.pyd.p/meson-generated_..__flapackmodule.c.obj
FAILED: scipy/linalg/_flapack.cp310-win_amd64.pyd.p/meson-generated_..__flapackmodule.c.obj 
"cc" "-Iscipy\linalg\_flapack.cp310-win_amd64.pyd.p" "-Iscipy\linalg" "-I..\scipy\linalg" "-IC:\hostedtoolcache\windows\Python\3.10.11\x64\lib\site-packages\numpy\core\include" "-IC:\hostedtoolcache\windows\Python\3.10.11\x64\lib\site-packages\numpy\f2py\src" "-IC:/hostedtoolcache/windows/Python/3.10.11/x64/Lib/site-packages/scipy_openblas32/include" "-IC:\hostedtoolcache\windows\Python\3.10.11\x64\Include" "-fvisibility=hidden" "-fdiagnostics-color=always" "-D_FILE_OFFSET_BITS=64" "-Wall" "-Winvalid-pch" "-std=c17" "-O2" "-g" "-Wno-unused-but-set-variable" "-Wno-unused-function" "-Wno-conversion" "-Wno-misleading-indentation" "-mlong-double-64" "-D__USE_MINGW_ANSI_STDIO=1" "-DMS_WIN64=" "-Wno-empty-body" -MD -MQ scipy/linalg/_flapack.cp310-win_amd64.pyd.p/meson-generated_..__flapackmodule.c.obj -MF "scipy\linalg\_flapack.cp310-win_amd64.pyd.p\meson-generated_..__flapackmodule.c.obj.d" -o scipy/linalg/_flapack.cp310-win_amd64.pyd.p/meson-generated_..__flapackmodule.c.obj "-c" scipy/linalg/_flapackmodule.c
In file included from C:\hostedtoolcache\windows\Python\3.10.11\x64\lib\site-packages\numpy\core\include/numpy/ndarraytypes.h:1948,
                 from C:\hostedtoolcache\windows\Python\3.10.11\x64\lib\site-packages\numpy\core\include/numpy/ndarrayobject.h:12,
                 from C:\hostedtoolcache\windows\Python\3.10.11\x64\lib\site-packages\numpy\core\include/numpy/arrayobject.h:5,
                 from C:\hostedtoolcache\windows\Python\3.10.11\x64\lib\site-packages\numpy\f2py\src/fortranobject.h:13,
                 from scipy/linalg/_flapackmodule.c:23:
C:\hostedtoolcache\windows\Python\3.10.11\x64\lib\site-packages\numpy\core\include/numpy/npy_1_7_deprecated_api.h:14:9: note: '#pragma message: C:\hostedtoolcache\windows\Python\3.10.11\x64\lib\site-packages\numpy\core\include/numpy/npy_1_7_deprecated_api.h(14) : Warning Msg: Using deprecated NumPy API, disable it with #define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION'
   14 | #pragma message(_WARN___LOC__"Using deprecated NumPy API, disable it with " \
      |         ^~~~~~~
scipy/linalg/_flapackmodule.c:101:10: fatal error: threads.h: No such file or directory
  101 | #include <threads.h>
      |          ^~~~~~~~~~~
compilation terminated.

[ev-br]

So f2py C17 support in numpy seems to need some work/testing, it seems

[rgommers]

I tested combinations of numpy and C standard versions. Conclusion:

• for numpy 1.23.5-1.25.2, the threads.h build error on Windows shows up for both C11 and C17, only -std=c99 works
• for numpy 1.26.4, the problem is gone, and both C11 and C17 work fine

numpy 1.26.x was the first minor version to be built with meson, so we probably fixed the threads.h issue as part of the effort to squash all warnings coming from f2py-generated C code.

I have not yet checked if we can work around the problem somehow.

[rgommers]

The root cause is a bug in older versions of npy_os.h (numpy/numpy#24761), which was only fixed in numpy 1.26.1. There's a failure to detect MinGW, and after that a problematic usage of threads.h on Windows was guarded by __STDC_VERSION__ >= 201112L (i.e., C11 and up).

[rgommers]

Okay, this is all happy now.

[lucascolley]

thanks Ralf!

[ngoldbaum]

Over in scikit-learn, we hit an issue building under pyiodide after moving to C17: scikit-learn/scikit-learn#29013. From what I can tell, scipy currently doesn't build under pyodide (#15290) due to missing fortran support, so scipy doesn't have a similar issue. However, if pyodide doesn't grow C17 support before that happens, then scipy specifying C17 in meson.build might be an issue.

Just a heads' up!

[rgommers]

Thanks for the heads up. Looking at getting that fixed in Meson (pyodide/pyodide#4762).

Scipy currently doesn't build under pyodide

SciPy does build in Pyodide in-tree, it's at 1.12.0 right now with an update to 1.13.0 in progress. C17 support will become needed for 1.14.0 - we should have this fix included in a new Meson release by then.

[rgommers]

Fix in progress: mesonbuild/meson#13221