[cfe-dev] Enabling strong enum extensions under C

[Richard Smith via cfe-dev]

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?

> We haven't thought about adding a
> -std=clang<X> flag before.
>
> This isn't a Swift feature; it's an Objective-C feature that Swift makes use
> of.
>
> Jordan
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>