10.2 Program Execution

danger

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/5

A 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 are determined as follows (unless specified otherwise via an implementation-defined pragma, or by some other implementation-defined means):

2.a

discussion

From a run-time point of view, an Ada 95 partition is identical to an Ada 83 program — implementations were always allowed to provide inter-program communication mechanisms. The additional semantics of partitions is that interfaces between them can be defined to obey normal language rules (as is done in Annex E, “Distributed Systems”), whereas interfaces between separate programs had no particular semantics.

2.b

implementation defined

The manner of explicitly assigning library units to a partition.

2.c

implementation defined

The implementation-defined means, if any, of specifying which compilation units are needed by a given compilation unit.

2.d

discussion

There are no pragmas that “specify otherwise” defined by the core language. However, an implementation is allowed to provide such pragmas, and in fact Annex E, “Distributed Systems” defines some pragmas whose semantics includes reducing the set of compilation units described here.

3 4

A compilation unit needs itself;

If a compilation unit is needed, then so are any compilation units upon which it depends semantically;

If a library_unit_declaration is needed, then so is any corresponding library_unit_body;

7/2

If a compilation unit with stubs is needed, then so are any corresponding subunits;

7.a

discussion

Note that in the environment, the stubs are replaced with the corresponding proper_bodies.

7.1/2

If the (implicit) declaration of the limited view of a library package is needed, then so is the explicit declaration of the library package.

7.b

discussion

Note that a child unit is not included just because its parent is included — to include a child, mention it in a with_clause.

7.c/2

note

A package is included in a partition even if the only reference to it is in a 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.

8.a

discussion

This may seem superfluous, since it follows from the definition. But we would like to have every error message that might be generated (before run time) by an implementation correspond to some explicitly stated “shall” rule.

8.b

note

Of course, this does not mean that the “shall” rules correspond one-to-one with an implementation's error messages. For example, the rule that says overload resolution “shall” succeed in producing a single interpretation would correspond to many error messages in a good implementation — the implementation would want to explain to the user exactly why overload resolution failed. This is especially true for the syntax rules — they are considered part of overload resolution, but in most cases, one would expect an error message based on the particular syntax rule that was violated.

8.c

implementation defined

The manner of designating the main subprogram of a partition.

8.d

ramification

An implementation cannot require the user to specify, say, all of the library units to be included. It has to support, for example, perhaps the most typical case, where the user specifies just one library unit, the main program. The implementation has to do the work of tracking down all the other ones.

Each partition has an anonymous environment task[, which is an implicit outermost task whose execution elaborates the library_items of the environment declarative_part, and then calls the main subprogram, if there is one. A partition's execution is that of its tasks.]

9.a

ramification

An environment task has no master; all nonenvironment tasks have masters.

9.b

note

An implementation is allowed to support multiple concurrent executions of the same partition.

[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 needed by the declaration of the other library unit.

10.a.1/2

discussion

{8652/0107} “Mentions” was used informally in the above rule; it was not intended to refer to the definition of mentions in 10.1.2. It was changed to “names” to make this clear.

10.a

note

See above for a definition of which library_items are “needed by” a given declaration.

10.b/5

note

Note that elaboration dependences are among library_items, 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;
13task 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;

13.a

ramification

The name of the environment task is written in italics here to indicate that this task is anonymous.

13.b

discussion

The model is different for a “passive partition” (see E.1). Either there is no environment task, or its 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_items consisting of copies of the library_items included in the partition[. The order of elaboration of library_items is the order in which they appear in the environment declarative_part]:

The order of all included library_items is such that there are no forward elaboration dependences.

15.a

ramification

This rule is written so that if a 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.

16/5

Any included library_unit_declaration for which aspect Elaborate_Body is True is immediately followed by its library_unit_body, if included.

16.a

discussion

This implies that the body of such a library unit shall not “with” any of its own children, or anything else that depends semantically upon the declaration of the library unit.

16.b/5

proof

All library_items declared pure occur before any that are not declared pure.

All preelaborated library_items occur before any that are not preelaborated.

18.a

discussion

Normally, if two partitions contain the same compilation unit, they each contain a separate copy of that compilation unit. See Annex E, “Distributed Systems” for cases where two partitions share the same copy of something.

18.b

note

There is no requirement that the main subprogram be elaborated last. In fact, it is possible to write a partition in which the main subprogram cannot be elaborated last.

18.c

ramification

This 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_items that obeys the above rules. The order is otherwise implementation defined.

19.a/5

discussion

The only way to violate this rule is to have Elaborate or Elaborate_All pragmas or Elaborate_Body aspects that cause circular ordering requirements, thus preventing an order that has no forward elaboration dependences.

19.b

implementation defined

The order of elaboration of library_items.

19.c/5

note

To be honest: Notwithstanding what the RM says elsewhere, each rule that requires a declaration to have a corresponding completion is considered to be a Post-Compilation Rule when the declaration is that of a library unit.

19.d

discussion

Such rules may be checked at “link time”, for example. Rules requiring the completion to have certain properties, on the other hand, are checked at compile time of the completion.

The full expanded names of the library units and subunits included in a given partition shall be distinct.

20.a

reason

This is a Post-Compilation Rule because making it a Legality Rule would violate the Language Design Principle labeled “legality determinable via semantic dependences”.

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.

22.a

implementation defined

Parameter passing and function return for the main subprogram.

or:

A null_statement, if there is no main subprogram.

24.a

discussion

For a passive partition, either there is no environment task, or its sequence_of_statements is an infinite loop. See E.1.

25/5

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.]

25.a

implementation defined

The mechanisms for building and running partitions.

Dynamic Semantics

The 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.]

