[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