[PATCH] D153156: [Clang] CWG1473: do not err on the lack of space after operator""
Aaron Ballman via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Fri Aug 18 08:10:59 PDT 2023
aaron.ballman added a comment.
In D153156#4598988 <https://reviews.llvm.org/D153156#4598988>, @rZhBoYao wrote:
> In D153156#4598915 <https://reviews.llvm.org/D153156#4598915>, @steelannelida wrote:
>
>> Unfortunately the option -Wno-reserved-user-defined-literal fails after this:
>>
>> #define MYTHING "_something_"
>>
>> const char* f() {
>> return "ONE"MYTHING"TWO";
>> }
>>
>> $ clang -Wno-reserved-user-defined-literal repro.cxx
>> repro.cxx:4:15: error: no matching literal operator for call to 'operator""MYTHING' with arguments of types 'const char *' and 'unsigned long', and no matching literal operator template
>> 4 | return "ONE"MYTHING"TWO";
>> | ^
>> 1 error generated.
>
> This is conforming right? Correct me if I'm wrong. My reading of https://eel.is/c++draft/lex.pptoken#3.3 is that "ONE"MYTHING"TWO" is a single preprocessing-token during phase 3 (https://eel.is/c++draft/lex.phases#1.3). Can @aaron.ballman confirm this?
The diagnostic behavior is correct. `MYTHING` doesn't get expanded until phase 4 (http://eel.is/c++draft/lex.phases#1.4), so this appears as `"ONE"MYTHING` as a single preprocessor token: https://eel.is/c++draft/lex.ext#nt:user-defined-string-literal and that token is an invalid UDL.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D153156/new/
https://reviews.llvm.org/D153156
More information about the cfe-commits
mailing list