3.11 Declarative Parts
Syntax
Static Semantics
Dynamic Semantics
{elaborated}
An elaborable construct is in the
elaborated
state after the normal completion of its elaboration. Prior to that,
it is
not yet elaborated.
Ramification: The elaborated state is
only important for bodies; certain uses of a body raise an exception
if the body is not yet elaborated.
Note that "prior" implies before the
start of elaboration, as well as during elaboration.
The use of the term "normal completion"
implies that if the elaboration propagates an exception or is aborted,
the declaration is not elaborated. RM83 missed the aborted case.
{Elaboration_Check
[partial]} {check,
language-defined (Elaboration_Check)} For
a construct that attempts to use a body, a check (Elaboration_Check)
is performed, as follows:
{
8652/0014}
{
AI95-00064-01}
For a call to a (non-protected) subprogram that has an explicit body,
a check is made that the body is already elaborated. This check and the
evaluations of any actual parameters of the call are done in an arbitrary
order.
Discussion: AI83-00180 specifies that
there is no elaboration check for a subprogram defined by a
pragma
Interface (or equivalently,
pragma
Import). AI83-00430 specifies that there is no elaboration check for
an enumeration literal. AI83-00406 specifies that the evaluation of parameters
and the elaboration check occur in an arbitrary order. AI83-00406 applies
to generic instantiation as well (see below).
{
8652/0014}
{
AI95-00064-01}
A subprogram can be completed by a renaming-as-body, and we need to make
an elaboration check on such a body, so we use “body” rather
than
subprogram_body
above.
For a call to a protected operation of a protected
type (that has a body — no check is performed if a
pragma
Import applies to the protected type), a check is made that the
protected_body
is already elaborated. This check and the evaluations of any actual parameters
of the call are done in an arbitrary order.
Discussion: A protected type has only
one elaboration “bit,” rather than one for each operation,
because one call may result in evaluating the barriers of other entries,
and because there are no elaborable declarations between the bodies of
the operations. In fact, the elaboration of a
protected_body
does not elaborate the enclosed bodies, since they are not considered
independently elaborable.
Note that there is no elaboration check when
calling a task entry. Task entry calls are permitted even before the
associated
task_body
has been seen. Such calls are simply queued until the task is activated
and reaches a corresponding
accept_statement.
We considered a similar rule for protected entries — simply queuing
all calls until the
protected_body
was seen, but felt it was not worth the possible implementation overhead,
particularly given that there might be multiple instances of the protected
type.
For the activation of a task, a check is made by
the activator that the
task_body
is already elaborated. If two or more tasks are being activated together
(see
9.2), as the result of the elaboration
of a
declarative_part
or the initialization for the object created by an allocator, this check
is done for all of them before activating any of them.
Reason: As specified by AI83-00149, the
check is done by the activator, rather than by the task itself. If it
were done by the task itself, it would be turned into a Tasking_Error
in the activator, and the other tasks would still be activated.
For the instantiation of a generic unit that has
a body, a check is made that this body is already elaborated. This check
and the evaluation of any
explicit_generic_actual_parameters
of the instantiation are done in an arbitrary order.
{Program_Error (raised
by failure of run-time check)} The exception
Program_Error is raised if any of these checks fails.
Extensions to Ada 83
The syntax rule for
proper_body
now allows a
protected_body,
and the rules for elaboration checks now cover calls on protected operations.
Wording Changes from Ada 83
The syntax rule for
later_declarative_item
is removed; the syntax rule for
declarative_item
is new.
RM83 defines “elaborated” and “not
yet elaborated” for
declarative_items
here, and for other things in
3.1, “
Declarations”.
That's no longer necessary, since these terms are fully defined in
3.1.
Wording Changes from Ada 95
{
8652/0009}
{
AI95-00137-01}
Corrigendum: Changed representation clauses to aspect clauses
to reflect that they are used for more than just representation.
{
8652/0014}
{
AI95-00064-01}
Corrigendum: Clarified that the elaboration check applies to all
kinds of subprogram bodies.
{
AI95-00420-01}
Defined “declaration list” to avoid confusion for various
rules. Other kinds of declaration list are defined elsewhere.
Sponsored by Ada-Europe