[llvm-bugs] [Bug 49413] elaborated-enum-base incompatible with NS_ENUM

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Mar 3 11:44:28 PST 2021


https://bugs.llvm.org/show_bug.cgi?id=49413

Richard Smith <richard-llvm at metafoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Richard Smith <richard-llvm at metafoo.co.uk> ---
The macro in question generates ill-formed code in C++; note that GCC and ICC
also reject. As a result, Clang generates an error by default. (The code
generated by the macro is valid in Objective-C and Objective-C++, though.)

Because Clang historically incorrectly accepted this, and in particular because
Apple's NS_ENUM macro currently relies on that compiler bug, we allow the error
for this non-conforming code to be disabled with -Wno-elaborated-enum-base. If
you need to keep building such code and can't fix it to be valid C++, you can
use that flag to allow Clang to accept the code (but it will not be portable to
other compilers).

Hopefully Apple will fix their macro at some point, if they've not done so
already. For example, this can be done with something like:

#ifdef __cplusplus
#define NS_ENUM(name, underlying) \
  void NS_ENUM_##name##_typedef(); \
  enum name : underlying
#else
// old definition
#endif

(where the first line of the macro expansion exists only to effectively swallow
the preceding `typedef` keyword, which is useless in C++).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20210303/9a12ff50/attachment.html>


More information about the llvm-bugs mailing list