[cfe-dev] Enabling strong enum extensions under C

Sean Silva via cfe-dev cfe-dev at lists.llvm.org
Tue Feb 16 16:16:30 PST 2016


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.
>

Actually here's one where even -Wpedantic won't coax a warning out of clang:

Sean:~/tmp % cat testpedantic.c
__attribute__((enable_if(1, "foo")))
void bar() {
}

Sean:~/tmp % clang -c testpedantic.c -std=c11 -Wpedantic -pedantic
Sean:~/tmp % clang -c testpedantic.c -std=c11 -Wpedantic
Sean:~/tmp % clang -c testpedantic.c -std=c99 -Wpedantic
Sean:~/tmp %

-- Sean Silva


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.
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160216/2e0a4dba/attachment.html>


More information about the cfe-dev mailing list