Incorrect warning about wchar_t in C

[AaronBallman]

Should this warn about wchar_t in C?

#include <wchar.h>

int main (void)
{
  wchar_t foo;
  (void)foo;
  return 0;
}

% xcrun /Users/builder/llvm/llvm-install/bin/clang -fsyntax-only -Weverything ~/Desktop/test.c

/Users/builder/Desktop/test.c:5:3: warning: identifier 'wchar_t' conflicts with a C++ keyword [-Wc++-keyword]
    5 |   wchar_t foo;
      |   ^

Originally posted by @seanm in #137234 (comment)

[Fznamznon]

The same goes with other typedefed types i.e. char16_t, char32_t etc https://godbolt.org/z/MEa1G353M
I don't see a way to detect that was a typedef coming from the standard headers at the point where we issue the warning, should we perhaps not warn on these?

[AaronBallman]

This does seem to require some pretty significant reworking to support correctly. We only have the IdentifierInfo but we need more context. The only idea I had (which may be a terrible one) would be to provide some sort of optional callback to the API so we can say "this might be reserved, but let's let the callback tell us if we're wrong".

But yeah, if we can't find a way to silence the diagnostic, it might make sense to turn it off for these identifiers, which would be unfortunate because we'd lose the diagnostic in a case like:

// C file, no headers included.
void wchar_t(void) {}

but not the end of the world given how easy it is to get transitive includes which would result in: https://godbolt.org/z/axq4K4ThK or similar.

[efriedma-quic]

What can you actually do in C with an identifier that isn't a keyword, and isn't already defined somewhere else? It's pretty limited: you can define a macro, a typedef, a struct, a variable, an enum constant, or a label. We could just diagnose those usages explicitly, instead of eagerly diagnosing things before the parser sees them.