On 10/24/2017 7:05 AM, Jason Merrill wrote:
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.
Thanks for pointing this out. Checking in the front end will be
difficult because the front end gets tokens after macro expansion. I
think the difficulty of fixing this bug comes because of the requirement
to maintain backward compatibility with the option -Wliteral-suffix for
-std=c++11.
Mukesh
Jason
