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@lists.llvm.org> wrote:
>
> On Mon, 11 May 2020 at 06:37, Hans Wennborg via cfe-commits
> <cfe-commits@lists.llvm.org <mailto:cfe-commits@lists.llvm.org>> wrote:
> On Sat, May 9, 2020 at 4:32 AM Richard Smith via cfe-commits
> <cfe-commits@lists.llvm.org <mailto:cfe-commits@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@lists.llvm.org <mailto:cfe-commits@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@lists.llvm.org <mailto:cfe-commits@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@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
