[PATCH] PR preprocessor/84517 allow double-underscore macros after string literals

[Jonathan Wakely]

On 27 February 2018 at 16:49, Tim Song <t.canens.cpp@gmail.com> wrote:
> On Tue, Feb 27, 2018 at 9:41 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> Since the fix for PR c++/80955 any suffix on a string literal that
>> begins with an underscore is assumed to be a user-defined literal
>> suffix, not a macro. This assumption is invalid for a suffix beginning
>> with two underscores, because such names are reserved and can't be used
>> for UDLs anyway.
>
> [lex.name]/3 reserves all identifiers containing double underscore,
> but the spaceless one-token form does not actually use such an
> identifier.
>
> See the (equally reserved) _Bq example in [over.literal]/8:
>
> double operator""_Bq(long double);                  // OK: does not
> use the reserved identifier _­Bq ([lex.name])
> double operator"" _Bq(long double);                 // uses the
> reserved identifier _­Bq ([lex.name])

I know, but GCC doesn't implement the rule accurately. I reported PR
80955 because GCC's UDL parsing meant we reject valid programs. The
fix for that bug was a bit of a hack, simply adding a special case so
that a suffix starting with an underscore is never expanded as a
macro, which makes the above examples do the right thing. But that
introduces a regression where we no longer accept ""__FILE__ (because
it starts with an underscore), where previously that was accepted as
an extension, just like "%"PRIu64 is accepted (with a warning).

After the hack for 80955 we still do the wrong thing for:

#define foo
int operator""foo();

But that can't appear in a valid program, so we get away with it. But
it's still a hack.

My patch doesn't try to change how we parse operator""_Bq it just
ensures we accept ""__FILE__ and similar cases. I think my patch means
we reject:

int operator""__X(unsigned long long);

But that also can't appear in a valid program, so again we get away with it.