wcschr omits wchar_t from the errors

[Alcaro]

#include <wchar.h>

void the_bug()
{
    (void)wcschr(123, 0);
    (void)wcsrchr(123, 0);
    (void)wcsstr(123, 0);
}

C only; the bug does not reproduce in C++, where wchar_t is a keyword. Only specifically wcschr is affected, not even wcsrchr which has identical prototype.

Expected:

<source>:5:18: error: [...] parameter of type 'const wchar_t *' (aka 'const int *') [-Wint-conversion]
<source>:6:19: error: [...] parameter of type 'const wchar_t *' (aka 'const int *') [-Wint-conversion]
<source>:7:18: error: [...] parameter of type 'const wchar_t *' (aka 'const int *') [-Wint-conversion]

Actual:

<source>:5:18: error: [...] parameter of type 'const int *' [-Wint-conversion]
<source>:6:19: error: [...] parameter of type 'const wchar_t *' (aka 'const int *') [-Wint-conversion]
<source>:7:18: error: [...] parameter of type 'const wchar_t *' (aka 'const int *') [-Wint-conversion]

https://godbolt.org/z/sdMhhv3d3

[Alcaro]

While the easiest-to-demonstrate symptom is via the diagnostics subsystem, that's not the root cause; the issue is also observable under clang:as-a-library libclang and C++ API https://godbolt.org/z/x76nncMTj (or was in Clang 14, but it would greatly surprise me if anyone's fixed that specific piece since then without also fixing the diagnostic).

Probably shows up in other places too, for example the C++ API, but I didn't investigate that.

[AaronBallman]

Wow, that's a surprising behavior. -E shows this for the declarations:

# 165 "/usr/include/wchar.h" 3 4
extern wchar_t *wcschr (const wchar_t *__wcs, wchar_t __wc)
     __attribute__ ((__nothrow__ )) __attribute__ ((__pure__));
# 175 "/usr/include/wchar.h" 3 4
extern wchar_t *wcsrchr (const wchar_t *__wcs, wchar_t __wc)
     __attribute__ ((__nothrow__ )) __attribute__ ((__pure__));

so both are const wchar_t * in the header. I think the issue is that we have a builtin defined for wcschr but not the other two:

def WcsChr : LibBuiltin<"wchar.h"> {
  let Spellings = ["wcschr"];
  let Attributes = [NoThrow, Pure, Constexpr];
  let Prototype = "wchar_t*(wchar_t const*, wchar_t)";
  let AddBuiltinPrefixedAlias = 1;
}

The signature is correct there, but this maybe the cause of the confusing diagnostic.

[AaronBallman]

wscmp and others have the same behavior, so this does seem to be related to builtin handling: https://godbolt.org/z/d55b1MEMY

[AaronBallman]

I think the issue is here:

llvm-project/clang/lib/AST/ASTContext.cpp

Line 12445 in 119292c

Type = Context.getWideCharType();

In C, that gets a type compatible with the one defined in stddef.h, not the actual underlying typedef type.

It may be that we want this to provide a typedef type rather than a canonical type, but I'm not certain what the fallout would be from that.