26.a

ramification

The “further details” mentioned above include, for example, program termination — it is implementation defined. There is no need to define it here; it's entirely up to the implementation whether it wants to consider the program as a whole to exist beyond the existence of individual partitions.

26.b

implementation defined

The details of program execution, including program termination.

26.c

note

To be honest: The execution of the partition terminates (normally or abnormally) when the environment task terminates (normally or abnormally, respectively).

Bounded (Run-Time) Errors

Once 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

The 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.

28.a

discussion

The consistency requirement implies that a partition cannot contain two versions of the same compilation unit. That is, a partition cannot contain two different library units with the same full expanded name, nor two different bodies for the same program unit. For example, suppose we compile the following:

28.b

package A is -- Version 1.
    ...
end A;
28.cwith A;
package B is
end B;
28.dpackage A is -- Version 2.
    ...
end A;
28.ewith A;
package C is
end C;

28.f

note

It would be wrong for a partition containing B and C to contain both versions of A. Typically, the implementation would require the use of Version 2 of A, which might require the recompilation of B. Alternatively, the implementation might automatically recompile B when the partition is built. A third alternative would be an incremental compiler that, when Version 2 of A is compiled, automatically patches the object code for B to reflect the changes to A (if there are any relevant changes — there might not be any).

28.g

note

An implementation that supported fancy version management might allow the use of Version 1 in some circumstances. In no case can the implementation allow the use of both versions in the same partition (unless, of course, it can prove that the two versions are semantically identical).

28.h

note

The core language says nothing about inter-partition consistency; see also Annex E, “Distributed Systems”.

Implementation Permissions

29/3

The 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.

29.a

implementation defined

The semantics of any nonactive partitions supported by the implementation.

29.b

discussion

Annex E, “Distributed Systems” defines the concept of passive partitions; they may be thought of as a partition without an environment task, or as one with a particularly simple form of environment task, having an infinite loop rather than a call on a main subprogram as its 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.

30.a

ramification

The implementation is required to support main subprograms that are procedures declared by generic_instantiations, 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.

30.b

note

Note that renamings are irrelevant to this rule. This rules says which subprograms (not views) have to be supported. The implementation can choose any way it wants for the user to indicate which subprogram should be the main subprogram. An implementation might allow any name of any view, including those declared by renamings. Another implementation might require it to be the original name. Another implementation still might use the name of the source file or some such thing.

If the environment task completes abnormally, the implementation may abort any dependent tasks.

31.a

reason

If the implementation does not take advantage of this permission, the normal action takes place — the environment task awaits those tasks.

31.b

note

The possibility of aborting them is not shown in the Environment_Task code above, because there is nowhere to put an 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.

31.c

note

Furthermore, this is merely a permission, and is not fundamental to the model, so it is probably better to state it separately anyway.

31.d

note

Note that implementations (and tools like debuggers) can have modes that provide other behaviors in addition.

32/5

note

NOTE 1 An implementation can provide inter-partition communication mechanism(s) via special packages and pragmas. Standard pragmas for distribution and methods for specifying inter-partition communication are defined in Annex E, “Distributed Systems”. If no such mechanisms are provided, then each partition is isolated from all others, and behaves as a program in and of itself.

