[PATCH] D153156: [Clang] CWG1473: do not err on the lack of space after operator""

[Jordan Rupprecht via Phabricator via cfe-commits]

rupprecht added a comment.

In D153156#4599106 <https://reviews.llvm.org/D153156#4599106>, @aaron.ballman wrote:

> 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.

IIUC, the question is not whether the diagnostic is correct, but rather why `-Wno-reserved-user-defined-literal` does not workaround the breakage. Is that right?

An example of this in the wild is older versions of swig: https://github.com/swig/swig/blob/939dd5e1c8c17e5f8b38747bf18e9041ab5f377e/Source/Modules/php.cxx#L1724


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D153156/new/

https://reviews.llvm.org/D153156