On 27 February 2018 at 16:49, Tim Song <t.canens....@gmail.com> wrote: > On Tue, Feb 27, 2018 at 9:41 AM, Jonathan Wakely <jwakely....@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.
