On 12.08.2025 11:55, Nicola Vetrini wrote:
> On 2025-08-12 09:25, Jan Beulich wrote:
>> On 11.08.2025 23:25, Nicola Vetrini wrote:
>>> On 2025-08-11 22:30, Dmytro Prokopchuk1 wrote:
>>>> --- a/xen/arch/arm/decode.c
>>>> +++ b/xen/arch/arm/decode.c
>>>> @@ -178,6 +178,9 @@ static int decode_thumb(register_t pc, struct
>>>> hsr_dabt *dabt)
>>>> case 3: /* Signed byte */
>>>> update_dabt(dabt, reg, 0, true);
>>>> break;
>>>> + default:
>>>> + ASSERT_UNREACHABLE();
>>>> + break;
>>>> }
>>>>
>>>
>>> I think this is fine, and there should be no problems with the break
>>> being unreachable in some configs due to the call property for
>>> ASSERT_UNREACHABLE
>>>
>>> -doc_begin="Calls to function `__builtin_unreachable()' in the
>>> expansion
>>> of macro
>>> `ASSERT_UNREACHABLE()' are not considered to have the `noreturn'
>>> property."
>>> -call_properties+={"name(__builtin_unreachable)&&stmt(begin(any_exp(macro(name(ASSERT_UNREACHABLE)))))",
>>> {"noreturn(false)"}}
>>> -doc_end
>>
>> Did you also see Julien's reply? Imo, to address a complaint from one
>> rule, another rule is then being violated: The "default" label itself
>> is unreachable here.
>
> Unfortunately only after sending my reply, however the point here is
> that ASSERT_UNREACHABLE() is now considered as if it was not actually a
> source of unreachability for any statement below (which is the case only
> in configurations where NDEBUG is undefined iirc). This was done mainly
> to allow stubs for Rule 2.1 so that their return statement just after an
> ASSERT_UNREACHABLE() is not seen as a problem, but given that the
> configuration to obtain that is global it influences treatment for other
> rules as well, and its addition is relatively recent compared to the
> text written in rules.rst.
I understand the special treatment of ASSERT_UNREACHABLE(). Yet even if that
wasn't there, both the default: label and the break; statement would be
unreachable here.
Jan
