10.2 Program Execution
This Reference Manual output has not been verified, and may contain omissions or errors. Report any problems on the tracking issue
An Ada program consists of a set of partitions[, which can execute in parallel with one another, possibly in a separate address space, and possibly on a separate computer.]
Post-Compilation Rules
2/5A partition is a program or part of a program that can be invoked from outside the Ada implementation. [For example, on many systems, a partition can be an executable file generated by the system linker.] The user can explicitly assign library units to a partition. The assignment is done in an implementation-defined manner. The compilation units included in a partition are those of the explicitly assigned library units, as well as other compilation units needed by those library units. The compilation units needed by a given compilation unit (the needed compilation units) are determined as follows (unless specified otherwise via an implementation-defined pragma
, or by some other implementation-defined means):
- A compilation unit is a needed compilation unit of itself;
- If a compilation unit is among the needed compilation units, then so are any compilation units upon which it depends semantically;
- If a
library_unit_declaration
is among the needed compilation units, then so is any correspondinglibrary_unit_body
; 6/5 - If a compilation unit with stubs is among the needed compilation units, then so are any corresponding subunits;
proper_bodies
. - If the (implicit) declaration of the limited view of a library package is among the needed compilation units, then so is the explicit declaration of the library package.
with_clause
.limited_with_clause
. While this isn't strictly necessary (no objects of types imported from such a unit can be created), it ensures that all incomplete types are eventually completed, and is the least surprising option. The user can optionally designate (in an implementation-defined manner) one subprogram as the main subprogram for the partition. A main subprogram, if specified, shall be a subprogram.
Each partition has an anonymous environment task[, which is an implicit outermost task whose execution elaborates the library_item
s of the environment declarative_part
, and then calls the main subprogram, if there is one. A partition's execution is that of its tasks.]
[The order of elaboration of library units is determined primarily by the elaboration dependences.] There is an elaboration dependence of a given library_item
upon another if the given library_item
or any of its subunits depends semantically on the other library_item
. In addition, if a given library_item
or any of its subunits has a pragma
Elaborate or Elaborate_All that names another library unit, then there is an elaboration dependence of the given library_item
upon the body of the other library unit, and, for Elaborate_All only, upon each library_item
that is a needed compilation unit of the declaration of the other library unit.
library_item
s are “needed by” a given declaration.library_item
s, whereas the other two forms of dependence are among compilation units. Note that elaboration dependence includes semantic dependence. It's a little bit sad that the Elaborate_Body aspect can't be folded into this mechanism. It follows from the definition that the elaboration dependence relationship is transitive. Note that the wording of the rule does not need to take into account a semantic dependence of a library_item
or one of its subunits upon a subunit of a different library unit, because that can never happen. The environment task for a partition has the following structure:
task Environment_Task;
12task body Environment_Task is
... (1) -- The environment declarative_part
-- (that is, the sequence of library_items) goes here.
begin
... (2) -- Call the main subprogram, if there is one.
end Environment_Task;
sequence_of_statements
is an infinite loop rather than a call on a main subprogram. The environment declarative_part
at (1) is a sequence of declarative_item
s consisting of copies of the library_item
s included in the partition[. The order of elaboration of library_item
s is the order in which they appear in the environment declarative_part
]:
- The order of all included
library_item
s is such that there are no forward elaboration dependences.
library_item
depends on itself, we don't require it to be elaborated before itself. See AI83-00113/12. This can happen only in pathological circumstances. For example, if a library subprogram_body
has no corresponding subprogram_declaration
, and one of the subunits of the subprogram_body
mentions the subprogram_body
in a with_clause
, the subprogram_body
will depend on itself. For another example, if a library_unit_body
applies a pragma
Elaborate_All to its own declaration, then the library_unit_body
will depend on itself. - Any included
library_unit_declaration
for which aspect Elaborate_Body is True is immediately followed by itslibrary_unit_body
, if included.
- All
library_item
s declared pure occur before any that are not declared pure. 17 - All preelaborated
library_item
s occur before any that are not preelaborated.
declarative_part
has the properties required of all environments (see 10.1.4). However, the environment declarative_part
of a partition will typically contain fewer compilation units than the environment declarative_part
used at compile time — only the “needed” ones are included in the partition. There shall be a total order of the library_item
s that obeys the above rules. The order is otherwise implementation defined.
pragma
s or Elaborate_Body aspects that cause circular ordering requirements, thus preventing an order that has no forward elaboration dependences. library_item
s.The full expanded names of the library units and subunits included in a given partition shall be distinct.
The sequence_of_statements
of the environment task (see (2) above) consists of either:
- A call to the main subprogram, if the partition has one. If the main subprogram has parameters, they are passed; where the actuals come from is implementation defined. What happens to the result of a main function is also implementation defined.
or:
- A
null_statement
, if there is no main subprogram.
sequence_of_statements
is an infinite loop. See E.1. The mechanisms for building and running partitions are implementation defined. [These can be combined into one operation, as, for example, in dynamic linking, or “load-and-go” systems.]
Dynamic Semantics
25The execution of a program consists of the execution of a set of partitions. Further details are implementation defined. The execution of a partition starts with the execution of its environment task, ends when the environment task terminates, and includes the executions of all tasks of the partition. [The execution of the (implicit) task_body
of the environment task acts as a master for all other tasks created as part of the execution of the partition. When the environment task completes (normally or abnormally), it waits for the termination of all such tasks, and then finalizes any remaining objects of the partition.]
Bounded (Run-Time) Errors
26Once the environment task has awaited the termination of all other tasks of the partition, any further attempt to create a task (during finalization) is a bounded error, and may result in the raising of Program_Error either upon creation or activation of the task. If such a task is activated, it is not specified whether the task is awaited prior to termination of the environment task.
Implementation Requirements
27The implementation shall ensure that all compilation units included in a partition are consistent with one another, and are legal according to the rules of the language.
package A is -- Version 1.
...
end A;
27.cwith A;
package B is
end B;
27.dpackage A is -- Version 2.
...
end A;
27.ewith A;
package C is
end C;
Implementation Permissions
28/3The kind of partition described in this subclause is known as an active partition. An implementation is allowed to support other kinds of partitions, with implementation-defined semantics.
sequence_of_statements
. An implementation may restrict the kinds of subprograms it supports as main subprograms. However, an implementation is required to support all main subprograms that are public parameterless library procedures.
generic_instantiation
s, as well as those that are children of library units other than Standard. Generic units are, of course, not allowed to be main subprograms, since they are not subprograms.If the environment task completes abnormally, the implementation may abort any dependent tasks.
exception_handler
that can handle exceptions raised in both the environment declarative_part
and the main subprogram, such that the dependent tasks can be aborted. If we put an exception_handler
in the body of the environment task, then it won't handle exceptions that occur during elaboration of the environment declarative_part
. If we were to move those things into a nested block_statement
, with the exception_handler
outside that, then the block_statement
would await the library tasks we are trying to abort.library_item
s that is consistent with the partial ordering defined above does not always ensure that each library_unit_body
is elaborated before any other compilation unit whose elaboration necessitates that the library_unit_body
be already elaborated. (In particular, there is no requirement that the body of a library unit be elaborated as soon as possible after the library_unit_declaration
is elaborated, unless the pragmas or aspects in 10.2.1 are used.)library_item
s, and by tasks created by that elaboration. Passive partitions, which cannot have main subprograms, are defined in Annex E, “Distributed Systems”. pragma
Elaborate or Elaborate_All are defined in terms of “needed by”.) This property allows us to use the environment concept both at compile time and at partition-construction time/run time. Extensions to Ada 83
Wording Changes from Ada 83
Wording Changes from Ada 95
10.2.1 Elaboration Control
1/5[ This subclause defines aspects and pragmas that help control the elaboration order of library_item
s.]
Language Design Principles
aggregate
s, string_literal
s, and concatenations thereof. It is important to be able to write link-time evaluated expressions involving the First, Last, and Length attributes of such data structures (including variables), because they might be initialized with positional aggregate
s or string_literal
s, and we don't want the user to have to count the elements. There is no corresponding need for accessing discriminants, since they can be initialized with a static constant, and then the constant can be referred to elsewhere. It is important to allow link-time initialized data structures involving discriminant-dependent components. It is important to be able to write link-time evaluated expressions involving pointers (both access values and addresses) to the above-mentioned data structures.Syntax
2/5
Paragraphs 2 through 4 were moved to Annex J, “Obsolescent Features”.
Legality Rules
5An elaborable construct is preelaborable unless its elaboration performs any of the following actions:
- The execution of a
statement
other than anull_statement
.
- A call to a subprogram other than:
- a static function;
- an instance of Unchecked_Conversion (see 13.9);
- a function declared in System.Storage_Elements (see 13.7.1); or
- the functions To_Pointer and To_Address declared in an instance of System.Address_to_Access_Conversions (see 13.7.2).
- The evaluation of a
primary
that is aname
of an object, unless thename
is a static expression, or statically denotes a discriminant of an enclosing type.
name
, but not as a primary
. For example, one can evaluate an attribute of the object. One can evaluate an attribute_reference
, so long as it does not denote an object, and its prefix
does not disobey any of these rules. For example, Obj'Access, Obj'Unchecked_Access, and Obj'Address are generally legal in preelaborated library units. - The creation of an object [(including a component)] that is initialized by default, if its type does not have preelaborable initialization. Similarly, the evaluation of an
extension_aggregate
with an ancestorsubtype_mark
denoting a subtype of such a type.
- The elaboration of any elaborable construct that is not preelaborable.
A generic declaration is preelaborable unless every instance would perform one of the above actions.
A generic body is preelaborable only if elaboration of a corresponding instance body would not perform any such actions, presuming that:
- the actual for each discriminated formal derived type, formal private type, or formal private extension declared within the formal part of the generic unit is a type that does not have preelaborable initialization, unless the Preelaborable_Initialization aspect was specified for the formal type;
- the actual for each formal type is nonstatic;
- the actual for each formal object is nonstatic; and
- the actual for each formal subprogram is a user-defined subprogram.
{8652/0035} When the library unit aspect (see 13.1.1) Preelaborate of a program unit is True, the unit is said to be preelaborated. When the Preelaborate aspect is specified True for a library unit, all compilation units of the library unit are preelaborated. The declaration and body of a preelaborated library unit, and all subunits that are elaborated as part of elaborating the library unit, shall be preelaborable. All compilation units of a preelaborated library unit shall depend semantically only on declared pure or preelaborated library_item
s. In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit. [ If a library unit is preelaborated, then its declaration, if any, and body, if any, are elaborated prior to all nonpreelaborated library_item
s of the partition.]
The following rules specify which entities have preelaborable initialization, namely that the Preelaborable_Initialization aspect of the entity is True:
- The partial view of a private type or private extension, a protected type without
entry_declaration
s, a generic formal private type, or a generic formal derived type, has preelaborable initialization if and only if the Preelaborable_Initialization aspect has been specified True for them. [A protected type withentry_declaration
s or a task type never has preelaborable initialization.] The Preelaborable_Initialization aspect of a partial view of a type may be specified as False, even if the full view of the type has preelaborable initialization. Similarly, a generic formal type may be specified with Preelaborable_Initialization False, even if the actual type in an instance has preelaborable initialization. 11.3/2 - A component (including a discriminant) of a record or protected type has preelaborable initialization if its declaration includes a
default_expression
whose execution does not perform any actions prohibited in preelaborable constructs as described above, or if its declaration does not include a default expression and its type has preelaborable initialization. 11.4/3 - A derived type has preelaborable initialization if its parent type has preelaborable initialization and if the noninherited components all have preelaborable initialization. However, a controlled type with an Initialize procedure that is not a null procedure does not have preelaborable initialization.
- A view of a type has preelaborable initialization if it is an elementary type, an array type whose component type has preelaborable initialization, a record type whose components all have preelaborable initialization, or an interface type.
The following attribute is defined for a nonformal composite subtype S declared within the visible part of a package or a generic package, or a generic formal private subtype or formal derived subtype:
S'Preelaborable_Initialization
- This attribute is of Boolean type, and its value reflects whether the type of S has preelaborable initialization. The value of this attribute, the type-related Preelaborable_Initialization aspect, may be specified for any type for which the attribute is defined. The value shall be specified by a static expression, unless the type is not a formal type but is nevertheless declared within a generic package. In this latter case, the value may also be specified by references to the Preelaborable_Initialization attribute of one or more formal types visible at the point of the declaration of the composite type, conjoined with and.
If the Preelaborable_Initialization aspect is specified True for a private type or a private extension, the full view of the type shall have preelaborable initialization. If the aspect is specified True for a protected type, the protected type shall not have entries, and each component of the protected type shall have preelaborable initialization. If the aspect is specified True for a generic formal type, then in a generic_instantiation
the corresponding actual type shall have preelaborable initialization. If the aspect definition includes one or more Preelaborable_Initialization attribute_reference
s, then the full view of the type shall have preelaborable initialization presuming the types mentioned in the prefix
es of the attribute_reference
s all have preelaborable initialization. For any other composite type, the aspect shall be specified statically True or False only if it is confirming . In addition to the places where Legality Rules normally apply (see 12.3), these rules apply also in the private part of an instance of a generic unit.
entry_declaration
s and task types not have preelaborable initialization, but they cannot have Preelaborable_Initialization aspect specified True for them. Implementation Advice
12In an implementation, a type declared in a preelaborated package should have the same representation in every elaboration of a given version of the package, whether the elaborations occur in distinct executions of the same program, or in executions of distinct programs or partitions that include the given version.
Paragraphs 13 through 15 were moved to Annex J, “Obsolescent Features”.
Static Semantics
15.1/5A pure program unit is a preelaborable program unit whose elaboration does not perform any of the following actions:
- the elaboration of a variable declaration;
- the evaluation of an
allocator
of an access-to-variable type; for the purposes of this rule, the partial view of a type is presumed to have nonvisible components whose default initialization evaluates such anallocator
;
allocator
would provide a backdoor way to get a global variable into a pure unit, so it is prohibited. Most such allocator
s are illegal anyway, as their type is required to have Storage_Size = 0 (see the next two rules). But access parameters and access discriminants don't necessarily disallow allocator
s. However, a call is also illegal here (by the preelaboration rules), so access parameters cannot cause trouble. So this rule is really about prohibiting allocators in discriminant constraints:type Rec (Acc : access Integer) is record
C : Character;
end record;
15.a.3/3Not_Const : constant Rec (Acc => new Integer'(2)); -- Illegal in a pure unit.
allocator
to initialize an access discriminant; the type still could have the Preelaborable_Initialization aspect specified . Ada 95 did not allow such private types to have preelaborable initialization, so such a default initialization could not have occurred. Thus this rule is not incompatible with Ada 95. - the elaboration of the declaration of a nonderived named access-to-variable type unless the Storage_Size of the type has been specified by a static expression with value zero or is defined by the language to be zero;
allocator
has a side effect; the pool constitutes variable data. We allow access-to-subprogram types because they don't have allocator
s. We even allow named access-to-object types if they have an empty predefined pool (they can't have a user-defined pool as System.Storage_Pools is not pure). In this case, most attempts to use an allocator
are illegal, and any others (in a generic body) will raise Storage_Error. - the elaboration of the declaration of a nonderived named access-to-constant type for which the Storage_Size has been specified by an expression other than a static expression with value zero;
- the elaboration of any program unit that is not pure.
A generic declaration is pure unless every instance would perform one of the above actions.
A generic body is pure only if elaboration of a corresponding instance body would not perform any such actions presuming any composite formal types have nonvisible components whose default initialization evaluates an allocator
of an access-to-variable type.
The Storage_Size for an anonymous access-to-variable type declared at library level in a library unit that is declared pure is defined to be zero.
Legality Rules
16/2This paragraph was deleted.
When the library unit aspect Pure of a program unit is True, the unit is said to be declared pure. When the Pure aspect is specified True for a library unit, all compilation units of the library unit are declared pure. In addition, the limited view of any library package is declared pure. The declaration and body of a declared pure library unit, and all subunits that are elaborated as part of elaborating the library unit, shall be pure. All compilation units of a declared pure library unit shall depend semantically only on declared pure library_item
s. In addition to the places where Legality Rules normally apply (see 12.3), these rules also apply in the private part of an instance of a generic unit. Furthermore, the full view of any partial view declared in the visible part of a declared pure library unit that has any available stream attributes shall support external streaming (see 13.13.2).
library_item
, so rules that discuss “declared pure library_item
s” do include limited views.Erroneous Execution
17.1/4Execution is erroneous if some operation (other than the initialization or finalization of the object) modifies the value of a constant object declared at library-level in a pure package.
Implementation Permissions
18/3If a library unit is declared pure, then the implementation is permitted to omit a call on a library-level subprogram of the library unit if the results are not needed after the call. In addition, the implementation may omit a call on such a subprogram and simply reuse the results produced by an earlier call on the same subprogram, provided that none of the parameters nor any object accessible via access values from the parameters have any part that is of a type whose full type is an immutably limited type, and the addresses and values of all by-reference actual parameters, the values of all by-copy-in actual parameters, and the values of all objects accessible via access values from the parameters, are the same as they were at the earlier call. [This permission applies even if the subprogram produces other side effects when called.]
library_item
has no variable state. Hence, a call on one of its (nonnested) subprograms cannot normally have side effects. Side effects are still possible via dispatching calls and via indirect calls through access-to-subprogram values. Other mechanisms that might be used to modify variable state include machine code insertions, imported subprograms, and unchecked conversion to an access type declared within the subprogram; this list is not exhaustive. Thus, the permissions described in this subclause may apply to a subprogram whose execution has side effects. The compiler may omit a call to such a subprogram even if side effects exist, so the writer of such a subprogram has to keep this in mind. Syntax
19/5The following pragma
s are defined with the given forms :
pragma Elaborate(library_unit_name
{, library_unit_name
});
pragma Elaborate_All(library_unit_name
{, library_unit_name
});
This paragraph was deleted.
A pragma
Elaborate or Elaborate_All is only allowed within a context_clause
.
context_clause
” allows it to be the last item in the context_clause
. It can't be first, because the name
has to denote something mentioned earlier. This paragraph was deleted.
pragma
Elaborate or Elaborate_All is not elaborated, not that it makes any practical difference.pragma
Elaborate or Elaborate_All is neither a program unit pragma, nor a library unit pragma.Legality Rules
25/5 If the aspect Elaborate_Body is True for a declaration , then the declaration requires a completion [(a body)].
The library_unit_name
of a pragma
Elaborate or Elaborate_All shall denote a nonlimited view of a library unit.
pragma
s are intended to prevent elaboration check failures. But a limited view does not make anything visible that has an elaboration check, so the pragma
s cannot do anything useful. Moreover, the pragma
s would probably reintroduce the circularity that the limited_with_clause
was intended to break. So we make such uses illegal. Static Semantics
26/3[A pragma
Elaborate specifies that the body of the named library unit is elaborated before the current library_item
. A pragma
Elaborate_All specifies that each library_item
that is needed by the named library unit declaration is elaborated before the current library_item
.]
[If the Elaborate_Body aspect of a library unit is True, the body of the library unit is elaborated immediately after its declaration.]
stub
s), then no Elaboration_Checks are needed for that subprogram. The same is true for Elaboration_Checks on task activations and instantiations, and for library subprograms and generic units. library_item
means that if a subprogram_body
is not a completion, it is impossible for any library_item
to be elaborated between the declaration and the body of such a subprogram. Therefore, it is impossible for a call to such a subprogram to fail its Elaboration_Check. name
of a pragma
Elaborate or Elaborate_All has to denote a library unit mentioned by a previous with_clause
of the same context_clause
. Extensions to Ada 83
pragma
s are new to Ada 95.context_clause
— in Ada 83, they were required to appear last. Incompatibilities With Ada 95
Extensions to Ada 95
pragma
Preelaborable_Initialization are new. These allow more types of objects to be created in preelaborable units, and fix holes in the old rules.Wording Changes from Ada 95
limited_with_clause
. Incompatibilities With Ada 2005
Extensions to Ada 2005
library_item
, but it is a compilation unit).aspect_specification
Wording Changes from Ada 2005
Incompatibilities With Ada 2012
Extensions to Ada 2012
pragma
Preelaborable_Initialization is now obsolescent.