On 27 February 2018 at 16:59, Jonathan Wakely <jwakely....@gmail.com> wrote: > 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.
Sorry for being inaccurate, what I mean is the problem case where a macro clashes with a UDL can't appear (because defining the macro would be invalid): #define __X int operator""__X(unsigned long long); However, that doesn't help for this case: int operator""__FILE__(unsigned long long); This is allowed as a UDL, and doesn't use a reserved identifier (because it doesn't define __FILE__, the implementation does), but would fail after my patch because __FILE__ gets incorrectly expanded as a macro. I don't have much sympathy for anybody defining such a UDL.
