- (1)
- This clause 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.
- (2)
- The freezing of an entity occurs at one or more places (freezing points)
in 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 in 10.1.4).
- (3)
- The end of a declarative_part, protected_body, or a declaration of a
library package or generic library package, causes freezing of each entity
declared within it, except for incomplete types. A noninstance body causes
freezing of each entity declared before it within the same declarative_part.
- (4)
- A construct that (explicitly or implicitly) references an entity can
cause the freezing of the entity, as defined by subsequent paragraphs. At
the place where a construct causes freezing, each name, expression, or range
within the construct causes freezing:
- (5)
- The occurrence of a generic_instantiation causes freezing; also,
if a parameter of the instantiation is defaulted, the default_expression or default_name for that parameter causes freezing.
- (6)
- The occurrence of an object_declaration that has no corresponding
completion causes freezing.
- (7)
- The declaration of a record extension causes freezing of the
parent subtype.
- (8)
- A static expression causes freezing where it occurs. A nonstatic
expression causes freezing where it occurs, unless the expression is part of
a default_expression, a default_name, or a per-object expression of a
component's constraint, in which case, the freezing occurs later as part of
another construct.
- (9)
- The following rules define which entities are frozen at the place where a
construct causes freezing:
- (10)
- At the place where an expression causes freezing, the type of the
expression is frozen, unless the expression is an enumeration
literal used as a discrete_choice of the array_aggregate of an
enumeration_representation_clause.
- (11)
- At 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 name causes freezing, the
nominal subtype associated with the name is frozen.
- (12)
- At the place where a range causes freezing, the type of the range
is frozen.
- (13)
- At 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.
- (14)
- At the place where a callable entity is frozen, each subtype of
its profile is frozen. If the callable entity is a member of an
entry family, the index subtype of the family is frozen. At the
place where a function call causes freezing, if a parameter of
the call is defaulted, the default_expression for that parameter
causes freezing.
- (15)
- At the place where a subtype is frozen, its type is frozen. At
the place where a type is frozen, any expressions or names 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.
Legality Rules
- (16)
- The explicit declaration of a primitive subprogram of a tagged type shall
occur before the type is frozen (see 3.9.2).
- (17)
- A type shall be completely defined before it is frozen (see
3.11.1 and 7.3).
- (18)
- The completion of a deferred constant declaration shall occur before the
constant is frozen (see 7.4).
- (19)
- A representation item that directly specifies an aspect of an entity shall
appear before the entity is frozen (see 13.1).
-- Email comments, additions, corrections, gripes, kudos, etc. to:
Magnus Kempe -- Magnus.Kempe@di.epfl.ch
Copyright statement
Page last generated: 95-03-12