32.a

ramification

Not providing such mechanisms is equivalent to disallowing multi-partition programs.

32.b

note

An implementation may provide mechanisms to facilitate checking the consistency of library units elaborated in different partitions; Annex E, “Distributed Systems” does so.

33/5

note

NOTE 2 Partitions are not required to run in separate address spaces. For example, an implementation can support dynamic linking via the partition concept.

34/5

note

NOTE 3 An order of elaboration of library_items 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 subclause 10.2.1 are used.)

35/5

note

NOTE 4 A partition (active or otherwise) does not necessarily have a main subprogram. In such a case, all the work done by the partition would be done by elaboration of various library_items, and by tasks created by that elaboration. Passive partitions, which cannot have main subprograms, are defined in Annex E, “Distributed Systems”.

35.a

ramification

The environment task is the outermost semantic level defined by the language.

35.b

note

Standard has no private part. This prevents strange implementation-dependences involving private children of Standard having visibility upon Standard's private part. It doesn't matter where the body of Standard appears in the environment, since it doesn't do anything. See Annex A, “Predefined Language Environment”.

35.c

note

Note that elaboration dependence is carefully defined in such a way that if (say) the body of something doesn't exist yet, then there is no elaboration dependence upon the nonexistent body. (This follows from the fact that “needed by” is defined that way, and the elaboration dependences caused by a 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

35.d

note

The concept of partitions is new to Ada 95.

35.e

note

A main subprogram is now optional. The language-defined restrictions on main subprograms are relaxed.

Wording Changes from Ada 83

35.f

note

Ada 95 uses the term “main subprogram” instead of Ada 83's “main program” (which was inherited from Pascal). This is done to avoid confusion — a main subprogram is a subprogram, not a program. The program as a whole is an entirely different thing.

Wording Changes from Ada 95

35.g/2

note

The mistaken use of “mentions” in the elaboration dependence rule was fixed.

35.h/2

note

The needs relationship was extended to include limited views.

10.2.1 Elaboration Control

1/5

[ This subclause defines aspects and pragmas that help control the elaboration order of library_items.]

Language Design Principles

1.a

note

The rules governing preelaboration are designed to allow it to be done largely by bulk initialization of statically allocated storage from information in a “load module” created by a linker. Some implementations may require run-time code to be executed in some cases, but we consider these cases rare enough that we need not further complicate the rules.

1.b

note

It is important that programs be able to declare data structures that are link-time initialized with aggregates, string_literals, 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 aggregates or string_literals, 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.

1.c

note

The rules also ensure that no Elaboration_Check need be performed for calls on library-level subprograms declared within a preelaborated package. This is true also of the Elaboration_Check on task activation for library level task types declared in a preelaborated package. However, it is not true of the Elaboration_Check on instantiations.

1.d

note

A static expression should never prevent a library unit from being preelaborable.

Syntax

Paragraphs 2 through 4 were moved to Annex J, “Obsolescent Features”.

Legality Rules

An elaborable construct is preelaborable unless its elaboration performs any of the following actions:

5.a

ramification

A preelaborable construct can be elaborated without using any information that is available only at run time. Note that we don't try to prevent exceptions in preelaborable constructs; if the implementation wishes to generate code to raise an exception, that's OK.

5.b

note

Because there is no flow of control and there are no calls (other than to predefined subprograms), these run-time properties can actually be detected at compile time. This is necessary in order to require compile-time enforcement of the rules.

The execution of a statement other than a null_statement.

6.a

ramification

A preelaborable construct can contain labels and null_statements.

7/5

A call to a subprogram other than:

7.1/5

a static function;

7.2/5

an instance of Unchecked_Conversion (see 13.9);

7.3/5

a function declared in System.Storage_Elements (see 13.7.1); or

7.4/5

the functions To_Pointer and To_Address declared in an instance of System.Address_to_Access_Conversions (see 13.7.2).

7.a/5

ramification

The parameters of any such function have to pass the preelaborability rules, so they typically have to be static expressions. The extra allowed functions are all forms of conversion that the compiler understands, so there should be little implementation burden. Note that such a call might raise an exception; preelaborable is not the same as elaborable with no code.

The evaluation of a primary that is a name of an object, unless the name is a static expression, or statically denotes a discriminant of an enclosing type.

8.a

ramification

One can evaluate such a 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.

