[cfe-dev] Enabling strong enum extensions under C
Jordan Rose via cfe-dev
cfe-dev at lists.llvm.org
Tue Feb 16 16:09:04 PST 2016
> 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 <mailto: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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160216/9c7b05c4/attachment.html>
More information about the cfe-dev
mailing list