> On May 20, 2020, at 5:53 PM, Richard Smith <rich...@metafoo.co.uk> wrote: > > On Wed, 20 May 2020 at 16:30, Akira Hatanaka via cfe-commits > <cfe-commits@lists.llvm.org <mailto:cfe-commits@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 > <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.)
Thanks! Is there a way to avoid the dummy typedef so that it doesn’t show up in completions and stuff or some way in C++ to undef the typedef? > >> On May 11, 2020, at 1:37 PM, Richard Smith via cfe-commits >> <cfe-commits@lists.llvm.org <mailto: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 <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