9/3

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 ancestor subtype_mark denoting a subtype of such a type.

9.a

ramification

One can declare these kinds of types, but one cannot create objects of those types.

9.b

note

It is also nonpreelaborable to create an object if that will cause the evaluation of a default expression that will call a user-defined function. This follows from the rule above forbidding nonnull statements.

9.c/2

note

This paragraph was deleted.

9.1/5

The elaboration of any elaborable construct that is not preelaborable.

9.2/5

A generic declaration is preelaborable unless every instance would perform one of the above actions.

9.d/5

ramification

A generic declaration is preelaborable unless there is no instance that could be declared preelaborated. For instance, a generic package declaration that directly contains a variable initialized by a non-static function that is not a formal function is not preelaborable (and thus would be illegal if the Preelaborate aspect were applied to it).

10/2

A generic body is preelaborable only if elaboration of a corresponding instance body would not perform any such actions, presuming that:

10.1/5

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;

10.2/2

the actual for each formal type is nonstatic;

10.3/2

the actual for each formal object is nonstatic; and

10.4/2

the actual for each formal subprogram is a user-defined subprogram.

10.a.1/2

discussion

This is an “assume-the-worst” rule. The elaboration of a generic unit doesn't perform any of the actions listed above, because its sole effect is to establish that the generic can from now on be instantiated. So the elaboration of the generic itself is not the interesting part when it comes to preelaboration rules. The interesting part is what happens when you elaborate “any instantiation” of the generic. For instance, declaring an object of a limited formal private type might well start tasks, call functions, and do all sorts of nonpreelaborable things. We prevent these situations by assuming that the actual parameters are as badly behaved as possible.

10.a

reason

Without this rule about generics, we would have to forbid instantiations in preelaborated library units, which would significantly reduce their usefulness.

11/5

{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_items. 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_items of the partition.]

11.a

ramification

In a generic body, we assume the worst about formal private types and extensions.

11.a.1/1

note

{8652/0035} Subunits of a preelaborated subprogram unit do not need to be preelaborable. This is needed in order to be consistent with units nested in a subprogram body, which do not need to be preelaborable even if the subprogram is preelaborated. However, such subunits cannot depend semantically on nonpreelaborated units, which is also consistent with nested units.

11.a.2/5

note

If a unit is not preelaborated, the value of the Preelaborate aspect for that unit is False.

11.b/3

note

Aspect Description for Preelaborate: Code execution during elaboration is avoided for a given package.

11.c/5

discussion

Rules for specifying a library unit aspect (like Preelaborate) are found in 13.1.1.

11.1/5

The following rules specify which entities have preelaborable initialization, namely that the Preelaborable_Initialization aspect of the entity is True:

11.2/5

The partial view of a private type or private extension, a protected type without entry_declarations, 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 with entry_declarations 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.

11.5/2

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.

11.6/5

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:

11.7/5

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.

11.d/5

ramification

“Formal types visible at the point of the declaration” includes all visible formal types, including those that might have been declared in formal packages or in child packages.

11.e/5

note

Aspect Description for Preelaborable_Initialization: Declares that a type has preelaborable initialization.

11.8/5

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_references, then the full view of the type shall have preelaborable initialization presuming the types mentioned in the prefixes of the attribute_references 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.

11.f/5

reason

The reason why we need to be allowed to specify the aspect for private types, private extensions, and protected types is fairly clear: the properties of the full view determine whether the type has preelaborable initialization or not; in order to preserve privacy we need a way to express on the partial view that the full view is well-behaved. The reason why we need to be allowed to specify the aspect for other composite types is more subtle: a nonnull override for Initialize might occur in the private part, even for a nonprivate type; in order to preserve privacy, we need a way to express on a type declared in a visible part that the private part does not contain any nasty override of Initialize.

11.9/5

11.g/5

ramification

Not only do protected types with entry_declarations and task types not have preelaborable initialization, but they cannot have Preelaborable_Initialization aspect specified True for them.

Implementation Advice

In 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.

12.a/2

implementation advice

A type declared in a preelaborated package should have the same representation in every elaboration of a given version of the package.

13/5

14/5

15/5

Paragraphs 13 through 15 were moved to Annex J, “Obsolescent Features”.

Static Semantics

15.1/5

A pure program unit is a preelaborable program unit whose elaboration does not perform any of the following actions:

15.2/2

the elaboration of a variable declaration;

15.3/2

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 an allocator;

15.a.1/3

reason

Such an allocator would provide a backdoor way to get a global variable into a pure unit, so it is prohibited. Most such allocators 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 allocators. 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:

15.a.2/3

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.

15.a/5

note

The second half of the rule is needed because aggregates can specify the default initialization of a private type or extension using <> or the ancestor subtype of an extension aggregate. The subtype of a component could use an 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.

15.4/3

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;

15.b/2

discussion

A remote access-to-class-wide type (see E.2.2) has its Storage_Size defined to be zero.

15.c/2

reason

We disallow most named access-to-object types because an allocator has a side effect; the pool constitutes variable data. We allow access-to-subprogram types because they don't have allocators. 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.

15.5/5

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;

15.d/2

discussion

We allow access-to-constant types so long as there is no user-specified nonzero Storage_Size; if there were a user-specified nonzero Storage_Size restricting the size of the storage pool, allocators would be problematic since the package is supposedly ‘stateless’, and the allocated size count for the storage pool would represent state.

15.6/5

the elaboration of any program unit that is not pure.

15.7/5

A generic declaration is pure unless every instance would perform one of the above actions.

15.d.1/5

ramification

A generic declaration is pure unless there is no instance that could be declared pure. For instance, a generic package declaration that directly contains a variable declaration is not pure (and thus would be illegal if aspect Pure is specified for it).

15.8/5

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.

15.9/5

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.

15.e/2

ramification

This makes allocators illegal for such types (see 4.8), making a storage pool unnecessary for these types. A storage pool would represent state.

15.f/2

note

Note that access discriminants and access parameters are never library-level, even when they are declared in a type or subprogram declared at library-level. That's because they have their own special accessibility rules (see 3.10.2).

Legality Rules

16/2

This paragraph was deleted.

17/5

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_items. 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).

17.a/3

note

This paragraph was deleted.

17.b

discussion

A declared-pure package is useful for defining types to be shared between partitions with no common address space.

17.c

reason

Note that generic packages are not mentioned in the list of things that can contain variable declarations. Note that the Ada 95 rules for deferred constants make them allowable in library units that are declared pure; that isn't true of Ada 83's deferred constants.

17.d/2

ramification

Anonymous access types are allowed.

17.d.1/3

note

A limited view is not a library unit, so any rule that starts “declared pure library unit” does not apply to a limited view. In particular, the 3rd and last sentences never apply to limited views. However, a limited view is a library_item, so rules that discuss “declared pure library_items” do include limited views.

17.d.2/5

note

If a unit is not declared pure, the value of the Pure aspect for that unit is False.

17.e/2

reason

Ada 95 didn't allow any access types as these (including access-to-subprogram types) cause trouble for Annex E, “Distributed Systems”, because such types allow access values in a shared passive partition to designate objects in an active partition, thus allowing inter-address space references. We decided to disallow such uses in the relatively rare cases where they cause problems, rather than making life harder for the majority of users. Types declared in a pure package can be used in remote operations only if they are externally streamable. That simply means that there is a means to transport values of the type; that's automatically true for nonlimited types that don't have an access part. The only tricky part about this is to avoid privacy leakage; that was handled by ensuring that any private types (and private extensions) declared in a pure package that have available stream attributes (which include all nonlimited types by definition) have to be externally streamable.

17.f/3

note

Aspect Description for Pure: Side effects are avoided in the subprograms of a given package.

Erroneous Execution

17.1/4

Execution 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.

17.g/4

discussion

This could be accomplished via a self-referencing pointer or via squirrelling a writable pointer to a controlled object.

Implementation Permissions

18/3

If 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.]

18.a/3

discussion

A declared-pure 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/5

The following pragmas are defined with the given forms :

pragma Elaborate(library_unit_name{, library_unit_name});

pragma Elaborate_All(library_unit_name{, library_unit_name});

22/5

This paragraph was deleted.

A pragma Elaborate or Elaborate_All is only allowed within a context_clause.

23.a

ramification

“Within a 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.

24/5

This paragraph was deleted.

24.a

discussion

Hence, a pragma Elaborate or Elaborate_All is not elaborated, not that it makes any practical difference.

24.b

note

Note that a 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)].

25.a/5

proof

25.1/2

The library_unit_name of a pragma Elaborate or Elaborate_All shall denote a nonlimited view of a library unit.

25.b/2

reason

These pragmas are intended to prevent elaboration check failures. But a limited view does not make anything visible that has an elaboration check, so the pragmas cannot do anything useful. Moreover, the pragmas 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.]

