7.6.1 Completion and Finalization
This subclause defines
completion and
leaving
of the execution of constructs and entities. A
master is the execution
of a construct that includes finalization of local objects after it is
complete (and after waiting for any local tasks — see
9.3),
but before leaving. Other constructs and entities are left immediately
upon completion.
Dynamic Semantics
The execution
of a construct or entity is
complete when the end of that execution
has been reached, or when a transfer of control (see
5.1)
causes it to be abandoned.
Completion
due to reaching the end of execution, or due to the transfer of control
of an
exit_statement,
return statement,
goto_statement,
or
requeue_statement
or of the selection of a
terminate_alternative
is
normal completion. Completion is
abnormal otherwise
— when control is transferred out of a construct due to abort or
the raising of an exception.
After execution
of a construct or entity is complete, it is
left, meaning that
execution continues with the next action, as defined for the execution
that is taking place.
Leaving an execution happens
immediately after its completion, except in the case of a
master:
the execution of a body other than a
package_body;
the execution of a
statement;
or the evaluation of an
expression,
function_call,
or
range that
is not part of an enclosing
expression,
function_call,
range, or
simple_statement
other than a
simple_return_statement.
A master is finalized after it is complete, and before it is left.
For the
finalization of
a master, dependent tasks are first awaited, as explained in
9.3.
Then each object whose accessibility level is the same as that of the
master is finalized if the object was successfully initialized and still
exists. These actions are performed whether the master is left by reaching
the last statement or via a transfer of control. When a transfer of control
causes completion of an execution, each included master is finalized
in order, from innermost outward.
For
the
finalization of an object:
If the full type of the object is an elementary
type, finalization has no effect;
If the full type of the object is a tagged type,
and the tag of the object identifies a controlled type, the Finalize
procedure of that controlled type is called;
If the full type of the object is a protected type,
or if the full type of the object is a tagged type and the tag of the
object identifies a protected type, the actions defined in
9.4
are performed;
If the full type of the object is a composite type,
then after performing the above actions, if any, every component of the
object is finalized in an arbitrary order, except as follows:
if the object has a component with an access discriminant constrained
by a per-object expression, this component is finalized before any components
that do not have such discriminants; for an object with several components
with such a discriminant, they are finalized in the reverse of the order
of their
component_declarations;
If the object has coextensions (see
3.10.2),
each coextension is finalized after the object whose access discriminant
designates it.
Immediately before an instance
of Unchecked_Deallocation reclaims the storage of an object, the object
is finalized. If an instance of Unchecked_Deallocation is never applied
to an object created by an
allocator,
the object will still exist when the corresponding master completes,
and it will be finalized then.
The finalization of a master performs finalization
of objects created by declarations in the master in the reverse order
of their creation. After the finalization of a master is complete, the
objects finalized as part of its finalization cease to
exist,
as do any types and subtypes defined and created within the master.
Each nonderived
access type
T has an associated
collection,
which is the set of objects created by
allocators
of
T, or of types derived from
T. Unchecked_Deallocation
removes an object from its collection. Finalization of a collection consists
of finalization of each object in the collection, in an arbitrary order.
The collection of an access type is an object implicitly declared at
the following place:
For a named access type, the first freezing point
(see
13.14) of the type.
For the type of an access parameter, the call that
contains the
allocator.
For the type of an access result, within the master
of the call (see
3.10.2).
For any other anonymous access type, the first
freezing point of the innermost enclosing declaration.
The master of an object is the master enclosing
its creation whose accessibility level (see
3.10.2)
is equal to that of the object, except in the case of an anonymous object
representing the result of an
aggregate
or function call. If such an anonymous object is part of the result of
evaluating the actual parameter expression for an explicitly aliased
parameter of a function call, the master of the object is the innermost
master enclosing the evaluation of the
aggregate
or function call, excluding the
aggregate
or function call itself. Otherwise, the master of such an anonymous object
is the innermost master enclosing the evaluation of the
aggregate
or function call, which may be the
aggregate
or function call itself.
In the case of an
expression
that is a master, finalization of any (anonymous) objects occurs after
completing evaluation of the
expression
and all use of the objects, prior to starting the execution of any subsequent
construct.
Bounded (Run-Time) Errors
It
is a bounded error for a call on Finalize or Adjust that occurs as part
of object finalization or assignment to propagate an exception. The possible
consequences depend on what action invoked the Finalize or Adjust operation:
For an Adjust invoked as part of assignment operations
other than those invoked as part of an
assignment_statement,
other adjustments due to be performed might or might not be performed,
and then Program_Error is raised. During its propagation, finalization
might or might not be applied to objects whose Adjust failed.
For
an Adjust invoked as part of an
assignment_statement,
any other adjustments due to be performed are performed, and then Program_Error
is raised.
For a Finalize invoked as part
of a call on an instance of Unchecked_Deallocation, any other finalizations
due to be performed are performed, and then Program_Error is raised.
This paragraph
was deleted.
For a Finalize invoked due
to reaching the end of the execution of a master, any other finalizations
associated with the master are performed, and Program_Error is raised
immediately after leaving the master.
For a Finalize invoked by the
transfer of control of an
exit_statement,
return statement,
goto_statement,
or
requeue_statement,
Program_Error is raised no earlier than after the finalization of the
master being finalized when the exception occurred, and no later than
the point where normal execution would have continued. Any other finalizations
due to be performed up to that point are performed before raising Program_Error.
For a Finalize invoked by a transfer of control
that is due to raising an exception, any other finalizations due to be
performed for the same master are performed; Program_Error is raised
immediately after leaving the master.
For a Finalize invoked by a transfer of control
due to an abort or selection of a terminate alternative, the exception
is ignored; any other finalizations due to be performed are performed.
Implementation Permissions
If the execution of an
allocator
propagates an exception, any parts of the allocated object that were
successfully initialized may be finalized as part of the finalization
of the innermost master enclosing the
allocator.
The implementation may finalize objects created
by
allocators
for an access type whose storage pool supports subpools (see
13.11.4)
as if the objects were created (in an arbitrary order) at the point where
the storage pool was elaborated instead of at the first freezing point
of the access type.
18 The rules of Clause 10 imply that immediately
prior to partition termination, Finalize operations are applied to library-level
controlled objects (including those created by
allocators
of library-level access types, except those already finalized). This
occurs after waiting for library-level tasks to terminate.
19 A constant is only constant between
its initialization and finalization. Both initialization and finalization
are allowed to change the value of a constant.
20 Abort is deferred during certain operations
related to controlled types, as explained in
9.8.
Those rules prevent an abort from causing a controlled object to be left
in an ill-defined state.
21 The Finalize procedure is called upon
finalization of a controlled object, even if Finalize was called earlier,
either explicitly or as part of an assignment; hence, if a controlled
type is visibly controlled (implying that its Finalize primitive is directly
callable), or is nonlimited (implying that assignment is allowed), its
Finalize procedure should be designed to have no ill effect if it is
applied a second time to the same object.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
