[clang] Support __typeof_unqual__ in all C modes

[nathanchance]

GCC has added __typeof_unqual__ to allow typeof_unqual to be used in all C modes (not just C23 and newer), similar to __typeof__ and typeof.

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=607d9d50ee44163cee621cd991600acaf78c2fee

The Linux kernel would like to start using __typeof_unqual__ to strip type qualifiers such as address spaces from inputs to macros but cannot switch to C23 due to compiler version requirements.

Match GCC and allow __typeof_unqual__ in all C modes.

Closes: #76423
Link: https://lore.kernel.org/CAFULd4YG21NdF_qNVBGDtXO6xnaYFeRPvKicB=gpgUUqYE=4jw@mail.gmail.com/

PR notes/commentary:

• I am not sure if there are any other tests I should add, I could not tell where __typeof__ was being used normally versus being explicitly tested aside from this test.
• If there are any comments in the source code that should be updated, I am more than happy to do so, I just didn't want to be preemptive if they were not going to matter.

[nickdesaulniers]

Thanks for the patch!

[AaronBallman]

Thank you for this; I think it's a very reasonable extension!

[AaronBallman]

LGTM, please add a C++-specific test when landing, since this is also going into C++.

[nathanchance]

LGTM, please add a C++-specific test when landing, since this is also going into C++.

Does 4f9e79b seem reasonable on that front? Should I add a test that typeof_unqual is not accepted for C++? As far as I understand it, that is not supported by any compiler or the standard, correct?

[AaronBallman]

LGTM, please add a C++-specific test when landing, since this is also going into C++.

Does 4f9e79b seem reasonable on that front?

Yup, thank you!

Should I add a test that typeof_unqual is not accepted for C++? As far as I understand it, that is not supported by any compiler or the standard, correct?

I don't think there's a need for that (your patch doesn't change the status quo for typeof_unqual). That said, I will rarely complain about additional test coverage. ;-)

[nathanchance]

Should I add a test that typeof_unqual is not accepted for C++? As far as I understand it, that is not supported by any compiler or the standard, correct?

I don't think there's a need for that (your patch doesn't change the status quo for typeof_unqual). That said, I will rarely complain about additional test coverage. ;-)

Since it is a new test, I will add that coverage just to make it a little more obvious that is expected: c89b969

I'll merge this once presubmit is finished and no obvious regressions are noticed, thank you both for the quick feedback!

[nathanchance]

Would it make sense to apply this to release/18.x to get it into the hands of users quicker? It seems like it should be a safe change to apply. It sounds like GCC 14 will be the first one to support __typeof_unqual__, which should be released quite soon if I understand their release cycle correctly, so it makes sense that Clang would support it around the same time. No worries if it does not seem reasonable, just figured it was worth asking.

[AaronBallman]

I agree that the feature is safe, but I don't think it qualifies because it's adding a new feature rather than fixing an issue. That said, if @tru or @tstellar think it's worth adding as release managers, I won't block it (because it really should be quite safe).

[tru]

The final decision is Toms, but I don't think it qualifies since we are so late in the current process and that 19 will start in just a few months.