[PATCH] D33424: Lexer: allow imaginary constants in GNU mode (only).

[Richard Smith via cfe-commits]

On 26 May 2017 at 10:34, Tim Northover via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

> On 24 May 2017 at 17:54, Richard Smith <richard at metafoo.co.uk> wrote:
> > Yikes :-( Maybe libc++ *should* have that extension then. It sounds like
> > we'll silently get the wrong value for any attempt at std::complex /
> > _Complex interop right now:
>
> That sounds like a pretty good idea whatever we decide to do about the
> literals.
>
> But we do need to sort out what we're going to do here. I quite like
> the approach you suggested, and think it's an improvement worth
> putting in for gnu++ modes regardless.
>
> So the remaining question is what we should do for the
> standards-compliant C++ modes. We seem to have 3 plausible options:
>
> 1. Bar it everywhere. It's an extension.
> 2. Bar it for C++14 onwards, where the standard provides literals.
> 3. Allow it everywhere.
>
> Although 2 would be the most conservative option (it maintains all
> existing behaviour), it's my least favourite for the added complexity
> and quirkiness.
>
> My original inclination is to go with Marshall and pick 1, but it's a
> very weak preference and I know I tend to be a bit user-hostile in
> these situations.
>
> So, how do we resolve this. Does anyone else have opinions?


Generally I'd also side towards 1, but in this instance that would mean
we're removing a conforming extension that prior versions of clang
supported in C++98 and C++11 modes, with no way to get the extension back
other than turning on the full set of (non-conforming) GNU extensions.

I quite like the approach we take to MS extensions: we have two separate
flags for the conforming and non-conforming extensions. For GNU extensions,
we generally do the same, where the conforming extensions are enabled by
default (with no way to turn them off other than -pedantic-errors or
-Werror=gnu!) and the non-conforming extension controlled by -std=gnu* vs
-std=c* ("GNU mode"). (In the longer term, I'd like to replicate the MS
pattern for the GNU extensions, with -fgnu-extensions controlling the
conforming extensions and -fgnu-compatibility controlling the
non-conforming extensions.)

If we generally think that distinction is a good thing, then (because this
is a conforming extension) consistency weakly suggests that it should not
be controlled by GNU mode. But I don't find that argument decisive; the
important thing is that we don't enable non-conforming extensions by
default in non-GNU (and non-MS-compat) modes, not that GNU mode consists of
/only/ non-conforming extensions.

Given that we probably want to retain a way to enable this outside GNU
mode, if we go for 1, then we would want a separate flag to enable it, and
then the difference between 1 and 3 is whether it's a -f flag or a -W flag.
The latter is our normal choice for such conforming extensions.


Looking at the

  std::complex<float> x = 1.0if;

case again, I think there's another problem here: we support an implicit
conversion from _Complex float to float in C++ (without even a warning).
This conversion is valid in C, but at least GCC disallows it in its C++
mode. We should probably at least warn on that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170526/bb86916c/attachment-0001.html>