[PATCH v2] c++: P2865R5, Remove Deprecated Array Comparisons from C++26 [PR117788]

Jason Merrill jason@redhat.com
Thu Dec 5 18:15:49 GMT 2024


On 12/4/24 12:27 PM, Marek Polacek wrote:
> On Tue, Dec 03, 2024 at 04:27:22PM -0500, Jason Merrill wrote:
>> On 12/3/24 2:46 PM, Marek Polacek wrote:
>>> On Thu, Nov 28, 2024 at 12:04:56PM -0500, Jason Merrill wrote:
>>>> On 11/27/24 9:06 PM, Marek Polacek wrote:
>>>>> Not a bugfix, but this should only affect C++26.
>>>>>
>>>>> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>>>>>
>>>>> -- >8--
>>>>> This patch implements P2865R5 by promoting the warning to error in C++26
>>>>> only.  -Wno-array-compare shouldn't disable the error, so adjust the call
>>>>> sites as well.
>>>>
>>>> I think it's fine for -Wno-array-compare to suppress the error (and
>>>> -Wno-error=array-compare to reduce it to a warning), so how about
>>>> DK_PERMERROR rather than DK_ERROR?
>>>
>>> Sounds good.
>>>> We also need SFINAE for this when !tf_warning_or_error.
>>>
>>> I've added Warray-compare-1.C, which has:
>>>
>>>     template<int I>
>>>     void f (int(*)[arr1 == arr2 ? I : I]);
>>>
>>> but when we call cp_build_binary_op from the parser, complain is
>>> tf_warning_or_error, so we warn (as does clang++).  I suspect
>>> that goes against [temp.deduct.general]/8.
>>
>> No, that's fine; in C++26 that template is IFNDR because no well-formed
>> instantiation exists, it's OK for us to give a diagnostic and then continue
>> just like in a non-template.
> 
> Ah yes.
> 
>> I'm not sure there is a SFINAE situation where this would come up, but I'd
>> still like to adjust this:
>>
>>> @@ -6125,11 +6124,10 @@ cp_build_binary_op (const op_location_t &location,
>>>    			"comparison with string literal results "
>>>    			"in unspecified behavior");
>>>    	}
>>> -      else if (warn_array_compare
>>> -	       && TREE_CODE (TREE_TYPE (orig_op0)) == ARRAY_TYPE
>>> +      else if (TREE_CODE (TREE_TYPE (orig_op0)) == ARRAY_TYPE
>>>    	       && TREE_CODE (TREE_TYPE (orig_op1)) == ARRAY_TYPE
>>>    	       && code != SPACESHIP_EXPR
>>> -	       && (complain & tf_warning))
>>> +	       && (complain & tf_warning_or_error))
>>>    	do_warn_array_compare (location, code,
>>>    			       tree_strip_any_location_wrapper (orig_op0),
>>>    			       tree_strip_any_location_wrapper (orig_op1));
>>
>> If we happen to get here when not complaining, we'll silently accept it.
>> Either we should handle that case by returning error_mark_node in C++26 and
>> above, or we should assert that it can't happen.
> 
> We actually can get there.  But returning error_mark_node in C++26
> causes problems: we hit:
> 
>          /* If we ran into a problem, make sure we complained.  */
>          gcc_assert (seen_error ());
> 
> because a permerror doesn't count as an error.  Either we'd have to go
> back to DK_ERROR, or leave the patch as-is.

Hmm, I guess cp_seen_error should also consider werrorcount.

Jason



More information about the Gcc-patches mailing list