[cfe-dev] Enabling strong enum extensions under C

[Saleem Abdulrasool via cfe-dev]

On Tue, Feb 16, 2016 at 4:09 PM, Jordan Rose via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

>
> On Feb 16, 2016, at 15:40, Richard Smith <richard at metafoo.co.uk> wrote:
>
> On Tue, Feb 16, 2016 at 3:34 PM, Jordan Rose via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
>
>
> On Feb 16, 2016, at 13:49, Douglas Gregor <dgregor at apple.com> wrote:
>
>
> On Feb 16, 2016, at 12:56 PM, Nico Weber <thakis at chromium.org> wrote:
>
> Is this the only C extension you need for swift?
>
>
> I believe that it’s the only non-attribute extension not covered by an
> existing flag.
>
> What about -fblocks?
>
>
> This already has a flag, which Swift’s Clang importer can set if it’s
> important. I haven’t heard a ton of demand for blocks outside of Darwin
> clients.
>
> If it's just typed enums and you don't think it'll become more over time,
> it
> probably doesn't matter much all either way. If you think you'll need more
> features over time, having some global toggle for this seems nice. It could
> default to on for -std=gnuX (if you use this, you don't mind extensions)
> and
> to off for -std=cX (if you use this, you probably want to use the language
> as standardized), or something like that.
>
>
> Swift’s Clang importer can certainly use -std=gnu<whatever>, and keep fixed
> underlying types out of -std=c<X>.
>
>
> I do want to mention that Clang has plenty of other Clang-only extensions
> that we added to -std=gnu<whatever>.
>
>
> That sounds like a bug. The difference between -std=cX and -std=gnuX
> should be exactly the same as enabling a (hypothetical)
> -fgnu-extensions (or perhaps -fgnu-compatibility) flag -- that is, it
> should only enable GNU extensions. Do you have an example?
>
>
> I take it back; it seems we merely have Clang extensions that we added
> without *any* flags, other than -Wpedantic. The closest thing is that we
> accept any constant-foldable integer as an array size in GNU mode, and our
> constant folding logic probably doesn't exactly match GCC's.
>

I think that those should really be considered bugs.

Honestly, given that the addition of `-fgnu-extensions` has been discussed
multiple times, I think that it is reasonable to try to provide a mechanism
for helping users write portable code (yes, clang is a great compiler and
hopefully fits everyone's needs, but that doesn't mean that people won't
use any other compilers).  Rather than silently introducing non-standard
behavior we could provide a means to identify those and allow users to
determine if they wish to use that.

That is not to say we could not enable the extensions by default, but
merely that we should have a way to disable the extensions and at the very
least indicate that they are being used.  Doing so may help push certain
features into the standard as Doug was suggesting.


> Although this seems wrong:
>
>   if (!LangOpts.GNUMode && !LangOpts.MSVCCompat)
>     Builder.defineMacro("__STRICT_ANSI__");
>
>
> Given that, I'm not sure why this would be different from any other Clang
> extension <http://clang.llvm.org/docs/LanguageExtensions.html> that was
> added without a flag.
>
> Jordan
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>


-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160217/a6a8a8a0/attachment.html>