Support lists for ObjC and ObjC++ standards #13642
Conversation
|
I have tested this with Clang and with GCC, but only far enough with GCC to get to the point it fails because my GCC build doesn't have ObjC[++] support. |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
dcbaker
force-pushed
the
submit/fix-objc-standards
branch
from
cce0240
to
f8d86c3
Compare
|
Should there be a test for that, to ensure every compiler supports the same syntax for |
dcbaker
force-pushed
the
submit/fix-objc-standards
branch
from
f8d86c3
to
5a1175a
Compare
|
It was worth writing the tests, I found some issues that weren't being caught by our existing tests. |
We'll want to use this for ObjC as well, so we'll make it public and put it in a public place.
This means that the two compilers will update together, and that ObjC has the list behavior that C does.
…mpiler We'll want to use this for the ObjC++ compiler too.
So we can re-use it for the ObjC code
So we can re-use it in the ObjC++ standards
dcbaker
force-pushed
the
submit/fix-objc-standards
branch
from
5a1175a
to
76b2563
Compare
|
Also in the latest version, use mixins for the Apple version overrides |
To avoid duplication between C and ObjC
Check clang-cl as well as cl, and clang as well as gcc.
This tests ObjC and ObjC++ both with and without C enabled. I did this because I ran into issues where ObjC only worked when C was enabled, and then a later bug where C was disabled, due to the fact that C and ObjC both use `c_std` and not `objc_std`.
dcbaker
force-pushed
the
submit/fix-objc-standards
branch
from
76b2563
to
d4bcdc8
Compare
|
xref #13713: it'd be good to produce a future-feature warning if ObjC is used with a list of standards. Otherwise projects might be surprised e.g. if they use Objective C on macOS, don't CI on macOS with older Meson, and switch to |
dcbaker
force-pushed
the
submit/fix-objc-standards
branch
from
5aa46e7
to
b05ecce
Compare
Since this is optional, we should not accept that GCC is a valid ObjC or G++ is a valid ObjC++ Compiler unless we've tested that they can actually do a basic compile. This requires fixing a number of tests that have broken assumptions. In some cases I've split tests where issues with one language would hide the other. It would be great if we had a competent test framework that allowed subtests to skip, unfortunately we have python's unittest instead. Because of that we can't avoid extra tests by use of subtests.
dcbaker
force-pushed
the
submit/fix-objc-standards
branch
from
b05ecce
to
acb45fe
Compare
|
@bgilbert given that this series is already up to 13 patches and is fixing tons of issues with ObjC, I'd prefer to handle that separately, but I assigned that to myself and I'll have a look it at. |
dcbaker
force-pushed
the
submit/fix-objc-standards
branch
from
8b40662
to
e4810f9
Compare
dcbaker
force-pushed
the
submit/fix-objc-standards
branch
from
e4810f9
to
bed8bee
Compare
Also, share the implementations between the C and ObjC, and C++ and OjbC++ instance of both Clang and GNU compilers, so that we update once, and only once for each compiler.
Mostly this just ends up moving code around.
Fixes: #13639