> While it is a macro, it can be made a no-op, or even with compiler-specific instructions like __builtin_unreachable.
My PR 16280 uses _Py_NO_RETURN which uses __attribute__((__noreturn__)) with GCC and clang.
I'm not sure how __builtin_unreachable could be used with Py_UNREACHABLE() macro.
> While it is a macro, it can be made a no-op
I understood that Py_UNREACHABLE() is used on purpose to prevent undefined behavior. For example, if a function accepts an enum, but is called with a value which is not part of the enum: what should happen? Should Python crash? Usually, we try to be nice and return an error. But sometimes, you cannot report an error and so Py_UNREACHABLE() is a good solution.
> I prefer to keep it a macro. The compiler does not know that it is never executed, so it can generate a suboptimal code.
I don't see how PR 16280 could have an effect on that. I don't see how the compiler can guess that the code is never executed with the current macro.
--
Using a function allows to put a breakpoint on it.
In fact, I can easily modify PR 16280 to keep the macro, since I only call Py_FatalError() with a string. The function body is simple.