13.14 Freezing Rules
[This subclause defines a place in the program text where each declared
entity becomes “frozen.” A use of an entity, such as a reference
to it by name, or (for a type) an expression of the type, causes freezing
of the entity in some contexts, as described below. The Legality Rules
forbid certain kinds of uses of an entity in the region of text where
it is frozen.]
Reason: This concept has two purposes:
a compile-time one and a run-time one.
The compile-time purpose of the freezing rules
comes from the fact that the evaluation of static expressions depends
on overload resolution, and overload resolution sometimes depends on
the value of a static expression. (The dependence of static evaluation
upon overload resolution is obvious. The dependence in the other direction
is more subtle. There are three rules that require static expressions
in contexts that can appear in declarative places: The expression in
shall be static. In a record aggregate, variant-controlling discriminants
shall be static. In an array aggregate with more than one named association,
the choices shall be static. The compiler needs to know the value of
these expressions in order to perform overload resolution and legality
checking.) We wish to allow a compiler to evaluate static expressions
when it sees them in a single pass over the compilation_unit
The freezing rules ensure that.
The run-time purpose of the freezing rules is
called the “linear elaboration model.” This means that declarations
are elaborated in the order in which they appear in the program text,
and later elaborations can depend on the results of earlier ones. The
elaboration of the declarations of certain entities requires run-time
information about the implementation details of other entities. The freezing
rules ensure that this information has been calculated by the time it
is used. For example, suppose the initial value of a constant is the
result of a function call that takes a parameter of type T. In
order to pass that parameter, the size of type T has to be known.
If T is composite, that size might be known only at run time.
(Note that in these discussions, words like
“before” and “after” generally refer to places
in the program text, as opposed to times at run time.)
The “implementation details” we're talking about above
For a tagged type, the implementations of
all the primitive subprograms of the type — that is (in the canonical
implementation model), the contents of the type descriptor, which contains
pointers to the code for each primitive subprogram.
For a type, the full type declaration of any
parts (including the type itself) that are private.
For a deferred constant, the full constant
declaration, which gives the constant's value. (Since this information
necessarily comes after the constant's type and subtype are fully known,
there's no need to worry about its type or subtype.)
For any entity, representation information
specified by the user via representation items. Most representation items
are for types or subtypes; however, various other kinds of entities,
such as objects and subprograms, are possible.
Similar issues arise for incomplete types. However, we do not use freezing
to prevent premature access; incomplete types have different, more severe,
restrictions. Similar issues also arise for subprograms, protected operations,
tasks and generic units. However, we do not use freezing to prevent premature
access for those, either; 3.11
with run-time Elaboration_Checks. Even so, freezing is used for these
entities to prevent giving representation items too late (that is, after
uses that require representation information, such as calls).
Language Design Principles
An evaluable construct should freeze anything
that's needed to evaluate it.
The compiler should be allowed to evaluate static
expressions without knowledge of their context. (I.e. there should not
be any special rules for static expressions that happen to occur in a
context that requires a static expression.)
Compilers should be allowed to evaluate static
expressions (and record the results) using the run-time representation
of the type. For example, suppose Color'Pos(Red) = 1, but the internal
code for Red is 37. If the value of a static expression is Red, some
compilers might store 1 in their symbol table, and other compilers might
store 37. Either compiler design should be feasible.
Compilers should never be required to detect
erroneousness or exceptions at compile time (although it's very nice
if they do). This implies that we should not require code-generation
for a nonstatic expression of type T too early, even if we can
prove that that expression will be erroneous, or will raise an exception.
Here's an example
(modified from AI83-00039, Example 3):
type T is
function F return T;
function G(X : T) return Boolean;
Y : Boolean := G(F); -- doesn't force T in Ada 83
for T use
this is legal. Of course, it raises Program_Error because the function
bodies aren't elaborated yet. A one-pass compiler has to generate code
for an expression of type T before it knows the representation of T.
Here's a similar example, which AI83-00039 also says is legal:
package P is
type T is private;
function F return T;
function G(X : T) return Boolean;
Y : Boolean := G(F); -- doesn't force T in Ada 83
type T is
If T's size were dynamic, that size would be
stored in some compiler-generated dope; this dope would be initialized
at the place of the full type declaration. However, the generated code
for the function calls would most likely allocate a temp of the size
specified by the dope before checking for Program_Error. That
dope would contain uninitialized junk, resulting in disaster. To avoid
doing that, the compiler would have to determine, at compile time, that
the expression will raise Program_Error.
This is silly. If we're going to require compilers
to detect the exception at compile time, we might as well formulate the
rule as a legality rule.
Compilers should not be required to generate
code to load the value of a variable before the address of the variable
has been determined.
After an entity has been frozen, no further
requirements may be placed on its representation (such as by a representation
item or a full_type_declaration
of an entity occurs at one or more places (freezing points
the program text where the representation for the entity has to be fully
determined. Each entity is frozen from its first freezing point to the
end of the program text (given the ordering of compilation units defined
Ramification: The “representation”
for a subprogram includes its calling convention and means for referencing
the subprogram body, either a “link-name” or specified address.
It does not include the code for the subprogram body itself, nor its
address if a link-name is used to reference the body.
This subclause also defines a place in the program
text where the profile of each declared callable entity becomes frozen
A use of a callable entity causes freezing of its profile in some contexts,
as described below. At the place where the profile of a callable entity
becomes frozen, the entity itself becomes frozen.
This is worded carefully
to handle nested packages and private types. Entities declared in a nested
will be frozen by some containing construct.
An incomplete type declared in the private part of a library package_specification
can be completed in the body. For other incomplete types (and in the
bodies of library packages), the completion of the type will be frozen
at the end of the package or declarative_part
and that will freeze the incomplete view as well.
The reason we have to worry about freezing of incomplete types is to
prevent premature uses of the types in dispatching calls. Such uses may
need access to the tag of the type, and the type has to be frozen to
know where the tag is stored.
The part about bodies does not say immediately
within. A renaming-as-body
does not have this property. Nor does an imported body
The reason bodies cause freezing
is because we want proper_bodies
to be interchangeable — one should be able to move a proper_body
to a subunit
and vice-versa, without changing the semantics. Clearly, anything that
should cause freezing should do so even if it's inside a proper_body
However, if we make it a body_stub
then the compiler can't see that thing that should cause freezing. So
we make body_stub
cause freezing, just in case they contain something that should cause
freezing. But that means we need to do the same for proper_bodies
Another reason for bodies to cause freezing,
there could be an added implementation burden if an entity declared in
an enclosing declarative_part
is frozen within a nested body, since some compilers look at bodies after
looking at the containing declarative_part
Note that the rule about proper bodies being freezing
only applies in declarative_parts.
All of the kinds of bodies (see 3.11.1 –
keep in mind the difference from bodys)
that are allowed in a package specification have their own freezing rules,
so they don't need to be covered by the above rule.
A construct that (explicitly or implicitly) references
an entity can cause the freezing
of the entity, as defined by
At the place where a construct
causes freezing, each name
within the construct causes freezing:
Note that in the sense
of this paragraph, a subtype_mark
“references” the denoted subtype, but not the type.
The occurrence of a generic_instantiation
causes freezing, except that a name
which is a generic actual parameter whose corresponding generic formal
parameter is a formal incomplete type (see 12.5.1
does not cause freezing. In addition, if a parameter of the instantiation
is defaulted, the default_expression
for that parameter causes freezing.
Thus, an actual parameter corresponding to a formal incomplete type parameter
may denote an incomplete or private type which is not completely defined
at the point of the generic_instantiation
This rule prevents calls through access values
to an expression that might have unfrozen parts. Typically, elaboration
checks and other freezing rules prevent this, but in this case the completion
is elaborated and since this is not a body
it does not by itself freeze anything that precedes it.
At the occurrence of a renames-as-body whose callable_entity_name
denotes an expression function, the return expression of the expression
function causes freezing.
The occurrence of an object_declaration
that has no corresponding completion causes freezing.
The declaration of a record
extension causes freezing of the parent subtype.
Ramification: This combined with another
rule specifying that primitive subprogram declarations shall precede
freezing ensures that all descendants of a tagged type implement all
of its dispatching operations.
The declaration of a private extension does not cause freezing. The freezing
is deferred until the full type declaration, which will necessarily be
for a record extension, task, or protected type (the latter only for
a limited private extension derived from an interface).
The declaration of a record extension, interface type, task unit, or
protected unit causes freezing of any progenitor types specified in the
Reason: This rule has the same purpose
as the one above: ensuring that all descendants of an interface tagged
type implement all of its dispatching operations. As with the previous
rule, a private extension does not freeze its progenitors; the full type
declaration (which must have the same progenitors) will do that.
Ramification: An interface type can be
a parent as well as a progenitor; these rules are similar so that the
location of an interface in a record extension does not have an effect
on the freezing of the interface type.
An implicit call freezes the same entities and profiles
that would be frozen by an explicit call. This is true even if the implicit
call is removed via implementation permissions.
If an expression is implicitly converted to a type
or subtype T
, then at the place where the expression causes freezing,
The following rules
define which entities are frozen at the place where a construct causes
Reason: We considered making enumeration
literals never cause freezing, which would be more upward compatible,
but examples like the variant record aggregate (Discrim => Red, ...)
caused us to change our mind. Furthermore, an enumeration literal is
a static expression, so the implementation should be allowed to represent
it using its representation.
The following pathological example was legal in Ada 83, but is illegal
in Ada 95:
package P1 is
type T is private;
package P2 is
type Composite(D : Boolean) is
case D is
when False => Cf : Integer;
when True => Ct : T;
X : Boolean := P2."="( (False,1), (False,1) );
type T is array(1..Func_Call) of Integer;
In Ada 95, the declaration of X freezes Composite
(because it contains an expression of that type), which in turn freezes
T (even though Ct does not exist in this particular case). But type T
is not completely defined at that point, violating the rule that a type
shall be completely defined before it is frozen. In Ada 83, on the other
hand, there is no occurrence of the name T, hence no forcing occurrence
At the place where a function
call causes freezing, the profile of the function is frozen. Furthermore,
if a parameter of the call is defaulted, the default_expression
for that parameter causes freezing. If the function call is to an expression
function, the return expression expression
of the expression function causes freezing.
This is the important rule for profile freezing: a call freezes the profile.
That's because generating the call will need to know how the parameters
are passed, and that will require knowing details of the types. Other
uses of subprograms do not need to know about the parameters, and thus
only freeze the subprogram, and not the profile.
Note that we don't need to consider procedure
or entry calls, since a body freezes everything that precedes it, and
the end of a declarative part freezes everything in the declarative part.
Freezing of the return expression expression
of an expression function only needs to be considered when the expression
function is in the same compilation unit and there are no intervening
the end of a declarative_part
or library package freezes everything in it, and a body body
freezes everything declared before it.
At the place where a generic_instantiation
causes freezing of a callable entity, the profile of that entity is frozen
unless the formal subprogram corresponding to the callable entity has
a parameter or result of a formal untagged incomplete type; if the callable
entity is an expression function, the return expression expression
of the expression function causes freezing.
Elaboration of the generic might
call the actual for one of its formal subprograms, so we need to know
the profile and (for an expression function) expression
At the place where a use of the Access or Unchecked_Access
attribute whose prefix
denotes an expression function causes freezing, the return
of the expression function causes freezing.
is needed to avoid calls to unfrozen expressions. Consider:
package Pack is
type Flub is range 0 .. 100;
function Foo (A : in Natural) return Natural is
(A + Flub'Size); -- The expression is not frozen here.
Bar is access function Foo
(A : in
P : Bar := Foo'Access; -- (A)
Val : Natural := P.all(5); -- (B)
If point (A) did not freeze the expression of
Foo (which freezes Flub), then the call at point (B) would be depending
on the aspects of the unfrozen type Flub. That would be bad.
the place where a name
causes freezing, the entity denoted by the name
is frozen, unless the name
is a prefix
of an expanded name;
at the place where an object
freezing, the nominal subtype associated with the name
This only matters in the presence of deferred constants or access types;
other than a deferred constant declaration causes freezing of the nominal
subtype, plus all component junk.
This rule ensures that X.D
freezes the same entities that X.all
.D does. Note that an implicit_dereference
is neither a name
by itself, so it isn't covered by other rules.
At the place where a range
causes freezing, the type of the range
Proof: This is consequence of the facts
that expressions freeze their type, and the Range attribute is defined
to be equivalent to a pair of expressions separated by “..”.}
the place where an allocator
causes freezing, the designated subtype of its type is frozen. If the
type of the allocator
is a derived type, then all ancestor types are also frozen.
also freeze the named subtype, as a consequence of other rules.
The ancestor types
are frozen to prevent things like this:
type Pool_Ptr is access System.Storage_Pools.Root_Storage_Pool'Class;
function F return Pool_Ptr;
package P is
type A1 is access Boolean;
type A2 is new A1;
type A3 is new A2;
X : A3 := new Boolean; -- Don't know what pool yet!
for A1'Storage_Pool use F.all;
This is necessary because derived access types
share their parent's pool.
At the place where a profile is frozen, each subtype
of the profile is frozen. If the corresponding callable entity is a member
of an entry family, the index subtype of the family is frozen.
the place where a subtype is frozen, its type is frozen.
the place where a type is frozen, any expressions or name
within the full type definition cause freezing; the first subtype, and
any component subtypes, index subtypes, and parent subtype of the type
are frozen as well.
For a specific
tagged type, the corresponding class-wide type is frozen as well. For
a class-wide type, the corresponding specific type is frozen as well.
Ramification: Freezing a type needs to
freeze its first subtype in order to preserve the property that the subtype-specific
aspects of statically matching subtypes are the same.
Freezing an access type does not freeze its
Reason: We have a language design principle
that all of the details of a specific tagged type are known at its freezing
point. But that is only true if the primitive subprograms are frozen
at this point as well. Late changes of Import and address clauses violate
Implementation Note: This rule means
that no implicit call to Initialize or Adjust can freeze a subprogram
(the type and thus subprograms would have been frozen at worst at the
The second sentence is the rule that makes it possible to check that
only subprograms with convention Ada are specified in attribute_definition_clause
without jumping through hoops.
[The explicit declaration
of a primitive subprogram of a tagged type shall occur before the type
is frozen (see 3.9.2
Reason: This rule is needed because (1)
we don't want people dispatching to things that haven't been declared
yet, and (2) we want to allow tagged type descriptors to be static (allocated
statically, and initialized to link-time-known symbols). Suppose T2 inherits
primitive P from T1, and then overrides P. Suppose P is called before
the declaration of the overriding P. What should it dispatch to? If the
answer is the new P, we've violated the first principle above. If the
answer is the old P, we've violated the second principle. (A call to
the new one necessarily raises Program_Error, but that's beside the point.)
Note that a call upon a dispatching operation
of type T will freeze T.
We considered applying this rule to all derived
types, for uniformity. However, that would be upward incompatible, so
we rejected the idea. As in Ada 83, for an untagged type, the above call
upon P will call the old P (which is arguably confusing).
To be honest:
This rule only applies to "original" declarations and not to
the completion of a primitive subprogram, even though a completion is
technically an explicit declaration, and it may declare a primitive subprogram.
[A type shall be completely
defined before it is frozen (see 3.11.1
[The completion of
a deferred constant declaration shall occur before the constant is frozen
An operational or representation item that directly specifies an aspect
of an entity shall appear before the entity is frozen (see 13.1
From RM83-13.1(7). The wording here forbids freezing within the aspect_clause
itself, which was not true of the Ada 83 wording. The wording of this
rule is carefully written to work properly for type-related representation
items. For example, an enumeration_representation_clause
is illegal after the type is frozen, even though the _clause
refers to the first subtype.
The above Legality Rule is stated for types and subtypes in 13.1
but the rule here covers all other entities as well.
Here's an example that illustrates when freezing occurs in the presence
type T is ...;
function F return T;
type R is
C : T := F;
D : Boolean := F = F;
X : R;
Since the elaboration of R's declaration does
not allocate component C, there is no need to freeze C's subtype at that
place. Similarly, since the elaboration of R does not evaluate the default_expression
“F = F”, there is no need to freeze the types involved at
that point. However, the declaration of X does
need to freeze
these things. Note that even if component C did not exist, the elaboration
of the declaration of X would still need information about T —
even though D is not of type T, its default_expression
requires that information.
Although we define freezing in terms of the program text as a whole (i.e.
after applying the rules of Clause 10
freezing rules actually have no effect beyond compilation unit boundaries.
That is important, because Clause 10
some implementation definedness in the order of things, and we don't
want the freezing rules to be implementation defined.
may choose to generate code for default_expression
in line at the place of use.
Alternatively, an implementation
may choose to generate thunks (subprograms implicitly generated by the
compiler) for evaluation of defaults. Thunk generation cannot, in general,
be done at the place of the declaration that includes the default. Instead,
they can be generated at the first freezing point of the type(s) involved.
(It is impossible to write a purely one-pass Ada compiler, for various
reasons. This is one of them — the compiler needs to store a representation
of defaults in its symbol table, and then walk that representation later,
no earlier than the first freezing point.)
In implementation terms, the linear elaboration
model can be thought of as preventing uninitialized dope. For example,
the implementation might generate dope to contain the size of a private
type. This dope is initialized at the place where the type becomes completely
defined. It cannot be initialized earlier, because of the order-of-elaboration
rules. The freezing rules prevent elaboration of earlier declarations
from accessing the size dope for a private type before it is initialized.
freezing rules in the case of unrecognized pragma
The tag (see 3.9
) of a tagged type T is created
at the point where T is frozen.
Incompatibilities With Ada 83
RM83 defines a forcing occurrence
of a type as follows: “A forcing occurrence is any occurrence [of
the name of the type, subtypes of the type, or types or subtypes with
subcomponents of the type] other than in a type or subtype declaration,
a subprogram specification, an entry declaration, a deferred constant
declaration, a pragma
or a representation_clause
for the type itself.
In any case, an occurrence within an expression is always forcing.”
It seems like
the wording allows things like this:
type A is array(Integer range 1..10) of Boolean;
subtype S is Integer range A'Range;
-- not forcing for A
Occurrences within pragma
can cause freezing in Ada 95. (Since such pragma
are ignored in Ada 83, this will probably fix more bugs than it causes.)
Extensions to Ada 83
package Outer is
type T is tagged limited private;
type T2 is
new T with private; -- Does not freeze T
-- in Ada 95.
package Inner is
type T is ...;
This is important for the usability of generics.
The above example uses the Ada 95 feature of formal derived types. Examples
using the kinds of formal parameters already allowed in Ada 83 are well
known. See, for example, comments 83-00627 and 83-00688. The extensive
use expected for formal derived types makes this issue even more compelling
than described by those comments. Unfortunately, we are unable to solve
the problem that explicit_generic_actual_parameter
cause freezing, even though a package equivalent to the instance would
not cause freezing. This is primarily because such an equivalent package
would have its body in the body of the containing program unit, whereas
an instance has its body right there.
Wording Changes from Ada 83
The concept of freezing is based on Ada 83's
concept of “forcing occurrences.” The first freezing point
of an entity corresponds roughly to the place of the first forcing occurrence,
in Ada 83 terms. The reason for changing the terminology is that the
new rules do not refer to any particular “occurrence” of
a name of an entity. Instead, we refer to “uses” of an entity,
which are sometimes implicit.
In Ada 83, forcing occurrences were used only
in rules about representation_clauses. We
have expanded the concept to cover private types, because the rules stated
in RM83-7.4.1(4) are almost identical to the forcing occurrence rules.
The Ada 83 rules
are changed in Ada 95 for the following reasons:
The Ada 83 rules do not work right for subtype-specific
aspects. In an earlier version of Ada 9X, we considered allowing representation
items to apply to subtypes other than the first subtype. This was part
of the reason for changing the Ada 83 rules. However, now that we have
dropped that functionality, we still need the rules to be different from
the Ada 83 rules.
The Ada 83 rules do not achieve the intended
effect. In Ada 83, either with or without the AIs, it is possible to
force the compiler to generate code that references uninitialized dope,
or force it to detect erroneousness and exception raising at compile
It was a goal of Ada 83 to avoid uninitialized
access values. However, in the case of deferred constants, this goal
was not achieved.
The Ada 83 rules are not only too weak —
they are also too strong. They allow loopholes (as described above),
but they also prevent certain kinds of default_expression
that are harmless, and certain kinds of generic_declaration
that are both harmless and very useful.
Incompatibilities With Ada 95
Various freezing rules were added
to fix holes in the rules. Most importantly, implicit calls are now freezing,
which make some representation clauses illegal in Ada 2005 that were
legal (but dubious) in Ada 95. Amendment Correction:
the primitive subprograms of a specific tagged type are frozen when the
type is frozen, preventing dubious convention changes (and address clauses)
after the freezing point. In both cases, the code is dubious and the
workaround is easy.
Wording Changes from Ada 95
Added wording to specify that both operational and
representation attributes must be specified before the type is frozen.
Added wording that declaring a specific descendant of an interface type
freezes the interface type.
Added wording that defines when a tag is created for a type (at the freezing
point of the type). This is used to specify checking for uncreated tags
Incompatibilities With Ada 2005
Separated the freezing of the
profile from the rest of a subprogram, in order to reduce the impact
of the Ada 95 incompatibility noted above. (The effects were much more
limiting than expected.)
Wording Changes from Ada 2005
Reworded so that incomplete types with a deferred
completion aren't prematurely frozen.
Added freezing rules for expression functions; these are frozen at the
point of call, not the point of declaration, like default expressions.
Added freezing rules for aspect_specification
these are frozen at the freezing point of the associated entity, not
the point of declaration.
Added freezing rules for formal incomplete types; the corresponding actual
is not frozen.
Wording Changes from Ada 2012
Corrigendum: Clarified when and what an
that is a completion or that is the target of a renames-as-body freezes.
This is formally an incompatibility, but as all known implementations
freeze expression functions more aggressively than allowed by either
the old or new wording, practically this will be an extension.
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe