1 |
706 |
jeremybenn |
------------------------------------------------------------------------------
|
2 |
|
|
-- --
|
3 |
|
|
-- GNAT COMPILER COMPONENTS --
|
4 |
|
|
-- --
|
5 |
|
|
-- F R E E Z E --
|
6 |
|
|
-- --
|
7 |
|
|
-- S p e c --
|
8 |
|
|
-- --
|
9 |
|
|
-- Copyright (C) 1992-2010, Free Software Foundation, Inc. --
|
10 |
|
|
-- --
|
11 |
|
|
-- GNAT is free software; you can redistribute it and/or modify it under --
|
12 |
|
|
-- terms of the GNU General Public License as published by the Free Soft- --
|
13 |
|
|
-- ware Foundation; either version 3, or (at your option) any later ver- --
|
14 |
|
|
-- sion. GNAT is distributed in the hope that it will be useful, but WITH- --
|
15 |
|
|
-- OUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY --
|
16 |
|
|
-- or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License --
|
17 |
|
|
-- for more details. You should have received a copy of the GNU General --
|
18 |
|
|
-- Public License distributed with GNAT; see file COPYING3. If not, go to --
|
19 |
|
|
-- http://www.gnu.org/licenses for a complete copy of the license. --
|
20 |
|
|
-- --
|
21 |
|
|
-- GNAT was originally developed by the GNAT team at New York University. --
|
22 |
|
|
-- Extensive contributions were provided by Ada Core Technologies Inc. --
|
23 |
|
|
-- --
|
24 |
|
|
------------------------------------------------------------------------------
|
25 |
|
|
|
26 |
|
|
with Types; use Types;
|
27 |
|
|
|
28 |
|
|
package Freeze is
|
29 |
|
|
|
30 |
|
|
--------------------------
|
31 |
|
|
-- Handling of Freezing --
|
32 |
|
|
--------------------------
|
33 |
|
|
|
34 |
|
|
-- In the formal Ada semantics, freezing of entities occurs at a well
|
35 |
|
|
-- defined point, described in (RM 13.14). The model in GNAT of freezing
|
36 |
|
|
-- is that a Freeze_Entity node is generated at the point where an entity
|
37 |
|
|
-- is frozen, and the entity contains a pointer (Freeze_Node) to this
|
38 |
|
|
-- generated freeze node.
|
39 |
|
|
|
40 |
|
|
-- The freeze node is processed in the expander to generate associated
|
41 |
|
|
-- data and subprograms (e.g. an initialization procedure) which must
|
42 |
|
|
-- be delayed until the type is frozen and its representation can be
|
43 |
|
|
-- fully determined. Subsequently the freeze node is used by Gigi to
|
44 |
|
|
-- determine the point at which it should elaborate the corresponding
|
45 |
|
|
-- entity (this elaboration also requires the representation of the
|
46 |
|
|
-- entity to be fully determinable). The freeze node is also used to
|
47 |
|
|
-- provide additional diagnostic information (pinpointing the freeze
|
48 |
|
|
-- point), when order of freezing errors are detected.
|
49 |
|
|
|
50 |
|
|
-- If we were fully faithful to the Ada model, we would generate freeze
|
51 |
|
|
-- nodes for all entities, but that is a bit heavy so we optimize (that
|
52 |
|
|
-- is the nice word) or cut corners (which is a bit more honest). For
|
53 |
|
|
-- many entities, we do not need to delay the freeze and instead can
|
54 |
|
|
-- freeze them at the point of declaration. The conditions for this
|
55 |
|
|
-- early freezing being permissible are as follows:
|
56 |
|
|
|
57 |
|
|
-- There is no associated expander activity that needs to be delayed
|
58 |
|
|
|
59 |
|
|
-- Gigi can fully elaborate the entity at the point of occurrence (or,
|
60 |
|
|
-- equivalently, no real elaboration is required for the entity).
|
61 |
|
|
|
62 |
|
|
-- In order for these conditions to be met (especially the second), it
|
63 |
|
|
-- must be the case that all representation characteristics of the entity
|
64 |
|
|
-- can be determined at declaration time.
|
65 |
|
|
|
66 |
|
|
-- The following indicates how freezing is handled for all entity kinds:
|
67 |
|
|
|
68 |
|
|
-- Types
|
69 |
|
|
|
70 |
|
|
-- All declared types have freeze nodes, as well as anonymous base
|
71 |
|
|
-- types created for type declarations where the defining identifier
|
72 |
|
|
-- is a first subtype of the anonymous type.
|
73 |
|
|
|
74 |
|
|
-- Subtypes
|
75 |
|
|
|
76 |
|
|
-- All first subtypes have freeze nodes. Other subtypes need freeze
|
77 |
|
|
-- nodes if the corresponding base type has not yet been frozen. If
|
78 |
|
|
-- the base type has been frozen, then there is no need for a freeze
|
79 |
|
|
-- node, since no rep clauses can appear for the subtype in any case.
|
80 |
|
|
|
81 |
|
|
-- Implicit types and subtypes
|
82 |
|
|
|
83 |
|
|
-- As noted above, implicit base types always have freeze nodes. Other
|
84 |
|
|
-- implicit types and subtypes typically do not require freeze nodes,
|
85 |
|
|
-- because there is no possibility of delaying any information about
|
86 |
|
|
-- their representation.
|
87 |
|
|
|
88 |
|
|
-- Subprograms
|
89 |
|
|
--
|
90 |
|
|
-- Are frozen at the point of declaration unless one or more of the
|
91 |
|
|
-- formal types or return type themselves have delayed freezing and
|
92 |
|
|
-- are not yet frozen. This includes the case of a formal access type
|
93 |
|
|
-- where the designated type is not frozen. Note that we are talking
|
94 |
|
|
-- about subprogram specs here (subprogram body entities have no
|
95 |
|
|
-- relevance), and in any case, subprogram bodies freeze everything.
|
96 |
|
|
|
97 |
|
|
-- Objects with dynamic address clauses
|
98 |
|
|
--
|
99 |
|
|
-- These have a delayed freeze. Gigi will generate code to evaluate
|
100 |
|
|
-- the initialization expression if present and store it in a temp.
|
101 |
|
|
-- The actual object is created at the point of the freeze, and if
|
102 |
|
|
-- necessary initialized by copying the value of this temporary.
|
103 |
|
|
|
104 |
|
|
-- Formal Parameters
|
105 |
|
|
--
|
106 |
|
|
-- Are frozen when the associated subprogram is frozen, so there is
|
107 |
|
|
-- never any need for them to have delayed freezing.
|
108 |
|
|
|
109 |
|
|
-- Other Objects
|
110 |
|
|
--
|
111 |
|
|
-- Are always frozen at the point of declaration
|
112 |
|
|
|
113 |
|
|
-- All Other Entities
|
114 |
|
|
|
115 |
|
|
-- Are always frozen at the point of declaration
|
116 |
|
|
|
117 |
|
|
-- The flag Has_Delayed_Freeze is used for to indicate that delayed
|
118 |
|
|
-- freezing is required. Usually the associated freeze node is allocated
|
119 |
|
|
-- at the freezing point. One special exception occurs with anonymous
|
120 |
|
|
-- base types, where the freeze node is preallocated at the point of
|
121 |
|
|
-- declaration, so that the First_Subtype_Link field can be set.
|
122 |
|
|
|
123 |
|
|
Freezing_Library_Level_Tagged_Type : Boolean := False;
|
124 |
|
|
-- Flag used to indicate that we are freezing the primitives of a library
|
125 |
|
|
-- level tagged types. Used to disable checks on premature freezing.
|
126 |
|
|
-- More documentation needed??? why is this flag needed? what are these
|
127 |
|
|
-- checks? why do they need disabling in some cases?
|
128 |
|
|
|
129 |
|
|
-----------------
|
130 |
|
|
-- Subprograms --
|
131 |
|
|
-----------------
|
132 |
|
|
|
133 |
|
|
function Build_Renamed_Body
|
134 |
|
|
(Decl : Node_Id;
|
135 |
|
|
New_S : Entity_Id) return Node_Id;
|
136 |
|
|
-- Rewrite renaming declaration as a subprogram body, whose single
|
137 |
|
|
-- statement is a call to the renamed entity. New_S is the entity that
|
138 |
|
|
-- appears in the renaming declaration. If this is a Renaming_As_Body,
|
139 |
|
|
-- then Decl is the original subprogram declaration that is completed
|
140 |
|
|
-- by the renaming, otherwise it is the renaming declaration itself.
|
141 |
|
|
-- The caller inserts the body where required. If this call comes
|
142 |
|
|
-- from a freezing action, the resulting body is analyzed at once.
|
143 |
|
|
|
144 |
|
|
procedure Check_Compile_Time_Size (T : Entity_Id);
|
145 |
|
|
-- Check to see whether the size of the type T is known at compile time.
|
146 |
|
|
-- There are three possible cases:
|
147 |
|
|
--
|
148 |
|
|
-- Size is not known at compile time. In this case, the call has no
|
149 |
|
|
-- effect. Note that the processing is conservative here, in the sense
|
150 |
|
|
-- that this routine may decide that the size is not known even if in
|
151 |
|
|
-- fact Gigi decides it is known, but the opposite situation can never
|
152 |
|
|
-- occur.
|
153 |
|
|
--
|
154 |
|
|
-- Size is known at compile time, but the actual value of the size is
|
155 |
|
|
-- not known to the front end or is definitely 32 or more. In this case
|
156 |
|
|
-- Size_Known_At_Compile_Time is set, but the Esize field is left set
|
157 |
|
|
-- to zero (to be set by Gigi).
|
158 |
|
|
--
|
159 |
|
|
-- Size is known at compile time, and the actual value of the size is
|
160 |
|
|
-- known to the front end and is less than 32. In this case, the flag
|
161 |
|
|
-- Size_Known_At_Compile_Time is set, and in addition Esize is set to
|
162 |
|
|
-- the required size, allowing for possible front end packing of an
|
163 |
|
|
-- array using this type as a component type.
|
164 |
|
|
--
|
165 |
|
|
-- Note: the flag Size_Known_At_Compile_Time is used to determine if the
|
166 |
|
|
-- secondary stack must be used to return a value of the type, and also
|
167 |
|
|
-- to determine whether a component clause is allowed for a component
|
168 |
|
|
-- of the given type.
|
169 |
|
|
--
|
170 |
|
|
-- Note: this is public because of one dubious use in Sem_Res???
|
171 |
|
|
--
|
172 |
|
|
-- Note: Check_Compile_Time_Size does not test the case of the size being
|
173 |
|
|
-- known because a size clause is specifically given. That is because we
|
174 |
|
|
-- do not allow a size clause if the size would not otherwise be known at
|
175 |
|
|
-- compile time in any case.
|
176 |
|
|
|
177 |
|
|
function Is_Atomic_Aggregate
|
178 |
|
|
(E : Entity_Id;
|
179 |
|
|
Typ : Entity_Id) return Boolean;
|
180 |
|
|
|
181 |
|
|
-- If an atomic object is initialized with an aggregate or is assigned an
|
182 |
|
|
-- aggregate, we have to prevent a piecemeal access or assignment to the
|
183 |
|
|
-- object, even if the aggregate is to be expanded. We create a temporary
|
184 |
|
|
-- for the aggregate, and assign the temporary instead, so that the back
|
185 |
|
|
-- end can generate an atomic move for it. This is only done in the context
|
186 |
|
|
-- of an object declaration or an assignment. Function is a noop and
|
187 |
|
|
-- returns false in other contexts.
|
188 |
|
|
|
189 |
|
|
function Freeze_Entity (E : Entity_Id; N : Node_Id) return List_Id;
|
190 |
|
|
-- Freeze an entity, and return Freeze nodes, to be inserted at the point
|
191 |
|
|
-- of call. N is a node whose source location corresponds to the freeze
|
192 |
|
|
-- point. This is used in placing warning messages in the situation where
|
193 |
|
|
-- it appears that a type has been frozen too early, e.g. when a primitive
|
194 |
|
|
-- operation is declared after the freezing point of its tagged type.
|
195 |
|
|
-- Returns No_List if no freeze nodes needed.
|
196 |
|
|
|
197 |
|
|
procedure Freeze_All (From : Entity_Id; After : in out Node_Id);
|
198 |
|
|
-- Before a non-instance body, or at the end of a declarative part
|
199 |
|
|
-- freeze all entities therein that are not yet frozen. Calls itself
|
200 |
|
|
-- recursively to catch types in inner packages that were not frozen
|
201 |
|
|
-- at the inner level because they were not yet completely defined.
|
202 |
|
|
-- This routine also analyzes and freezes default parameter expressions
|
203 |
|
|
-- in subprogram specifications (this has to be delayed until all the
|
204 |
|
|
-- types are frozen). The resulting freeze nodes are inserted just
|
205 |
|
|
-- after node After (which is a list node) and analyzed. On return,
|
206 |
|
|
-- 'After' is updated to point to the last node inserted (or is returned
|
207 |
|
|
-- unchanged if no nodes were inserted). 'From' is the last entity frozen
|
208 |
|
|
-- in the scope. It is used to prevent a quadratic traversal over already
|
209 |
|
|
-- frozen entities.
|
210 |
|
|
|
211 |
|
|
procedure Freeze_Before (N : Node_Id; T : Entity_Id);
|
212 |
|
|
-- Freeze T then Insert the generated Freeze nodes before the node N
|
213 |
|
|
|
214 |
|
|
procedure Freeze_Expression (N : Node_Id);
|
215 |
|
|
-- Freezes the required entities when the Expression N causes freezing.
|
216 |
|
|
-- The node N here is either a subexpression node (a "real" expression)
|
217 |
|
|
-- or a subtype mark, or a subtype indication. The latter two cases are
|
218 |
|
|
-- not really expressions, but they can appear within expressions and
|
219 |
|
|
-- so need to be similarly treated. Freeze_Expression takes care of
|
220 |
|
|
-- determining the proper insertion point for generated freeze actions.
|
221 |
|
|
|
222 |
|
|
procedure Freeze_Fixed_Point_Type (Typ : Entity_Id);
|
223 |
|
|
-- Freeze fixed point type. For fixed-point types, we have to defer
|
224 |
|
|
-- setting the size and bounds till the freeze point, since they are
|
225 |
|
|
-- potentially affected by the presence of size and small clauses.
|
226 |
|
|
|
227 |
|
|
procedure Freeze_Itype (T : Entity_Id; N : Node_Id);
|
228 |
|
|
-- This routine is called when an Itype is created and must be frozen
|
229 |
|
|
-- immediately at the point of creation (for the sake of the expansion
|
230 |
|
|
-- activities in Exp_Ch3 (for example, the creation of packed array
|
231 |
|
|
-- types). We can't just let Freeze_Expression do this job since it
|
232 |
|
|
-- goes out of its way to make sure that the freeze node occurs at a
|
233 |
|
|
-- point outside the current construct, e.g. outside the expression or
|
234 |
|
|
-- outside the initialization procedure. That's normally right, but
|
235 |
|
|
-- not in this case, since if we create an Itype in an expression it
|
236 |
|
|
-- may be the case that it is not always elaborated (for example it
|
237 |
|
|
-- may result from the right operand of a short circuit). In this case
|
238 |
|
|
-- we want the freeze node to be inserted at the same point as the Itype.
|
239 |
|
|
-- The node N provides both the location for the freezing and also the
|
240 |
|
|
-- insertion point for the resulting freeze nodes.
|
241 |
|
|
|
242 |
|
|
end Freeze;
|