the following code produces an error: #define TESTL(x) L#x const wchar_t* a = L"Hello World"; const wchar_t* b = TESTL(Hello World); The preprocessor appears to ignore the L inside the define as the literal declaring the string as a wide string. The code not using the macro passes without error. Here is the analyzer output: "Use of undeclared identifier 'L'" This fails on both using the analyzer that ships with XCode 4.0.1 as well as svn trunk (test at revision 131851).
Clang is behaving correctly here (as does GCC). You can't both stringize a token and concatenate in one step. Instead, use: #define TESTL2(x) L##x #define TESTL(x) TESTL2(#x) const wchar_t* a = L"Hello World"; const wchar_t* b = TESTL(Hello World);
(In reply to comment #1) > Clang is behaving correctly here (as does GCC). You can't both stringize a > token and concatenate in one step. Instead, use: > > #define TESTL2(x) L##x > #define TESTL(x) TESTL2(#x) > const wchar_t* a = L"Hello World"; > const wchar_t* b = TESTL(Hello World); It also works with: #define TESTL(x) L###x const wchar_t* a = L"Hello World"; const wchar_t* b = TESTL(Hello World); I wasn't sure of the desired behaviour of "L#x" in clang (or that GCC doesn't allow for it either), I ran into it while trying to analyze some Microsoft example code while working on a Visual Studio plugin for the clang analyzer. Is this something that should be added to the clang Microsoft extensions?
IMO we should consider lexing this as a single wide string literal in -fms-compatibility mode. There appear to be lots of Windows applications using this idiom to form wide string literals from macro arguments.
Fixed in revision 224228