So I think there are two questions to decide here:

• Do we want a -std= flag, does Clang even accept that?
• Should we just take the ObjC flags from the C flags, and ObjC++ flags from the C++ flags, or should they be set independently?

• Do we want a -std= flag, does Clang even accept that?

Yes, clang accepts it, as long as you don't ask for an impossible combination (C or ObjC with std=c++11 for instance).

I tried not adding the flag explicitly, but then it is added by languageStandard().

• Should we just take the ObjC flags from the C flags, and ObjC++ flags from the C++ flags, or should they be set independently?

I guess I haven't yet taken a clear decision on that? That had to do with trying not to add a standards definition which seemed like a good idea because I haven't found a clear statement about the C standard that ObjC 2.0 is based on. But that question is probably moot because from what I understand the ObjC standard just describes the superset. I came across a post stating that using Objective-C code in a C11 (C++11) file gives you ObjC11 (ObjC++11).

I think this could be Q_UNREACHABLE().

What happens if you do get there? I'd hate to introduce something that causes an abort on a user's system because an unforeseen situation that slipped through "QC".

__builtin_unreachable() does have strange effects:

#include <stdio.h>

int foo(int doit)
{
     switch(doit) {
          case 0:
          case 1:
          case 2:
               return doit;
          default:
               __builtin_unreachable();
     }
}

int main(int argc, char *argv[])
{
     fprintf(stderr, "foo(0)=%d\n", foo(0));
     foo(1);
     foo(2);
     fprintf(stderr, "unreachable foo(4)=");
     fprintf(stderr, "%d\n", foo(4));
     return 0;
}

Depending on how and with what compiler I build this, the program either loops (from the foo(4) call back to the start of main) until it SEGVs, or it terminates after printing foo(4)=4

IOW, it looks like it just causes UB in release builds when the assert is removed from Q_UNREACHABLE :-/

Given that languageOption also has Q_UNREACHABLE(), and both are always called together, any crash that could happen would have already happened before. The function is called from CompilerProvider::{defines,includes} and both catch the Other case before calling into the ICompiler implementation. Maybe we should document the constraint (type != Utils::Other) in the ICompiler interface, but we should do it in a separate commit.