GeezerVison

This fails with

/usr/include/c++/15.1.1/ext/atomicity.h:39: syntax error: failed to evaluate #if condition, division/modulo by zero

The code in question:

#if __has_include(<sys/single_threaded.h>)
# include <sys/single_threaded.h>
#endif

It now fails with

/usr/include/c++/v1/__availability:78: syntax error: failed to evaluate #if condition, undefined function-like macro invocation: __has_feature( ... )

or

/usr/include/c++/v1/__assert:29: syntax error: failed to evaluate #if condition, undefined function-like macro invocation: __has_builtin( ... )

hmm.. my problem with this could be that maybe there will be problem in CI and no problem locally ..

Yes, that is a bit of a shortcoming. That might need some adjustment if encountered. But as we are just checking for errors and not the actual output it should be fine.

or no problem in CI today and then we get problems a year from now.

That can happen with anything in any workflow because the runners (and all other parts of the GitHub workflows) are constantly changing.

are the headers in a github runner fixed so they are never changed? or can they be changed at anytime (from one day to the next)?

No, they are not. But as mentioned above that is an issue we are constantly facing with any part of GitHub workflows.

After integrating this with MinGW I have a few cleanups for this.

Yes, that is a bit of a shortcoming. That might need some adjustment if encountered.

This can be improved upon later by getting the built-in include paths from the compiler (if possible).

I think I have that figured out as well.