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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
