2011-10-14 06:29:44 +08:00
// RUN: %clang_cc1 -fsyntax-only -pedantic -std=c++11 -verify -triple x86_64-apple-darwin %s
2010-12-02 01:42:47 +08:00
enum E { } ;
2011-12-22 10:22:31 +08:00
struct Z { } ;
2010-12-02 01:42:47 +08:00
typedef int Integer ;
struct X {
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.
2020-05-09 10:24:18 +08:00
enum E : 1 ; // expected-error{{anonymous bit-field}}
2010-12-02 01:42:47 +08:00
enum E : Z ; // expected-error{{invalid underlying type}}
enum E2 : int ;
enum E3 : Integer ;
} ;
struct Y {
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.
2020-05-09 10:24:18 +08:00
enum E : int ( 2 ) ; // expected-error{{anonymous bit-field}}
enum E : Z ( ) ; // expected-error{{anonymous bit-field}} expected-error{{integral constant expression must have integral or unscoped enumeration type, not 'Z'}}
2010-12-02 01:42:47 +08:00
} ;
2014-07-16 13:16:52 +08:00
namespace pr18587 {
struct A {
enum class B {
C
} ;
} ;
const int C = 4 ;
struct D {
A : : B : C ;
} ;
}
2015-03-28 08:31:40 +08:00
enum WithUnderlying : unsigned { wu_value } ;
struct WithUnderlyingBitfield {
WithUnderlying wu : 3 ;
} wu = { wu_value } ;
int want_unsigned ( unsigned ) ;
int want_unsigned ( int ) = delete ;
int check_enum_bitfield_promotes_correctly = want_unsigned ( wu . wu ) ;