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

[James Y Knight via Phabricator via cfe-commits]

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