6.5.1 Nonreturning SubprogramsPragma No_Return
will have to wait for Ada 2028 2020
For a subprogram procedure
or generic subprogram procedure
the following language-defined representation aspect may be specified:
The type of aspect No_Return is Boolean. When aspect No_Return is True
for an entity, the entity is said to be nonreturning
If directly specified, the aspect_definition
shall be a static expression. [This aspect is never inherited;] if not
directly specified, the aspect is False.
Aspect Description for No_Return:
A subprogram procedure
will not return normally.
If a generic subprogram procedure
is nonreturning, then so are its instances. If a subprogram procedure
declared within a generic unit is nonreturning, then so are the corresponding
copies of that subprogram procedure
Reason: A null procedure cannot have
the appropriate nonreturning semantics, as it does not raise an exception
or loop forever.
The procedure can be abstract. If a nonreturning subprogram procedure
is renamed (anywhere) calls through the new name still have the nonreturning
still require at least one return statement in a function; we just require
that all such return statements don't actually return a value.
A subprogram procedure
shall be nonreturning if it overrides a dispatching nonreturning subprogram procedure
In addition to the places where Legality Rules normally
apply (see 12.3
), this rule applies also in
the private part of an instance of a generic unit.
Reason: This ensures that dispatching
calls to nonreturning subprograms procedures
will, in fact, not return.
If a renaming-as-body completes a nonreturning subprogram procedure
declaration, then the renamed subprogram procedure
shall be nonreturning.
Reason: This ensures that no extra code
is needed to implement the renames (that is, no wrapper is needed) as
the body has the same property.
Paragraph 8 was deleted.
If the body of a nonreturning procedure completes normally, Program_Error
is raised at the point of the call.
Note that there is no name for suppressing this check, since the check
represents a bug, imposes no time overhead, and minimal space overhead
(since it can usually be statically eliminated as dead code). We don't need a similar rule for nonreturning functions as this is standard
semantics for all functions that normally complete without a transfer
of control (such as a return statement).
Implementation Note: If a nonreturning
procedure tries to return, we raise Program_Error. This is stated as
happening at the call site, because we do not wish to allow the procedure
to handle the exception (and then, perhaps, try to return again!). However,
the expected run-time model is that the compiler will generate raise
Program_Error at the end of the procedure body (but not handleable by
the procedure itself), as opposed to doing it at the call site. (This
is just like the typical run-time model for functions that fall off the
end without returning a value). The reason is indirect calls: in P.all(...);,
the compiler cannot know whether P designates a nonreturning procedure
or a normal one. Putting the raise Program_Error in the procedure's
generated code solves this problem neatly.
Similarly, if one passes a nonreturning procedure
to a generic formal parameter, the compiler cannot know this at call
sites (in shared code implementations); the raise-in-body solution deals
with this neatly.
Fail(Msg : String) -- raises Fatal_Error exception
-- Inform compiler and reader that procedure never returns normally
Extensions to Ada 95
Extensions to Ada 2005
Extensions to Ada 2012
Aspect No_Return can now be
applied to functions as well as procedures.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe