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

[Akira Hatanaka via cfe-commits]

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?

> 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 <mailto: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 <mailto: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 <https://github.com/llvm/llvm-project/commit/c90e198107431f64b73686bdce31c293e3380ac7>
> > DIFF: 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 <https://chromium-review.googlesource.com/c/chromium/src/+/2193673>
> for the Chromium discussion.)
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org <mailto:cfe-commits at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org <mailto:cfe-commits at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits <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/0f201dc0/attachment.html>