10.2.1 Elaboration Control
This subclause defines pragmas
that help control the elaboration order of library_item
Language Design Principles
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.
It is important that programs be able to declare
data structures that are link-time initialized with aggregate
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
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.
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.
A static expression should never prevent a library
unit from being preelaborable.
The form of a pragma
Preelaborate is as follows:
Preelaborate is a library unit pragma.
elaborable construct is preelaborable unless its elaboration performs
any of the following actions:
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.
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.
A call to a subprogram other than a static function.
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
One can evaluate such a
not as a primary
For example, one can evaluate an attribute of the object. One can evaluate
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 of
a type that
does not have preelaborable initialization.
Similarly, a default-initialized object
[(including a component)] of a descendant of a private type, private
extension, controlled type, task type, or protected type with entry_declarations;
the evaluation of an extension_aggregate
with an ancestor subtype_mark
denoting a subtype of such a type.
Ramification: One can declare these kinds
of types, but one cannot create objects of those types.
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
Controlled objects are disallowed because most
implementations will have to take some run-time action during initialization,
even if the Initialize procedure is null.
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
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 private
type (or extension) that does not have
preelaborable initialization, unless pragma
Preelaborable_Initialization has been applied to the formal type;
the actual for each formal object is nonstatic;
the actual for each formal subprogram is a user-defined
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 non-preelaborable things. We prevent these situations by assuming
that the actual parameters are as badly behaved as possible.
Reason: Without this rule about generics,
we would have to forbid instantiations in preelaborated library units,
which would significantly reduce their usefulness.
Preelaborate (or pragma
Pure — see below) is used to specify that applies
a library unit, then it
namely that the Preelaborate aspect
of the library unit is True; all compilation units of the library unit
. [ 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. 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
rules also apply this rule applies also
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 non-preelaborated
of the partition.] In addition, all compilation
units of a preelaborated library unit shall depend semantically only
on compilation units of other preelaborated library units.
Ramification: In a generic body, we assume
the worst about formal private types and extensions.
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.
for Preelaborate: Code
execution during elaboration is avoided for a given package.
The following rules specify
which entities have preelaborable initialization:
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 have preelaborable initialization if and only if the pragma
Preelaborable_Initialization has been applied to them. [A protected type
or a task type never has preelaborable initialization.]
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.
A derived type has preelaborable initialization
if its parent type has preelaborable initialization and (in
the case of a derived record extension) if
the non-inherited components all have preelaborable initialization. However,
a user-defined controlled
type with an overriding
Initialize procedure that
is not a null procedure does not have preelaborable
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.
Preelaborable_Initialization specifies that a type has preelaborable
initialization. This pragma shall appear in the visible part of a package
or generic package.
If the pragma appears in the first list of basic_declarative_items
of a package_specification,
then the direct_name
shall denote the first subtype of a composite private type, private extension,
or protected type that is not an interface type and is without entry_declarations,
and the type shall be declared immediately within the same package as
If the pragma
is applied to a private type or a private extension, the full view of
the type shall have preelaborable initialization. If the pragma
is applied to a protected type, the protected
type shall not have entries, and each component
of the protected type shall have preelaborable initialization. For
any other composite type, the type shall have preelaborable initialization.
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
The reason why we need the pragma 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
the pragma for other composite types is more subtle: a non-null 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.
only do protected types with entry_declarations
and task types not have preelaborable initialization, but they cannot
have pragma Preelaborable_Initialization applied to them.
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.
A type declared in a preelaborated package
should have the same representation in every elaboration of a given version
of the package.
The form of a pragma
Pure is as follows:
Pure is a library unit pragma.
the elaboration of a variable
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 non-visible components whose default
initialization evaluates such an allocator;
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:
type Rec (Acc : access Integer) is record
C : Character;
Not_Const : constant Rec (Acc => new Integer'(2)); -- Illegal in a pure unit.
The second half of
the This 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 a pragma
Preelaborable_Initialization given. 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
the elaboration of the declaration of a non-derived
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;
Discussion: A remote
access-to-class-wide type (see E.2.2) has
its Storage_Size defined to be zero.
We disallow most named access-to-object types because
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.
the elaboration of the declaration of a non-derived
named access-to-constant type for which
the Storage_Size has been specified by an expression other than a static
expression with value zero.
allow access-to-constant types so long as there is no user-specified
non-zero Storage_Size; if there were a user-specified non-zero 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.
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 non-visible 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.
illegal for such types (see 4.8), making a
storage pool unnecessary for these types. A storage pool would represent
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).
This paragraph was
A pure library_item
is a preelaborable library_item
that does not contain the declaration of any variable or named access
within a subprogram, generic subprogram, task unit, or protected unit.
Pure is used to specify declare
that a library unit is declared pure, namely
that the Pure aspect of the library
unit is True; 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 If
a pragma Pure
applies to a library unit, then its
compilation units of
a declared pure library unit shall be pure,
shall depend semantically only on compilation
units of other library units that are
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 the library unit that has any available stream attributes shall support external
streaming (see 13.13.2).
was deleted.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.
Discussion: A declared-pure package is
useful for defining types to be shared between partitions with no common
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
Anonymous access types (that is, access discriminants
and access parameters)
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.
Ada 95 didn't allow any access types as 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)
cause trouble for Annex
, “Distributed Systems
such types would
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. 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
would have to be a run-time check, in order to avoid violations of the
generic contract model.
for Pure: Side
effects are avoided in the subprograms of a given package.
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 Similarly, it
may omit such
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 are
limited type, and the addresses and values of all by-reference
actual parameters, and
the values of all
by-copy-in actual parameters, and the values of
all objects accessible via access values from the parameters,
the same as they were at the earlier call. [This permission applies even
if the subprogram produces other side effects when called.]
A declared-pure library_item
has no variable state. Hence, a call on one of its (nonnested) subprograms
cannot normally “normally”
have side effects. The only possible side effects from such a call would
be through machine code insertions, imported subprograms,
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
The form of a pragma
Elaborate, Elaborate_All, or Elaborate_Body is as follows:
“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.
Elaborate_Body is a library unit pragma.
Hence, a pragma
Elaborate or Elaborate_All is not elaborated, not that it makes any practical
Note that a pragma
Elaborate or Elaborate_All is neither a program unit pragma, nor a library
If the aspect a
Elaborate_Body is True for applies
a declaration [(including when pragma
, then the declaration requires a completion
of a pragma
Elaborate or Elaborate_All shall denote a nonlimited view of a library
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
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.
Elaborate specifies that the body of the named library unit is elaborated
before the current library_item
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.
The official statement of the
semantics of these pragma
is given in 10.2
Elaborate_Body sets the Elaborate_Body representation aspect of the library
unit to which it applies to the value True. [If the Elaborate_Body aspect
of a library unit is True, the body of the library unit is elaborated
immediately after its declaration.]
Proof: The official
statement of the semantics of this aspect is given in 10.2.
The presence of
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 stub
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.
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
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
for Elaborate_Body: A
given package must have a body, and that body is elaborated immediately
after the declaration.
12 A preelaborated library unit is allowed
to have non-preelaborable children.
not non-preelaborated subunits.
(Non-preelaborated subunits of subprograms are
allowed as discussed above.)
13 A library unit that is declared pure
is allowed to have impure children.
not impure subunits. (Impure
subunits of subprograms are allowed as discussed above.)
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
Extensions to Ada 83
The concepts of preelaborability
and purity are new to Ada 95. The Elaborate_All, Elaborate_Body, Preelaborate,
and Pure pragma
are new to Ada 95.
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
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).
Amendment Correction: 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
Extensions to Ada 95
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.
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
Corrigendum: The wording was changed so
that subunits of a preelaborated subprogram are also preelaborated.
Incompatibilities With Ada 2005
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).
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
Extensions to Ada 2005
wording so that a subunit can be pure (it is not a library_item,
but it is a compilation unit).
Correction: Adjusted wording so that the
rules for access types only apply to non-derived types (derived types
share their storage pool with their parent, so if the parent access type
is legal, so is any derived type.)
Pure and Preelaborate are now aspects, so they
can be specified by an aspect_specification
— although the pragmas are still preferred by the Standard.
Wording Changes from Ada 2005
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.
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.
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
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe