[clang] c90e198 - Fix parsing of enum-base to follow C++11 rules.

[Richard Smith via cfe-commits]

On Wed, 20 May 2020 at 16:30, Akira Hatanaka via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

> Hi Richard,
>
> It looks like this patch will reject the following code, which used to
> compile fine:
>
> $ cat test.cpp
> #include <CoreFoundation/CoreFoundation.h>
>
> typedef CF_ENUM(unsigned, TestEnum) {
>   A = 2,
>   B = 3,
> };
>
> $ clang++ -std=c++11 -c test.cpp
>
> *test.cpp:3:9: **error: **non-defining declaration of enumeration with a
> fixed underlying type is only permitted as a standalone declaration;
> missing list of enumerators? [-Welaborated-enum-base]*
> typedef CF_ENUM(unsigned, TestEnum) {
>
> The macro is defined in CFAvailability.h:
>
> https://opensource.apple.com/source/CF/CF-855.17/CFAvailability.h.auto.html
>
> What’s the best way to fix this?
>

Assuming this macro is always preceded by 'typedef', how about this:

-#define CF_ENUM(_type, _name) enum _name : _type _name; enum _name : _type
+#define CF_ENUM(_type, _name) int _dummy_##_name; enum _name : _type
_name; typedef enum _name _name; enum _name : _type

Or this:

+#ifdef __cplusplus
 #define CF_ENUM(_type, _name) int _dummy_##_name; enum _name : _type
+#else
 #define CF_ENUM(_type, _name) enum _name : _type _name; enum _name : _type
+#endif

(One wonders why the 'typedef' is not part of the macro definition.)

> On May 11, 2020, at 1:37 PM, Richard Smith via cfe-commits <
> cfe-commits at lists.llvm.org> wrote:
>
> On Mon, 11 May 2020 at 06:37, Hans Wennborg via cfe-commits <
> cfe-commits at lists.llvm.org> wrote:
>
>> On Sat, May 9, 2020 at 4:32 AM Richard Smith via cfe-commits
>> <cfe-commits at lists.llvm.org> wrote:
>> >
>> >
>> > Author: Richard Smith
>> > Date: 2020-05-08T19:32:00-07:00
>> > New Revision: c90e198107431f64b73686bdce31c293e3380ac7
>> >
>> > URL:
>> https://github.com/llvm/llvm-project/commit/c90e198107431f64b73686bdce31c293e3380ac7
>> > DIFF:
>> https://github.com/llvm/llvm-project/commit/c90e198107431f64b73686bdce31c293e3380ac7.diff
>> >
>> > LOG: Fix parsing of enum-base to follow C++11 rules.
>> >
>> > Previously we implemented non-standard disambiguation rules to
>> > distinguish an enum-base from a bit-field but otherwise treated a :
>> > after an elaborated-enum-specifier as introducing an enum-base. That
>> > misparses various examples (anywhere an elaborated-type-specifier can
>> > appear followed by a colon, such as within a ternary operator or
>> > _Generic).
>> >
>> > We now implement the C++11 rules, with the old cases accepted as
>> > extensions where that seemed reasonable. These amount to:
>> >  * an enum-base must always be accompanied by an enum definition (except
>> >    in a standalone declaration of the form 'enum E : T;')
>> >  * in a member-declaration, 'enum E :' always introduces an enum-base,
>> >    never a bit-field
>> >  * in a type-specifier (or similar context), 'enum E :' is not
>> >    permitted; the colon means whatever else it would mean in that
>> >    context.
>> >
>> > Fixed underlying types for enums are also permitted in Objective-C and
>> > under MS extensions, plus as a language extension in all other modes.
>> > The behavior in ObjC and MS extensions modes is unchanged (but the
>> > bit-field disambiguation is a bit better); remaining language modes
>> > follow the C++11 rules.
>> >
>> > Fixes PR45726, PR39979, PR19810, PR44941, and most of PR24297, plus C++
>> > core issues 1514 and 1966.
>>
>> Hello from Chromium :-)
>>
>> We saw new errors from some code in a header that looked like this:
>>
>>   // Adapted from NSPathUtilities.h and NSObjCRuntime.h.
>>   typedef enum NSSearchPathDirectory : unsigned long
>> NSSearchPathDirectory;
>>
>> For us we think the enum itself is enough, so we'll fix it by dropping
>> the typedef, but this raised the question of how your change affects
>> the Mac system headers. IIUC your change makes an exception for Obj-C,
>> but the headers can be used from regular C/C++ too. Do you think there
>> might be issues there?
>>
>
> The errors are DefaultError ExtWarns, so they will be suppressed by
> default in system headers. Even then:
>  * In Objective-C (and Objective-C++), the prior rule is unchanged.
>  * In (non-Objective) C++11 onwards, we now enforce the standard rules.
> (System headers should ideally be valid code, but if not, the system header
> exclusion will kick in. And the errors can be disabled by warning flag in
> user code written against old Clang.)
>  * In any other language mode, system headers should really not be using
> this functionality, since it's a non-standard language extension, and not
> supported by (for example) GCC. (With the same provisos as in the prior
> bullet.)
>
> We can make the C++ side of things more permissive if necessary, but I'm
> hopeful that we will be able to enforce the standard rules by default in
> this instance.
>
> (See https://chromium-review.googlesource.com/c/chromium/src/+/2193673
>> for the Chromium discussion.)
>> _______________________________________________
>> cfe-commits mailing list
>> cfe-commits at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20200520/50b99091/attachment.html>