jyknight reopened this revision. jyknight added a comment. This revision is now accepted and ready to land.
Reopening the review since it ended up reverted, but I do think we DO want to have at least some of the changes proposed here (and/or from the pending D158372 <https://reviews.llvm.org/D158372>). At the very least, the existing diagnostics are currently quite misleading/wrong, and the work here was helping to improve that. Taking this example: float operator ""XXX(const char *); It results in three diagnostics: <source>:1:18: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal] 1 | float operator ""XXX(const char *); | ^ | <source>:1:18: warning: identifier 'XXX' preceded by whitespace in a literal operator declaration is deprecated [-Wdeprecated-literal-operator] 1 | float operator ""XXX(const char *); | ~~~~~~~~~~~^~~ | operator""XXX <source>:1:7: warning: user-defined literal suffixes not starting with '_' are reserved; no literal will invoke this operator [-Wuser-defined-literals] 1 | float operator ""XXX(const char *); | ^ The first and third are enabled by default, the second is not. The first only describes what to do if you wanted it to be string-concat (which would be invalid here...), not if you wanted it to be an UDL-operator definition. And it's not clear that "identifier" really means "macro expanding to a string that I assume you meant" in the message. I think we should not emit that message ONLY if there is a macro named "XXX". The second is just incorrect -- there's already no space in the user’s source-code, the compiler just added one internally! The third seems OK, although if we actually do permit calling such UDLs, would want to remove the last phrase... Then, consider: float operator ""XXX(const char *); float x1 = ""XXX; One might reasonably expect to build when -Wno-reserved-user-defined-literal is specified. But, currently, it does not. I think a reasonable compromise behavior would be: 1. If the literal suffix is nonstandard (that is: doesn't start with `_`, and isn't a standard-defined UDL suffix), then try macro-expanding the suffix. 2. If there is an expansion, use the macro-expansion, instead of treating it as UDL, and diagnose as an error-by-default under -Wreserved-user-defined-literal. 3. On the other hand, if there is no macro-expansion, then let it be parsed as a nonstandard UDL, and emit a different diagnostic message under error-by-default -Wreserved-user-defined-literal. 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
