Ada Reference Manual (Ada 2022) — Legal Information
Contents   Index   References   Search   Previous   Next 

10.2.1 Elaboration Control

1/5
This subclause defines aspects and pragmas that help control the elaboration order of library_items.
Paragraphs 2 through 4 were moved to Annex J, “Obsolescent Features”. 

Legality Rules

5
An elaborable construct is preelaborable unless its elaboration performs any of the following actions: 
6
The execution of a statement other than a null_statement.
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). 
8
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. 
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.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.
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. 
11/5
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.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.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.

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

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

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.

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. 

Syntax

19/5
The following pragmas are defined with the given forms: 
20
  pragma Elaborate(library_unit_name{, library_unit_name});
21
  pragma Elaborate_All(library_unit_name{, library_unit_name});
22/5
This paragraph was deleted.
23
A pragma Elaborate or Elaborate_All is only allowed within a context_clause.
24/5
This paragraph was deleted.

Legality Rules

25/5
If the aspect Elaborate_Body is True for a declaration, then the declaration requires a completion (a body).
25.1/2
  The library_unit_name of a pragma Elaborate or Elaborate_All shall denote a nonlimited view of a library unit. 

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.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.
27/5
NOTE 1   A preelaborated library unit can have nonpreelaborable children. 
28/5
NOTE 2   A library unit that is declared pure can have impure children. 
Contents   Index   References   Search   Previous   Next 
Ada-Europe Ada 2005 and 2012 Editions sponsored in part by Ada-Europe