On Fri, Oct 20, 2017 at 3:52 PM, Mukesh Kapoor <mukesh.kap...@oracle.com> wrote: > On 10/20/2017 11:00 AM, Mukesh Kapoor wrote: >> On 10/20/2017 10:45 AM, Nathan Sidwell wrote: >>> On 10/20/2017 12:37 PM, Mukesh Kapoor wrote: >>>> >>>> This patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80955. >>>> Handle user-defined literals correctly in lex_string(). An empty string >>>> followed by an identifier is >>>> a valid user-defined literal. Don't issue a warning for this case. >>> >>> a) why do we trigger on the definition of the operator function, and not >>> on the use site? >> >> Actually, the current compiler issues an error (incorrectly) at both >> places: at the definition as well as at its use. >> >>> b) Why is the empty string special cased? Doesn't the same logic apply >>> to: >>> >>> int operator "bob"_zero (const char *, size_t) { return 0;} >> >> This is not a valid user-defined literal and is already reported as an >> error by the compiler. After my changes it's still reported as an error. >> The empty string immediately followed by an identifier is a special case >> because it's a valid user-defined literal in C++. ""_zero is a valid >> user-defined literal. > > Sorry, I used incorrect terminology here. An empty string immediately > followed by an identifier is a valid name for a literal operator; ""_zero is > a valid name for a literal operator.
Yes, and indeed "bob"_zero isn't. But it would be fine for the testcase to return "bob"_zero, a valid user-defined string literal which calls operator ""_zero, and that will still break after your patch. It seems like we need to handle this error recovery in the front end, where we can look to see if there's a matching operator, rather than in libcpp. Jason
