Skip to main content

3.11 Declarative Parts

danger

This Reference Manual output has not been verified, and may contain omissions or errors. Report any problems on the tracking issue

1

[A declarative_part contains declarative_items (possibly none).]

Syntax​

2
declarative_part ::= {declarative_item}
3
declarative_item ::= 
    basic_declarative_item | body
4/1
{8652/0009} basic_declarative_item ::= 
    basic_declaration | aspect_clause | use_clause
5
body ::= proper_body | body_stub
6
proper_body ::= 
    subprogram_body | package_body | task_body | protected_body

Static Semantics​

6.1/2

The list of declarative_items of a declarative_part is called the declaration list of the declarative_part.

Dynamic Semantics​

7

The elaboration of a declarative_part consists of the elaboration of the declarative_items, if any, in the order in which they are given in the declarative_part.

8

An elaborable construct is in the elaborated state after the normal completion of its elaboration. Prior to that, it is not yet elaborated.

8.a
ramification
The elaborated state is only important for bodies; certain uses of a body raise an exception if the body is not yet elaborated.
8.b
note
Note that "prior" implies before the start of elaboration, as well as during elaboration.
8.c
note
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.
9

For a construct that attempts to use a body, a check (Elaboration_Check) is performed, as follows:

10/1
  • {8652/0014} 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.
10.a
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).
10.a.1/3
note
{8652/0014} A subprogram can be completed by a renaming-as-body, a null_procedure_declaration, or an expression_function_declaration, and we need to make an elaboration check on such a body, so we use “body” rather than subprogram_body above.
11/3
  • For a call to a protected operation of a protected type (that has a body — no check is performed if the protected type is imported — see B.1), 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.
11.a
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.
11.b
note
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.
12
  • 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.
12.a
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.
13
  • 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.
14

The exception Program_Error is raised if any of these checks fails.

Extensions to Ada 83​

14.a/2
note
The syntax for declarative_part is modified to remove the ordering restrictions of Ada 83; that is, the distinction between basic_declarative_items and later_declarative_items within declarative_parts is removed. This means that things like use_clauses and object_declarations can be freely intermixed with things like bodies.
14.b
note
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​

14.c
note
The syntax rule for later_declarative_item is removed; the syntax rule for declarative_item is new.
14.d
note
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.
14.e
note
In RM83, all uses of declarative_part are optional (except for the one in block_statement with a declare) which is sort of strange, since a declarative_part can be empty, according to the syntax. That is, declarative_parts are sort of “doubly optional”. In Ada 95, these declarative_parts are always required (but can still be empty). To simplify description, we go further and say (see 5.6, “Block Statements”) that a block_statement without an explicit declarative_part is equivalent to one with an empty one.

Wording Changes from Ada 95​

14.f/2
note
{8652/0009} Corrigendum: Changed representation clauses to aspect clauses to reflect that they are used for more than just representation.
14.g/2
note
{8652/0014} Corrigendum: Clarified that the elaboration check applies to all kinds of subprogram bodies.
14.h/2
note
Defined “declaration list” to avoid confusion for various rules. Other kinds of declaration list are defined elsewhere.

3.11.1 Completions of Declarations​

1/3

{8652/0014} Declarations sometimes come in two parts. A declaration that requires a second part is said to require completion. The second part is called the completion of the declaration (and of the entity declared), and is either another declaration, a body, or a pragma. A body is a body, an entry_body, a null_procedure_declaration or an expression_function_declaration that completes another declaration, or a renaming-as-body (see 8.5.4).

1.a
discussion
Throughout the RM95, there are rules about completions that define the following:
1.b
  • Which declarations require a corresponding completion.
    • 1.c
  • Which constructs can only serve as the completion of a declaration.
    • 1.d
  • Where the completion of a declaration is allowed to be.
    • 1.e
  • What kinds of completions are allowed to correspond to each kind of declaration that allows one.
1.f
note
Don't confuse this compile-time concept with the run-time concept of completion defined in 7.6.1.
1.g
note
Note that the declaration of a private type (if limited) can be completed with the declaration of a task type, which is then completed with a body. Thus, a declaration can actually come in three parts.
1.h/3
note
An incomplete type (whether declared in the limited view of a package or not) may be completed by a private type declaration, so we can in fact have four parts.
1.i/3
note
In Ada 2012, there are no language-defined pragmas that act as completions. Pragma Import (which is obsolescent) has the effect of setting aspect Import to True; such an aspect makes giving a completion illegal. The wording that allows pragmas as completions was left as it is harmless and appears in many places in this Reference Manual.

Name Resolution Rules​

2

A construct that can be a completion is interpreted as the completion of a prior declaration only if:

3
  • The declaration and the completion occur immediately within the same declarative region;
    • 4
  • The defining name or defining_program_unit_name in the completion is the same as in the declaration, or in the case of a pragma, the pragma applies to the declaration;
    • 5
  • If the declaration is overloadable, then the completion either has a type-conformant profile, or is a pragma.

Legality Rules​

6/3

An implicit declaration shall not have a completion. For any explicit declaration that is specified to require completion, there shall be a corresponding explicit completion, unless the declared entity is imported (see B.1).

6.a.1/2
note
To be honest: The implicit declarations occurring in a limited view do have a completion (the explicit declaration occurring in the full view) but that's a special case, since the implicit declarations are actually built from the explicit ones. So they do not require a completion, they have one by fiat.
6.a/3
discussion
The implicit declarations of predefined operators are not allowed to have a completion. Enumeration literals, although they are subprograms, are not allowed to have a corresponding subprogram_body. That's because the completion rules are described in terms of constructs (subprogram_declarations) and not entities (subprograms). When a completion is required, it has to be explicit; the implicit null package_body that Clause 7 talks about cannot serve as the completion of a package_declaration if a completion is required.
7

At most one completion is allowed for a given declaration. Additional requirements on completions appear where each kind of completion is defined.

7.a
ramification
A subunit is not a completion; the stub is.
7.b
note
If the completion of a declaration is also a declaration, then that declaration might have a completion, too. For example, a limited private type can be completed with a task type, which can then be completed with a task body. This is not a violation of the “at most one completion” rule.
8

A type is completely defined at a place that is after its full type definition (if it has one) and after all of its subcomponent types are completely defined. A type shall be completely defined before it is frozen (see 13.14 and 7.3).

8.a
reason
Index types are always completely defined — no need to mention them. There is no way for a completely defined type to depend on the value of a (still) deferred constant.
9/3
note
NOTE 1 Completions are in principle allowed for any kind of explicit declaration. However, for some kinds of declaration, the only allowed completion is an implementation-defined pragma, and implementations are not required to have any such pragmas.
9.a/3
note
This paragraph was deleted.
10
note
NOTE 2 There are rules that prevent premature uses of declarations that have a corresponding completion. The Elaboration_Checks of 3.11 prevent such uses at run time for subprograms, protected operations, tasks, and generic units. The rules of 13.14, “Freezing Rules” prevent, at compile time, premature uses of other entities such as private types and deferred constants.

Wording Changes from Ada 83​

10.a
note
This subclause is new. It is intended to cover all kinds of completions of declarations, be they a body for a spec, a full type for an incomplete or private type, a full constant declaration for a deferred constant declaration, or a pragma Import for any kind of entity.

Wording Changes from Ada 95​

10.b/2
note
{8652/0014} Corrigendum: Added a definition of body, which is different than body or body.

Wording Changes from Ada 2005​

10.c/3
note
Added null procedures and expression functions that are completions to the definition of body.