26.a

proof

The official statement of the semantics of these pragmas is given in 10.2.

26.1/5

[If the Elaborate_Body aspect of a library unit is True, the body of the library unit is elaborated immediately after its declaration.]

26.a.1/3

proof

The official statement of the semantics of this aspect is given in 10.2.

26.b/5

implementation note

The specification of the Elaborate_Body aspect simplifies the removal of unnecessary Elaboration_Checks. For a subprogram declared immediately within a library unit for which the Elaborate_Body aspect is specified as True , the only calls that can fail the Elaboration_Check are those that occur in the library unit itself, between the declaration and body of the called subprogram; if there are no such calls (which can easily be detected at compile time if there are no stubs), 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.

26.c

ramification

The fact that the unit of elaboration is the 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.

26.d

discussion

The visibility rules imply that each library_unit_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.

26.e/5

note

Aspect Description for Elaborate_Body: A given package will have a body, and that body is elaborated immediately after the declaration.

note

NOTE 1 A preelaborated library unit is allowed to have nonpreelaborable children.

27.a/1

ramification

{8652/0035} But generally not nonpreelaborated subunits. (Nonpreelaborated subunits of subprograms are allowed as discussed above.)

note

NOTE 2 A library unit that is declared pure is allowed to have impure children.

28.a/1

ramification

{8652/0035} But generally not impure subunits. (Impure subunits of subprograms are allowed as discussed above.)

28.b

ramification

Pragma Elaborate is mainly for closely related library units, such as when two package bodies 'with' each other's declarations. In such cases, Elaborate_All sometimes won't work.

Extensions to Ada 83

28.c

note

The concepts of preelaborability and purity are new to Ada 95. The Elaborate_All, Elaborate_Body, Preelaborate, and Pure pragmas are new to Ada 95.

28.d

note

Pragmas Elaborate are allowed to be mixed in with the other things in the context_clause — in Ada 83, they were required to appear last.

Incompatibilities With Ada 95

28.e/2

note

The requirement that a partial view with available stream attributes be externally streamable can cause an incompatibility in rare cases. If there is a limited tagged type declared in a pure package with available attributes, and that type is used to declare a private extension in another pure package, and the full type for the private extension has a component of an explicitly limited record type, a protected type, or a type with access discriminants, then the stream attributes will have to be user-specified in the visible part of the package. That is not a requirement for Ada 95, but this combination seems very unlikely in pure packages. Note that this cannot be an incompatibility for a nonlimited type, as all of the types that are allowed in Ada 95 that would require explicitly defined stream attributes are limited (and thus cannot be used as components in a nonlimited type).

28.f/2

correction

Amendment Added wording to cover missing cases for preelaborated generic units. This is incompatible as a preelaborated unit could have used a formal object to initialize a library-level object; that isn't allowed in Ada 2005. But such a unit wouldn't really be preelaborable, and Ada 95 compilers can reject such units (as this is a Binding Interpretation), so such units should be very rare.

Extensions to Ada 95

28.g/2

correction

Amendment The concept of preelaborable initialization and pragma Preelaborable_Initialization are new. These allow more types of objects to be created in preelaborable units, and fix holes in the old rules.

28.h/2

note

Access-to-subprogram types and access-to-object types with a Storage_Size of 0 are allowed in pure units. The permission to omit calls was adjusted accordingly (which also fixes a hole in Ada 95, as access parameters are allowed, and changes in the values accessed by them must be taken into account).

Wording Changes from Ada 95

28.i/2

note

Corrigendum: The wording was changed so that subunits of a preelaborated subprogram are also preelaborated.

28.j/2

note

Disallowed pragma Elaborate and Elaborate_All for packages that are mentioned in a limited_with_clause.

Incompatibilities With Ada 2005

28.k/3

correction

Corrected a serious unintended incompatibility with Ada 95 in the new preelaboration wording — explicit initialization of objects of types that don't have preelaborable initialization was not allowed. Ada 2012 switches back to the Ada 95 rule in these cases. This is unlikely to occur in practice, as it is unlikely that a compiler would have implemented the more restrictive rule (it would fail many ACATS tests if it did).

28.l/3

correction

Added an assume-the-worst rule for generic bodies (else they would never be checked for purity) and added the boilerplate so that the entire generic specification is rechecked. Also fixed wording to have consistent handling for subunits for Pure and Preelaborate. An Ada 95 program could have depended on marking a generic pure that was not really pure, although this would defeat the purpose of the categorization and likely cause problems with distributed programs.

Extensions to Ada 2005

28.m/3

correction

Adjusted wording so that a subunit can be pure (it is not a library_item, but it is a compilation unit).

28.n/3

correction

Adjusted wording so that the rules for access types only apply to nonderived types (derived types share their storage pool with their parent, so if the parent access type is legal, so is any derived type.)

28.o/5

note

Elaborate_Body is now an aspect, so it can be specified by an aspect_specification

28.p/5

note

Pure and Preelaborate are now aspects, so they can be specified by an aspect_specification

Wording Changes from Ada 2005

28.q/3

correction

Added wording so that a limited view is always treated as pure, no matter what categorization is used for the originating unit. This was undefined in Ada 2005.

28.r/3

correction

Fixed minor issues with preelaborable initialization (PI): null Initialize procedures do not make a type non-PI; formal types with pragma PI can be assumed to have PI; formal extensions are assumed to not have PI; all composite types can have pragma PI (so that the possibility of hidden Initialize routines can be handled); added discriminants of a derived type are not considered in calculating PI.

28.s/3

correction

Clarified that the implementation permission to omit pure subprogram calls does not apply if any part of the parameters or any designated object has a part that is immutably limited. The old wording just said "limited type", which can change via visibility and thus isn't appropriate for dynamic semantics permissions.

Incompatibilities With Ada 2012

28.t/5

correction

Added a rule that a generic declaration is not pure if no instance could be pure (for instance, because the generic declaration would elaborates a variable.) This was legal in Ada 2012, but of course no instance could have been declared pure. A similar rule (with a similar effect) was added for preelaborable generic declarations.

Extensions to Ada 2012

28.u/5

note

Added some intrinsic conversion functions to those allowed to be called during the elaboration of a preelaborated unit. This is necessary to allow a portable Address aspect in a preelaborated unit, important on small embedded systems.

28.v/5

note

Aspect Preelaborable_Initialization is new; pragma Preelaborable_Initialization is now obsolescent.

Wording Changes from Ada 2012

28.w/4

note

Corrigendum: Explicitly stated that modifying a library-level constant in a pure package is erroneous. We don't document this as inconsistent as implementations certainly can still do whatever they were previously doing (no change is required); moreover, this case (and many more) were erroneous in Ada 2005 and before, so we're just restoring the previous semantics.

28.x/5

correction

Explicitly stated that the pure and preelaborate rules are recursive; that is, they apply to the contents of nested packages and generic packages.

28.y/5

note

The pragmas that set aspects (Pure, Preelaborate, Elaborate_Body) are now obsolescent.

10.2 Program Execution

Post-Compilation Rules​

Dynamic Semantics​

Bounded (Run-Time) Errors​

Implementation Requirements​

Implementation Permissions​

Extensions to Ada 83​

Wording Changes from Ada 83​

Wording Changes from Ada 95​

10.2.1 Elaboration Control​

Language Design Principles​

Syntax​

Legality Rules​

Implementation Advice​

Static Semantics​

Legality Rules​

Erroneous Execution​

Implementation Permissions​

Syntax​

Legality Rules​

Static Semantics​

Extensions to Ada 83​

Incompatibilities With Ada 95​

Extensions to Ada 95​

Wording Changes from Ada 95​

Incompatibilities With Ada 2005​

Extensions to Ada 2005​

Wording Changes from Ada 2005​

Incompatibilities With Ada 2012​

Extensions to Ada 2012​

Wording Changes from Ada 2012​

Post-Compilation Rules

Dynamic Semantics

Bounded (Run-Time) Errors

Implementation Requirements

Implementation Permissions

Extensions to Ada 83

Wording Changes from Ada 83

Wording Changes from Ada 95

10.2.1 Elaboration Control

Language Design Principles

Syntax

Legality Rules

Implementation Advice

Static Semantics

Legality Rules

Erroneous Execution

Implementation Permissions

Syntax

Legality Rules

Static Semantics

Extensions to Ada 83

Incompatibilities With Ada 95

Extensions to Ada 95

Wording Changes from Ada 95

Incompatibilities With Ada 2005

Extensions to Ada 2005

Wording Changes from Ada 2005

Incompatibilities With Ada 2012

Extensions to Ada 2012

Wording Changes from Ada 2012