Bug 22631 – ImportC: support C++11 unscoped enums with underlying type

Clang has an extension for specifying the underlying type of an enum (in the same way as c++ 11). See here: https://clang.llvm.org/docs/LanguageExtensions.html#enumerations-with-a-fixed-underlying-type Despite what the docs say, it works when compiling C code as well. An example of where this is used is in <os/clock.h> and other headers in the os group. After preprocessing, it expands to: typedef enum : uint32_t { OS_CLOCK_MACH_ABSOLUTE_TIME = 32, } os_clockid_t; Use of this feature is guarded by `__has_feature(objc_fixed_enum)`, but if you are using clang as the pre-processor, this will be true and there doesn’t seem to be any argument to clang or a #define that will make it not true.

@WalterBright created dlang/dmd pull request #13561 "fix Issue 22631 - ImportC: support C++11 unscoped enums with underlyi…" fixing this issue: - fix Issue 22631 - ImportC: support C++11 unscoped enums with underlying type https://github.com/dlang/dmd/pull/13561

I have not been able to get clang on my Mac to compile: enum E : char { A }; in a .c file. > clang --version Apple LLVM version 9.0.0 (clang-900.0.39.2) Target: x86_64-apple-darwin16.7.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin > cat test.c enum E : int { A, B }; > clang -c test.c test.c:1:8: error: expected identifier or '(' enum E : int ^ 1 error generated.

(In reply to Walter Bright from comment #3) > I have not been able to get clang on my Mac to compile: > > enum E : char { A }; > > in a .c file. > > > clang --version > Apple LLVM version 9.0.0 (clang-900.0.39.2) > Target: x86_64-apple-darwin16.7.0 > Thread model: posix > InstalledDir: /Library/Developer/CommandLineTools/usr/bin > > > cat test.c > enum E : int > { > A, B > }; > > clang -c test.c > test.c:1:8: error: expected identifier or '(' > enum E : int > ^ > 1 error generated. It compiles with the clang on my ubuntu box: clang version 10.0.0-4ubuntu1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin As well as with the apple-clang on my MacBook: Apple clang version 12.0.0 (clang-1200.0.32.29) Target: x86_64-apple-darwin19.6.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin Some brief probing in clang’s git repo shows it was turned on for all languages clang compiles in 2018 with this commit: https://github.com/llvm/llvm-project/commit/6f11db137034b38dbe2aabfa823ac0f2a7e3f9b9

dlang/dmd pull request #13561 "fix Issue 22631 - ImportC: support C++11 unscoped enums with underlyi…" was merged into master: - 2fa133705ff17b55066488568ba04274759c6a47 by Walter Bright: fix Issue 22631 - ImportC: support C++11 unscoped enums with underlying type https://github.com/dlang/dmd/pull/13561

Some basic types aren’t handled with the above PR: // test.c enum L: long long { // L_A = 1, }; enum U: unsigned long long { // U_A = 1, }; enum U2: unsigned { // U2_A = 1, }; test.c(2): Error: use `long` for a 64 bit integer instead of `long long` test.c(6): Error: basic type expected, not `unsigned` test.c(6): Error: illegal type combination test.c(6): Error: identifier or `(` expected test.c(8): Error: `=`, `;` or `,` expected to end declaration instead of `}` test.c(10): Error: basic type expected, not `unsigned` test.c(10): Error: illegal type combination test.c(10): Error: identifier or `(` expected test.c(12): Error: `=`, `;` or `,` expected to end declaration instead of `}`

(In reply to dave287091 from comment #6) > Some basic types aren’t handled with the above PR: > ... There’s an enum with a base of `unsigned long` in some macOS headers that is rejected.

I’ll close this and file a new bug.