Fwd: [PATCH][RFC] c++: Accept elaborated-enum-base in system headers

[Iain Sandoe <iain@sandoe.co.uk>]

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]



> Begin forwarded message:
> 
> From: Jason Merrill <jason@redhat.com>
> Subject: Re: [PATCH][RFC] c++: Accept elaborated-enum-base in system headers
> Date: 8 June 2023 at 19:06:36 BST
> To: Alex Coplan <alex.coplan@arm.com>, gcc-patches@gcc.gnu.org
> Cc: Nathan Sidwell <nathan@acm.org>, Iain Sandoe <iain@sandoe.co.uk>
> 
> On 6/8/23 07:06, Alex Coplan wrote:
>> Hi,
>> macOS SDK headers using the CF_ENUM macro can expand to invalid C++ code
>> of the form:
>> typedef enum T : BaseType T;
>> i.e. an elaborated-type-specifier with an additional enum-base.
>> Upstream LLVM can be made to accept the above construct with
>> -Wno-error=elaborated-enum-base.
> 
> I guess we might as well follow that example, and so instead of this check:
> 
>> +	   || (underlying_type && !in_system_header_at (colon_loc)))
> 
> Make the below an on-by-default pedwarn using OPT_Welaborated_enum_base, and don't return error_mark_node.

I was also wondering about (for this and other reasons) a -fclang-compat to put some of these things behind (since std=clang++NN is not really going to work to describe other non-standard extensions etc. since most are not synchronised to std revisions.)

Iain

> 
>> +	      cp_parser_commit_to_tentative_parse (parser);
>> +	      error_at (colon_loc,
>> +			"declaration of enumeration with "
>> +			"fixed underlying type and no enumerator list is "
>> +			"only permitted as a standalone declaration");
> 
>