While [[noreturn]] can be applied to a constexpr function, the current rules in [expr.const] p5.8 and [dcl.attr.noreturn] p2 state that constant evaluation fails when returning from a [[noreturn]] function. Such effect seems to be mandatory.
MSVC, ICC, and Clang currently accept the following code snippet. GCC starts to reject it since GCC14 but its current diagnostic message is weird (Godbolt link).
[[noreturn]] constexpr void unreachable_like() {}
constexpr int x = (unreachable_like(), 0);
It may be wanted to make the effect optional in the way of handling [[assume]].
Suggested resolution:
Modify [expr.const] p5 as indicated:
(5.8) an operation that would have undefined behavior as specified in [intro] through [cpp], excluding [dcl.attr.assume] and [dcl.attr.noreturn];
[...]
(5.33) [...] would not evaluate to true~.~ , or
[Note 4: [...] — end note]
(5.X) the completion of the invocation of a function previous declared with the noreturn attribute.
Full name of submitter (unless configured in github; will be published with the issue): Jiang An
Reference (section label): [expr.const], [dcl.attr.noreturn]
Link to reflector thread (if any):
Issue description:
While
[[noreturn]]
can be applied to a constexpr function, the current rules in [expr.const] p5.8 and [dcl.attr.noreturn] p2 state that constant evaluation fails when returning from a[[noreturn]]
function. Such effect seems to be mandatory.MSVC, ICC, and Clang currently accept the following code snippet. GCC starts to reject it since GCC14 but its current diagnostic message is weird (Godbolt link).
It may be wanted to make the effect optional in the way of handling
[[assume]]
.Suggested resolution:
Modify [expr.const] p5 as indicated: