Contents   Index   Previous   Next

10.2.1 Elaboration Control

1
   [{elaboration control} This subclause defines pragmas that help control the elaboration order of library_items.]

Language Design Principles

1.a
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
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
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
A static expression should never prevent a library unit from being preelaborable.

Syntax

2
The form of a pragma Preelaborate is as follows:
3
  pragma Preelaborate[(library_unit_name)];
4
{library unit pragma (Preelaborate) [partial]} {pragma, library unit (Preelaborate) [partial]} A pragma Preelaborate is a library unit pragma.

Legality Rules

5
   {preelaborable (of an elaborable construct) [distributed]} 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
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.
6
6.a
Ramification: A preelaborable construct can contain labels and null_statements.
7
8
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
9.a
Ramification: One can declare these kinds of types, but one cannot create objects of those types.
9.b
It is also non-preelaborable 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 non-null statements.
9.c
Reason: Controlled objects are disallowed because most implementations will have to take some run-time action during initialization, even if the Initialize procedure is null.
10
    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 formal private type (or extension) is a private type (or extension), and the actual for each formal subprogram is a user-defined subprogram. {generic contract issue}
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/1
      {8652/0035} {preelaborated [partial]} If a pragma Preelaborate (or pragma Pure -- see below) applies to a library unit, then it is preelaborated. [ {preelaborated [distributed]} If a library unit is preelaborated, then its declaration, if any, and body, if any, are elaborated prior to all non-preelaborated library_items of the partition.] The declaration and body of a preelaborated library unit, and all subunits that are elaborated as part of elaborating the library unit,All compilation units of a preelaborated library unit shall be preelaborable. {generic contract issue [partial]} In addition to the places where Legality Rules normally apply (see 12.3), this rule applies also in the private part of an instance of a generic unit. In addition, all compilation units of a preelaborated library unit shall depend semantically only on compilation units of other preelaborated library units.
11.a
Ramification: In a generic body, we assume the worst about formal private types and extensions.
11.a.1/1
{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 non-preelaborated units, which is also consistent with nested units.

Implementation Advice

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

Syntax

13
The form of a pragma Pure is as follows:
14
  pragma Pure[(library_unit_name)];
15
{library unit pragma (Pure) [partial]} {pragma, library unit (Pure) [partial]} A pragma Pure is a library unit pragma.

Legality Rules

16
    {pure} A pure library_item is a preelaborable library_item that does not contain the declaration of any variable or named access type, except within a subprogram, generic subprogram, task unit, or protected unit.
17
    {declared pure} A pragma Pure is used to declare that a library unit is pure. If a pragma Pure applies to a library unit, then its compilation units shall be pure, and they shall depend semantically only on compilation units of other library units that are declared pure.
17.a
To be honest: A declared-pure library unit is one to which a pragma Pure applies. Its declaration and body are also said to be declared pure.
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
Ramification: Anonymous access types (that is, access discriminants and access parameters) are allowed.
17.e
Reason: The primary reason for disallowing named access types is that an allocator has a side effect; the pool constitutes variable data. We considered somehow allowing allocator-less access types. However, these (including access-to-subprogram types) would cause trouble for Annex E, ``Distributed Systems'', because such types would allow access values in a shared passive partition to designate objects in an active partition, thus allowing inter-address space references. Furthermore, a named access-to-object type without a pool would be a new concept, adding complexity from the user's point of view. Finally, the prevention of allocators would have to be a run-time check, in order to avoid violations of the generic contract model.

Implementation Permissions

18
    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. Similarly, it may omit such a call and simply reuse the results produced by an earlier call on the same subprogram, provided that none of the parameters are of a limited type, and the addresses and values of all by-reference actual parameters, and the values of all by-copy-in actual 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
Discussion: A declared-pure library_item has no variable state. Hence, a call on one of its (nonnested) subprograms cannot ``normally'' have side effects. The only possible side effects from such a call would be through machine code insertions, unchecked conversion to an access type declared within the subprogram, and similar features. The compiler may omit a call to such a subprogram even if such side effects exist, so the writer of such a subprogram has to keep this in mind.

Syntax

19
The form of a pragma Elaborate, Elaborate_All, or Elaborate_Body is as follows:
20
  pragma Elaborate(library_unit_name{, library_unit_name});
21
  pragma Elaborate_All(library_unit_name{, library_unit_name});
22
  pragma Elaborate_Body[(library_unit_name)];
23
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
{library unit pragma (Elaborate_Body) [partial]} {pragma, library unit (Elaborate_Body) [partial]} A pragma Elaborate_Body is a library unit pragma.
24.a
Discussion: Hence, a pragma Elaborate or Elaborate_All is not elaborated, not that it makes any practical difference.
24.b
Note that a pragma Elaborate or Elaborate_All is neither a program unit pragma, nor a library unit pragma.

Legality Rules

25
    {requires a completion (declaration to which a pragma Elaborate_Body applies) [partial]} If a pragma Elaborate_Body applies to a declaration, then the declaration requires a completion [(a body)].

Static Semantics

26
    [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. A pragma Elaborate_Body specifies that the body of the library unit is elaborated immediately after its declaration.]
26.a
Proof: The official statement of the semantics of these pragmas is given in 10.2.
26.b
Implementation Note: The presence of a pragma Elaborate_Body simplifies the removal of unnecessary Elaboration_Checks. For a subprogram declared immediately within a library unit to which a pragma Elaborate_Body applies, 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.
NOTES
27
12  A preelaborated library unit is allowed to have non-preelaborable children.
27.a/1
Ramification: {8652/0035} But generally not non-preelaborated subunits. (Non-preelaborated subunits of subprograms are allowed as discussed above.)
28
13  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
{extensions to Ada 83} 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
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.

Contents   Index   Previous   Next   Legal