Fix handling of C standard support for Emscripten

[rgommers]

Emscripten version numbers are unrelated to Clang version numbers, so it is necessary to change the version checks for c_std=c17 & co. Without that, no project that defaults to C17 or newer will build with Emscripten.

See pyodide/pyodide#4762 for more context. Also note that this bug caused defaulting to C17 in scikit-learn to be reverted (scikit-learn#29015), and it may be a problem for SciPy 1.14.0 too since that release will upgrade from C99 to C17.

Cc @lesteve.

[eli-schwartz]

Neither CI failure seems relevant. Pylint updated and seems to be reporting a bunch of false positives, rust fails to link on Windows due to I can only assume a rustc update.

[rgommers]

Neither CI failure seems relevant.

Do I need to rebase once those are resolved on master, or is this good as is?

[eli-schwartz]

Changes seem correct. The CI failures can be easily checked as not related.

[rgommers]

Thanks for the reviews. Could this possibly be included in 1.4.1? I'm not sure how the backport process works, so I thought I'd ask here.

[eli-schwartz]

It's obviously a bug fix rather than a feature, so it should be eligible, yes.

The other concern really is just that if you create a build directory with the old meson, then backport the change and reuse the existing build directory, it should never crash due to breaking the pickle-based binary layout of the private coredata (for 1.5.0, we specifically error out and say to regenerate the build directory but bugfixes are drop-in compatible).

[rgommers]

Makes sense. Since building with std=c17 didn't work at all with Emscripten and the behavior for older C standards is unchanged, I'd expect no change to the private coredata that is relevant.

If it's eligible, should I open a PR for the backport, or is that all done in one go?

[eli-schwartz]

Changes to the private coredata would be e.g. if pickled code tried to evaluate nonexistent code, e.g. when building with older stds or loading unittests / installdata.

I don't think that should be a problem here, although double checking could still be good.

Either way if it's good to go, set the milestone and it will be backported automatically as part of the release process. Manual backports are only necessary if there are merge conflicts when cherry picking.

[tristan957]

Added to milestone. Thanks!