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.
4.1/2
{
AI95-00161-01}
The form of a pragma
Preelaborable_Initialization is as follows: 4.2/2
pragma
Preelaborable_Initialization(direct_name);
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
- The execution of a statement
other than a null_statement.
6.a
Ramification: A preelaborable construct
can contain labels and null_statements.
7
- A call to a subprogram other than
a static function.
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.
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/2
- {AI95-00161-01}
The creation of an object [(including a component)]
of a type that does not have preelaborable initialization. Similarly, 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; 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
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/2
This paragraph
was deleted.Reason: {
AI95-00161-01}
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/2
{
AI95-00403-01}
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.1/2
- {AI95-00403-01}
the actual for each formal private type (or extension)
declared within the formal part of the generic unit is a private type
(or extension) that does not have preelaborable initialization;
10.2/2
10.3/2
- {AI95-00403-01}
the actual for each formal object is nonstatic;
and
10.4/2
- {AI95-00403-01}
the actual for each formal subprogram is a user-defined
subprogram.
10.a.1/2
Discussion: {
AI95-00403-01}
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.
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}
{
AI95-00002-01}
{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}
{
AI95-00002-01}
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. 11.1/2
{
AI95-00161-01}
{preelaborable
initialization} The following rules specify
which entities have preelaborable initialization:11.2/2
- 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, have preelaborable initialization
if and only if the pragma Preelaborable_Initialization
has been applied to them. [A protected type with entry_declarations
or a task type never 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/2
- 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
does not have preelaborable initialization.
11.5/2
- {AI95-00161-01}
{AI95-00345-01}
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/2
{
AI95-00161-01}
A pragma Preelaborable_Initialization
specifies that a type has preelaborable initialization. This pragma shall
appear in the visible part of a package or generic package.11.7/2
{
AI95-00161-01}
{
AI95-00345-01}
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 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
the pragma. 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, each component of the protected type
shall have preelaborable initialization. In addition to the places where
Legality Rules normally apply, these rules apply also in the private
part of an instance of a generic unit.11.8/2
{
AI95-00161-01}
If the pragma appears
in a generic_formal_part, then the direct_name
shall denote a generic formal private type or a generic formal derived
type declared in the same generic_formal_part
as the pragma. In a generic_instantiation
the corresponding actual type shall have preelaborable initialization.11.b/2
Ramification: Not
only do protected types with entry_declarations
and task types not have preelaborable initialization, but they cannot
have pragma Preelaborable_Initialization applied to them.
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.
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.
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.
Static Semantics
15.1/2
{
AI95-00366-01}
{pure}
A pure library_item
is a preelaborable library_item 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 non-visible components whose default initialization evaluates
such an allocator;
15.a/2
Reason: 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. Ada 95 did not allow such private
types to have preelaborable initialization, so they could not have occurred.
Thus this rule is not incompatible with Ada 95.
15.4/2
- the elaboration
of the declaration of a 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: {
AI95-00366-01}
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/2
- the elaboration
of the declaration of a 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
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.
15.6/2
{
AI95-00366-01}
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 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.{
AI95-00366-01}
{pure}
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.
17/2
{
AI95-00366-01}
{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.
Furthermore, the full view
of any partial view declared in the visible part of the library unit
that has any available stream attributes shall support external streaming
(see 13.13.2). 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/2
Ramification: {
AI95-00366-01}
Anonymous access types
(that is, access discriminants
and access parameters) are allowed.
17.e/2
Reason: {
AI95-00366-01}
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)
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.
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
of allocators would have to be a run-time
check, in order to avoid violations of the generic contract model.
Implementation Permissions
18/2
{
AI95-00366-01}
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 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,
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/2
Discussion: {
AI95-00366-01}
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, 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)].
25.1/2
{
AI95-00217-06}
The library_unit_name
of a pragma Elaborate or Elaborate_All shall
denote a nonlimited view of a library unit. 25.a/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
[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.
27
12 A preelaborated library unit is allowed
to have non-preelaborable children.
27.a/1
Ramification: {
8652/0035}
{
AI95-00002-01}
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}
{
AI95-00002-01}
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.
Incompatibilities With Ada 95
28.e/2
{
AI95-00366-01}
{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).28.f/2
{
AI95-00403-01}
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
very rare. Extensions to Ada 95
28.g/2
{
AI95-00161-01}
{extensions to Ada 95} Amendment
Correction: 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
{
AI95-00366-01}
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
{
AI95-00002-01}
Corrigendum: The wording was changed so
that subunits of a preelaborated subprogram are also preelaborated.28.j/2
{
AI95-00217-06}
Disallowed pragma Elaborate and Elaborate_All for
packages that are mentioned in a limited_with_clause.
Sponsored by Ada-Europe