r303694 - Sema: allow imaginary constants via GNU extension if UDL overloads not present.

Richard Smith via cfe-commits cfe-commits at lists.llvm.org
Tue May 23 15:42:04 PDT 2017

On 23 May 2017 at 15:11, Tim Northover via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

> > +      if (!isImaginary) {
> >
> > Shouldn't this be "if (s != ThisTokEnd)"? (That is, if this was not a
> valid builtin suffix, reset the suffix information.)
> I think they're equivalent here:
>     !isImaginary => UDL is _ or time thing => extra crap on the end.
>     extra crap on the end => it's not a legitimate C++14 imaginary =>
> invalid as no _.
> so I went for the same test as when the data is used.

I think they're equivalent by coincidence, but the right test is that we
consumed the entire suffix. (If, say, C++20 adds an "in" suffix for
"inches", we shouldn't start treating that as an imaginary number if no
'operator""in' is declared.)

Maybe it would be clearer to store a separate "valid as non-UDL suffix"
flag instead of resetting these flags to false if the suffix is not valid
as a non-UDL suffix?

But I'm not committed to that, so I'm happy to switch if you're
> unconvinced. I don't think I'll be able to test the change though, even if
> there is a suffix where it matters (I can't think of anywhere those fields
> matter in the UDL but not imaginary case).

Right, I don't think this makes a difference today, because the only
ud-suffixes we let through here are "i", "if", and "il", all of which are
also valid builtin suffixes. But as noted above, this will do the wrong
thing if we permit more ud-suffixes beginning with "i" or "j".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170523/1ed96312/attachment.html>

More information about the cfe-commits mailing list