This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ Patch] PR 80955 (Macros expanded in definition of user-defined literals)
On Fri, Oct 20, 2017 at 3:52 PM, Mukesh Kapoor <mukesh.kapoor@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