]>
Commit | Line | Data |
---|---|---|
996ae0b0 RK |
1 | ------------------------------------------------------------------------------ |
2 | -- -- | |
3 | -- GNAT COMPILER COMPONENTS -- | |
4 | -- -- | |
5 | -- S E M -- | |
6 | -- -- | |
7 | -- S p e c -- | |
8 | -- -- | |
fbf5a39b | 9 | -- Copyright (C) 1992-2003 Free Software Foundation, Inc. -- |
996ae0b0 RK |
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 2, 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 COPYING. If not, write -- | |
19 | -- to the Free Software Foundation, 59 Temple Place - Suite 330, Boston, -- | |
20 | -- MA 02111-1307, USA. -- | |
21 | -- -- | |
22 | -- GNAT was originally developed by the GNAT team at New York University. -- | |
71ff80dc | 23 | -- Extensive contributions were provided by Ada Core Technologies Inc. -- |
996ae0b0 RK |
24 | -- -- |
25 | ------------------------------------------------------------------------------ | |
26 | ||
27 | -------------------------------------- | |
28 | -- Semantic Analysis: General Model -- | |
29 | -------------------------------------- | |
30 | ||
31 | -- Semantic processing involves 3 phases which are highly interwined | |
32 | -- (ie mutually recursive): | |
fbf5a39b | 33 | |
996ae0b0 RK |
34 | -- Analysis implements the bulk of semantic analysis such as |
35 | -- name analysis and type resolution for declarations, | |
36 | -- instructions and expressions. The main routine | |
37 | -- driving this process is procedure Analyze given below. | |
38 | -- This analysis phase is really a bottom up pass that is | |
39 | -- achieved during the recursive traversal performed by the | |
40 | -- Analyze_... procedures implemented in the sem_* packages. | |
41 | -- For expressions this phase determines unambiguous types | |
42 | -- and collects sets of possible types where the | |
43 | -- interpretation is potentially ambiguous. | |
fbf5a39b | 44 | |
996ae0b0 RK |
45 | -- Resolution is carried out only for expressions to finish type |
46 | -- resolution that was initiated but not necessarily | |
47 | -- completed during analysis (because of overloading | |
48 | -- ambiguities). Specifically, after completing the bottom | |
49 | -- up pass carried out during analysis for expressions, the | |
50 | -- Resolve routine (see the spec of sem_res for more info) | |
51 | -- is called to perform a top down resolution with | |
52 | -- recursive calls to itself to resolve operands. | |
fbf5a39b | 53 | |
996ae0b0 RK |
54 | -- Expansion if we are not generating code this phase is a no-op. |
55 | -- otherwise this phase expands, ie transforms, original | |
56 | -- declaration, expressions or instructions into simpler | |
57 | -- structures that can be handled by the back-end. This | |
58 | -- phase is also in charge of generating code which is | |
59 | -- implicit in the original source (for instance for | |
60 | -- default initializations, controlled types, etc.) | |
61 | -- There are two separate instances where expansion is | |
62 | -- invoked. For declarations and instructions, expansion is | |
63 | -- invoked just after analysis since no resolution needs | |
64 | -- to be performed. For expressions, expansion is done just | |
65 | -- after resolution. In both cases expansion is done from the | |
66 | -- bottom up just before the end of Analyze for instructions | |
67 | -- and declarations or the call to Resolve for expressions. | |
68 | -- The main routine driving expansion is Expand. | |
69 | -- See the spec of Expander for more details. | |
fbf5a39b | 70 | |
996ae0b0 RK |
71 | -- To summarize, in normal code generation mode we recursively traverse the |
72 | -- abstract syntax tree top-down performing semantic analysis bottom | |
73 | -- up. For instructions and declarations, before the call to the Analyze | |
74 | -- routine completes we perform expansion since at that point we have all | |
75 | -- semantic information needed. For expression nodes, after the call to | |
76 | -- Analysis terminates we invoke the Resolve routine to transmit top-down | |
77 | -- the type that was gathered by Analyze which will resolve possible | |
78 | -- ambiguities in the expression. Just before the call to Resolve | |
79 | -- terminates, the expression can be expanded since all the semantic | |
80 | -- information is available at that point. | |
fbf5a39b | 81 | |
996ae0b0 | 82 | -- If we are not generating code then the expansion phase is a no-op. |
fbf5a39b | 83 | |
996ae0b0 RK |
84 | -- When generating code there are a number of exceptions to the basic |
85 | -- Analysis-Resolution-Expansion model for expressions. The most prominent | |
86 | -- examples are the handling of default expressions and aggregates. | |
87 | ||
fbf5a39b AC |
88 | ---------------------------------------------------- |
89 | -- Handling of Default and Per-Object Expressions -- | |
90 | ---------------------------------------------------- | |
996ae0b0 RK |
91 | |
92 | -- The default expressions in component declarations and in procedure | |
93 | -- specifications (but not the ones in object declarations) are quite | |
94 | -- tricky to handle. The problem is that some processing is required | |
95 | -- at the point where the expression appears: | |
fbf5a39b | 96 | |
996ae0b0 RK |
97 | -- visibility analysis (including user defined operators) |
98 | -- freezing of static expressions | |
fbf5a39b | 99 | |
996ae0b0 RK |
100 | -- but other processing must be deferred until the enclosing entity |
101 | -- (record or procedure specification) is frozen: | |
fbf5a39b | 102 | |
996ae0b0 RK |
103 | -- freezing of any other types in the expression |
104 | -- expansion | |
fbf5a39b AC |
105 | |
106 | -- A similar situation occurs with the argument of priority and interrupt | |
107 | -- priority pragmas that appear in task and protected definition specs and | |
108 | -- other cases of per-object expressions (see RM 3.8(18)). | |
109 | ||
996ae0b0 RK |
110 | -- Expansion has to be deferred since you can't generate code for |
111 | -- expressions that refernce types that have not been frozen yet. As an | |
112 | -- example, consider the following: | |
fbf5a39b | 113 | |
996ae0b0 RK |
114 | -- type x is delta 0.5 range -10.0 .. +10.0; |
115 | -- ... | |
116 | -- type q is record | |
117 | -- xx : x := y * z; | |
118 | -- end record; | |
fbf5a39b | 119 | |
996ae0b0 | 120 | -- for x'small use 0.25 |
fbf5a39b | 121 | |
996ae0b0 RK |
122 | -- The expander is in charge of dealing with fixed-point, and of course |
123 | -- the small declaration, which is not too late, since the declaration of | |
124 | -- type q does *not* freeze type x, definitely affects the expanded code. | |
fbf5a39b AC |
125 | |
126 | -- Another reason that we cannot expand early is that expansion can generate | |
127 | -- range checks. These range checks need to be inserted not at the point of | |
128 | -- definition but at the point of use. The whole point here is that the value | |
129 | -- of the expression cannot be obtained at the point of declaration, only at | |
130 | -- the point of use. | |
131 | ||
996ae0b0 RK |
132 | -- Generally our model is to combine analysis resolution and expansion, but |
133 | -- this is the one case where this model falls down. Here is how we patch | |
134 | -- it up without causing too much distortion to our basic model. | |
fbf5a39b | 135 | |
996ae0b0 | 136 | -- A switch (sede below) is set to indicate that we are in the initial |
fbf5a39b | 137 | -- occurence of a default expression. The analyzer is then called on this |
996ae0b0 RK |
138 | -- expression with the switch set true. Analysis and resolution proceed |
139 | -- almost as usual, except that Freeze_Expression will not freeze | |
140 | -- non-static expressions if this switch is set, and the call to Expand at | |
141 | -- the end of resolution is skipped. This also skips the code that normally | |
142 | -- sets the Analyzed flag to True). The result is that when we are done the | |
143 | -- tree is still marked as unanalyzed, but all types for static expressions | |
144 | -- are frozen as required, and all entities of variables have been | |
145 | -- recorded. We then turn off the switch, and later on reanalyze the | |
146 | -- expression with the switch off. The effect is that this second analysis | |
147 | -- freezes the rest of the types as required, and generates code but | |
148 | -- visibility analysis is not repeated since all the entities are marked. | |
fbf5a39b | 149 | |
996ae0b0 RK |
150 | -- The second analysis (the one that generates code) is in the context |
151 | -- where the code is required. For a record field default, this is in | |
152 | -- the initialization procedure for the record and for a subprogram | |
153 | -- default parameter, it is at the point the subprogram is frozen. | |
fbf5a39b AC |
154 | -- For a priority or storage size pragma it is in the context of the |
155 | -- Init_Proc for the task or protected object. | |
996ae0b0 RK |
156 | |
157 | ------------------ | |
158 | -- Pre-Analysis -- | |
159 | ------------------ | |
160 | ||
161 | -- For certain kind of expressions, such as aggregates, we need to defer | |
162 | -- expansion of the aggregate and its inner expressions after the whole | |
163 | -- set of expressions appearing inside the aggregate have been analyzed. | |
164 | -- Consider, for instance the following example: | |
165 | -- | |
166 | -- (1 .. 100 => new Thing (Function_Call)) | |
167 | -- | |
168 | -- The normal Analysis-Resolution-Expansion mechanism where expansion | |
169 | -- of the children is performed before expansion of the parent does not | |
170 | -- work if the code generated for the children by the expander needs | |
171 | -- to be evaluated repeatdly (for instance in the above aggregate | |
172 | -- "new Thing (Function_Call)" needs to be called 100 times.) | |
173 | -- The reason why this mecanism does not work is that, the expanded code | |
174 | -- for the children is typically inserted above the parent and thus | |
175 | -- when the father gets expanded no re-evaluation takes place. For instance | |
176 | -- in the case of aggregates if "new Thing (Function_Call)" is expanded | |
177 | -- before of the aggregate the expanded code will be placed outside | |
178 | -- of the aggregate and when expanding the aggregate the loop from 1 to 100 | |
179 | -- will not surround the expanded code for "new Thing (Function_Call)". | |
180 | -- | |
181 | -- To remedy this situation we introduce a new flag which signals whether | |
182 | -- we want a full analysis (ie expansion is enabled) or a pre-analysis | |
183 | -- which performs Analysis and Resolution but no expansion. | |
184 | -- | |
185 | -- After the complete pre-analysis of an expression has been carried out | |
186 | -- we can transform the expression and then carry out the full | |
187 | -- Analyze-Resolve-Expand cycle on the transformed expression top-down | |
188 | -- so that the expansion of inner expressions happens inside the newly | |
189 | -- generated node for the parent expression. | |
190 | -- | |
191 | -- Note that the difference between processing of default expressions and | |
192 | -- pre-analysis of other expressions is that we do carry out freezing in | |
193 | -- the latter but not in the former (except for static scalar expressions). | |
194 | -- The routine that performs pre-analysis is called Pre_Analyze_And_Resolve | |
195 | -- and is in Sem_Res. | |
196 | ||
197 | with Alloc; | |
198 | with Einfo; use Einfo; | |
199 | with Opt; use Opt; | |
996ae0b0 RK |
200 | with Table; |
201 | with Types; use Types; | |
202 | ||
203 | package Sem is | |
204 | ||
205 | New_Nodes_OK : Int := 1; | |
206 | -- Temporary flag for use in checking out HLO. Set non-zero if it is | |
207 | -- OK to generate new nodes. | |
208 | ||
209 | ----------------------------- | |
210 | -- Semantic Analysis Flags -- | |
211 | ----------------------------- | |
212 | ||
fbf5a39b AC |
213 | Explicit_Overriding : Boolean := False; |
214 | -- Switch to indicate whether checking mechanism described in AI-218 | |
215 | -- is enforced: subprograms that override inherited operations must be | |
216 | -- be marked explicitly, to prevent accidental or omitted overriding. | |
217 | ||
996ae0b0 RK |
218 | Full_Analysis : Boolean := True; |
219 | -- Switch to indicate whether we are doing a full analysis or a | |
220 | -- pre-analysis. In normal analysis mode (Analysis-Expansion for | |
221 | -- instructions or declarations) or (Analysis-Resolution-Expansion for | |
222 | -- expressions) this flag is set. Note that if we are not generating | |
223 | -- code the expansion phase merely sets the Analyzed flag to True in | |
224 | -- this case. If we are in Pre-Analysis mode (see above) this flag is | |
225 | -- set to False then the expansion phase is skipped. | |
226 | -- When this flag is False the flag Expander_Active is also False | |
227 | -- (the Expander_Activer flag defined in the spec of package Expander | |
228 | -- tells you whether expansion is currently enabled). | |
229 | -- You should really regard this as a read only flag. | |
230 | ||
231 | In_Default_Expression : Boolean := False; | |
232 | -- Switch to indicate that we are in a default expression, as described | |
233 | -- above. Note that this must be recursively saved on a Semantics call | |
234 | -- since it is possible for the analysis of an expression to result in | |
235 | -- a recursive call (e.g. to get the entity for System.Address as part | |
236 | -- of the processing of an Address attribute reference). | |
237 | -- When this switch is True then Full_Analysis above must be False. | |
238 | -- You should really regard this as a read only flag. | |
239 | ||
fbf5a39b AC |
240 | In_Deleted_Code : Boolean := False; |
241 | -- If the condition in an if-statement is statically known, the branch | |
242 | -- that is not taken is analyzed with expansion disabled, and the tree | |
243 | -- is deleted after analysis. Itypes generated in deleted code must be | |
244 | -- frozen from start, because the tree on which they depend will not | |
245 | -- be available at the freeze point. | |
246 | ||
996ae0b0 RK |
247 | In_Inlined_Body : Boolean := False; |
248 | -- Switch to indicate that we are analyzing and resolving an inlined | |
249 | -- body. Type checking is disabled in this context, because types are | |
250 | -- known to be compatible. This avoids problems with private types whose | |
251 | -- full view is derived from private types. | |
252 | ||
253 | Inside_A_Generic : Boolean := False; | |
254 | -- This flag is set if we are processing a generic specification, | |
255 | -- generic definition, or generic body. When this flag is True the | |
256 | -- Expander_Active flag is False to disable any code expansion (see | |
257 | -- package Expander). Only the generic processing can modify the | |
258 | -- status of this flag, any other client should regard it as read-only. | |
259 | ||
260 | Unloaded_Subunits : Boolean := False; | |
261 | -- This flag is set True if we have subunits that are not loaded. This | |
262 | -- occurs when the main unit is a subunit, and contains lower level | |
263 | -- subunits that are not loaded. We use this flag to suppress warnings | |
264 | -- about unused variables, since these warnings are unreliable in this | |
265 | -- case. We could perhaps do a more accurate job and retain some of the | |
266 | -- warnings, but it is quite a tricky job. See test 4323-002. | |
267 | ||
268 | ----------------- | |
269 | -- Scope Stack -- | |
270 | ----------------- | |
271 | ||
996ae0b0 RK |
272 | -- The scope stack holds all entries of the scope table. As in the parser, |
273 | -- we use Last as the stack pointer, so that we can always find the scope | |
274 | -- that is currently open in Scope_Stack.Table (Scope_Stack.Last). The | |
275 | -- oldest entry, at Scope_Stack (0) is Standard. The entries in the table | |
276 | -- include the entity for the referenced scope, together with information | |
277 | -- used to restore the proper setting of check suppressions on scope exit. | |
278 | ||
996ae0b0 RK |
279 | type Scope_Stack_Entry is record |
280 | Entity : Entity_Id; | |
281 | -- Entity representing the scope | |
282 | ||
283 | Last_Subprogram_Name : String_Ptr; | |
284 | -- Pointer to name of last subprogram body in this scope. Used for | |
285 | -- testing proper alpha ordering of subprogram bodies in scope. | |
286 | ||
fbf5a39b | 287 | Save_Scope_Suppress : Suppress_Array; |
996ae0b0 RK |
288 | -- Save contents of Scope_Suppress on entry |
289 | ||
fbf5a39b AC |
290 | Save_Local_Entity_Suppress : Int; |
291 | -- Save contents of Local_Entity_Suppress.Last on entry | |
996ae0b0 RK |
292 | |
293 | Is_Transient : Boolean; | |
294 | -- Marks Transient Scopes (See Exp_Ch7 body for details) | |
295 | ||
296 | Previous_Visibility : Boolean; | |
297 | -- Used when installing the parent (s) of the current compilation | |
298 | -- unit. The parent may already be visible because of an ongoing | |
299 | -- compilation, and the proper visibility must be restored on exit. | |
300 | ||
301 | Node_To_Be_Wrapped : Node_Id; | |
302 | -- Only used in transient scopes. Records the node which will | |
303 | -- be wrapped by the transient block. | |
304 | ||
305 | Actions_To_Be_Wrapped_Before : List_Id; | |
306 | Actions_To_Be_Wrapped_After : List_Id; | |
307 | -- Actions that have to be inserted at the start or at the end of a | |
308 | -- transient block. Used to temporarily hold these actions until the | |
309 | -- block is created, at which time the actions are moved to the | |
310 | -- block. | |
311 | ||
312 | Pending_Freeze_Actions : List_Id; | |
313 | -- Used to collect freeze entity nodes and associated actions that | |
314 | -- are generated in a inner context but need to be analyzed outside, | |
315 | -- such as records and initialization procedures. On exit from the | |
316 | -- scope, this list of actions is inserted before the scope construct | |
317 | -- and analyzed to generate the corresponding freeze processing and | |
318 | -- elaboration of other associated actions. | |
319 | ||
320 | First_Use_Clause : Node_Id; | |
321 | -- Head of list of Use_Clauses in current scope. The list is built | |
322 | -- when the declarations in the scope are processed. The list is | |
323 | -- traversed on scope exit to undo the effect of the use clauses. | |
324 | ||
325 | Component_Alignment_Default : Component_Alignment_Kind; | |
326 | -- Component alignment to be applied to any record or array types | |
327 | -- that are declared for which a specific component alignment pragma | |
328 | -- does not set the alignment. | |
329 | ||
330 | Is_Active_Stack_Base : Boolean; | |
331 | -- Set to true only when entering the scope for Standard_Standard from | |
332 | -- from within procedure Semantics. Indicates the base of the current | |
333 | -- active set of scopes. Needed by In_Open_Scopes to handle cases | |
334 | -- where Standard_Standard can be pushed in the middle of the active | |
335 | -- set of scopes (occurs for instantiations of generic child units). | |
336 | end record; | |
337 | ||
338 | package Scope_Stack is new Table.Table ( | |
339 | Table_Component_Type => Scope_Stack_Entry, | |
340 | Table_Index_Type => Int, | |
341 | Table_Low_Bound => 0, | |
342 | Table_Initial => Alloc.Scope_Stack_Initial, | |
343 | Table_Increment => Alloc.Scope_Stack_Increment, | |
344 | Table_Name => "Sem.Scope_Stack"); | |
345 | ||
fbf5a39b AC |
346 | ----------------------------------- |
347 | -- Handling of Check Suppression -- | |
348 | ----------------------------------- | |
996ae0b0 | 349 | |
fbf5a39b AC |
350 | -- There are two kinds of suppress checks, scope based suppress checks |
351 | -- (from initial command line arguments, or from Suppress pragmas not | |
352 | -- including an entity name). The scope based suppress checks are recorded | |
353 | -- in the Sem.Supress variable, and all that is necessary is to save the | |
354 | -- state of this variable on scope entry, and restore it on scope exit. | |
355 | ||
356 | -- The other kind of suppress check is entity based suppress checks, from | |
357 | -- Suppress pragmas giving an Entity_Id. These are handled as follows. If | |
358 | -- a suppress or unsuppress pragma is encountered for a given entity, then | |
359 | -- the flag Checks_May_Be_Suppressed is set in the entity and an entry is | |
360 | -- made in either the Local_Entity_Suppress table (case of pragma that | |
361 | -- appears in other than a package spec), or in the Global_Entity_Suppress | |
362 | -- table (case of pragma that appears in a package spec, which is by the | |
363 | -- rule of RM 11.5(7) applicable throughout the life of the entity). | |
364 | ||
365 | -- If the Checks_May_Be_Suppressed flag is set in an entity then the | |
366 | -- procedure is to search first the local and then the global suppress | |
367 | -- tables (the local one being searched in reverse order, i.e. last in | |
368 | -- searched first). The only other point is that we have to make sure | |
369 | -- that we have proper nested interaction between such specific pragmas | |
370 | -- and locally applied general pragmas applying to all entities. This | |
371 | -- is achieved by including in the Local_Entity_Suppress table dummy | |
372 | -- entries with an empty Entity field that are applicable to all entities. | |
373 | ||
374 | Scope_Suppress : Suppress_Array := Suppress_Options; | |
375 | -- This array contains the current scope based settings of the suppress | |
376 | -- switches. It is initialized from the options as shown, and then modified | |
377 | -- by pragma Suppress. On entry to each scope, the current setting is saved | |
378 | -- the scope stack, and then restored on exit from the scope. This record | |
379 | -- may be rapidly checked to determine the current status of a check if | |
380 | -- no specific entity is involved or if the specific entity involved is | |
381 | -- one for which no specific Suppress/Unsuppress pragma has been set (as | |
382 | -- indicated by the Checks_May_Be_Suppressed flag being set). | |
383 | ||
384 | -- This scheme is a little complex, but serves the purpose of enabling | |
385 | -- a very rapid check in the common case where no entity specific pragma | |
386 | -- applies, and gives the right result when such pragmas are used even | |
387 | -- in complex cases of nested Suppress and Unsuppress pragmas. | |
388 | ||
389 | type Entity_Check_Suppress_Record is record | |
390 | Entity : Entity_Id; | |
391 | -- Entity to which the check applies, or Empty for a local check | |
392 | -- that has no entity name (and thus applies to all entities). | |
393 | ||
394 | Check : Check_Id; | |
395 | -- Check which is set (note this cannot be All_Checks, if the All_Checks | |
396 | -- case, a sequence of eentries appears for the individual checks. | |
397 | ||
398 | Suppress : Boolean; | |
399 | -- Set True for Suppress, and False for Unsuppress | |
400 | end record; | |
401 | ||
402 | -- The Local_Entity_Suppress table is a stack, to which new entries are | |
403 | -- added for Suppress and Unsuppress pragmas appearing in other than | |
404 | -- package specs. Such pragmas are effective only to the end of the scope | |
405 | -- in which they appear. This is achieved by marking the stack on entry | |
406 | -- to a scope and then cutting back the stack to that marked point on | |
407 | -- scope exit. | |
408 | ||
409 | package Local_Entity_Suppress is new Table.Table ( | |
410 | Table_Component_Type => Entity_Check_Suppress_Record, | |
411 | Table_Index_Type => Int, | |
412 | Table_Low_Bound => 0, | |
413 | Table_Initial => Alloc.Entity_Suppress_Initial, | |
414 | Table_Increment => Alloc.Entity_Suppress_Increment, | |
415 | Table_Name => "Local_Entity_Suppress"); | |
416 | ||
417 | -- The Global_Entity_Suppress table is used for entities which have | |
418 | -- a Suppress or Unsuppress pragma naming a specific entity in a | |
419 | -- package spec. Such pragmas always refer to entities in the package | |
420 | -- spec and are effective throughout the lifetime of the named entity. | |
421 | ||
422 | package Global_Entity_Suppress is new Table.Table ( | |
423 | Table_Component_Type => Entity_Check_Suppress_Record, | |
424 | Table_Index_Type => Int, | |
425 | Table_Low_Bound => 0, | |
426 | Table_Initial => Alloc.Entity_Suppress_Initial, | |
427 | Table_Increment => Alloc.Entity_Suppress_Increment, | |
428 | Table_Name => "Global_Entity_Suppress"); | |
996ae0b0 RK |
429 | |
430 | ----------------- | |
431 | -- Subprograms -- | |
432 | ----------------- | |
433 | ||
434 | procedure Initialize; | |
435 | -- Initialize internal tables | |
436 | ||
437 | procedure Lock; | |
438 | -- Lock internal tables before calling back end | |
439 | ||
440 | procedure Semantics (Comp_Unit : Node_Id); | |
441 | -- This procedure is called to perform semantic analysis on the specified | |
442 | -- node which is the N_Compilation_Unit node for the unit. | |
443 | ||
444 | procedure Analyze (N : Node_Id); | |
445 | procedure Analyze (N : Node_Id; Suppress : Check_Id); | |
446 | -- This is the recursive procedure which is applied to individual nodes | |
447 | -- of the tree, starting at the top level node (compilation unit node) | |
448 | -- and then moving down the tree in a top down traversal. It calls | |
449 | -- individual routines with names Analyze_xxx to analyze node xxx. Each | |
450 | -- of these routines is responsible for calling Analyze on the components | |
451 | -- of the subtree. | |
452 | -- | |
453 | -- Note: In the case of expression components (nodes whose Nkind is in | |
454 | -- N_Subexpr), the call to Analyze does not complete the semantic analysis | |
455 | -- of the node, since the type resolution cannot be completed until the | |
456 | -- complete context is analyzed. The completion of the type analysis occurs | |
457 | -- in the corresponding Resolve routine (see Sem_Res). | |
458 | -- | |
459 | -- Note: for integer and real literals, the analyzer sets the flag to | |
460 | -- indicate that the result is a static expression. If the expander | |
461 | -- generates a literal that does NOT correspond to a static expression, | |
462 | -- e.g. by folding an expression whose value is known at compile-time, | |
463 | -- but is not technically static, then the caller should reset the | |
464 | -- Is_Static_Expression flag after analyzing but before resolving. | |
465 | -- | |
466 | -- If the Suppress argument is present, then the analysis is done | |
467 | -- with the specified check suppressed (can be All_Checks to suppress | |
468 | -- all checks). | |
469 | ||
470 | procedure Analyze_List (L : List_Id); | |
471 | procedure Analyze_List (L : List_Id; Suppress : Check_Id); | |
472 | -- Analyzes each element of a list. If the Suppress argument is present, | |
473 | -- then the analysis is done with the specified check suppressed (can | |
474 | -- be All_Checks to suppress all checks). | |
475 | ||
fbf5a39b AC |
476 | procedure Copy_Suppress_Status |
477 | (C : Check_Id; | |
478 | From : Entity_Id; | |
479 | To : Entity_Id); | |
480 | -- If From is an entity for which check C is explicitly suppressed | |
481 | -- then also explicitly suppress the corresponding check in To. | |
482 | ||
996ae0b0 RK |
483 | procedure Insert_List_After_And_Analyze |
484 | (N : Node_Id; L : List_Id); | |
485 | procedure Insert_List_After_And_Analyze | |
486 | (N : Node_Id; L : List_Id; Suppress : Check_Id); | |
487 | -- Inserts list L after node N using Nlists.Insert_List_After, and then, | |
488 | -- after this insertion is complete, analyzes all the nodes in the list, | |
489 | -- including any additional nodes generated by this analysis. If the list | |
490 | -- is empty or be No_List, the call has no effect. If the Suppress | |
491 | -- argument is present, then the analysis is done with the specified | |
492 | -- check suppressed (can be All_Checks to suppress all checks). | |
493 | ||
494 | procedure Insert_List_Before_And_Analyze | |
495 | (N : Node_Id; L : List_Id); | |
496 | procedure Insert_List_Before_And_Analyze | |
497 | (N : Node_Id; L : List_Id; Suppress : Check_Id); | |
498 | -- Inserts list L before node N using Nlists.Insert_List_Before, and then, | |
499 | -- after this insertion is complete, analyzes all the nodes in the list, | |
500 | -- including any additional nodes generated by this analysis. If the list | |
501 | -- is empty or be No_List, the call has no effect. If the Suppress | |
502 | -- argument is present, then the analysis is done with the specified | |
503 | -- check suppressed (can be All_Checks to suppress all checks). | |
504 | ||
505 | procedure Insert_After_And_Analyze | |
506 | (N : Node_Id; M : Node_Id); | |
507 | procedure Insert_After_And_Analyze | |
508 | (N : Node_Id; M : Node_Id; Suppress : Check_Id); | |
509 | -- Inserts node M after node N and then after the insertion is complete, | |
510 | -- analyzes the inserted node and all nodes that are generated by | |
511 | -- this analysis. If the node is empty, the call has no effect. If the | |
512 | -- Suppress argument is present, then the analysis is done with the | |
513 | -- specified check suppressed (can be All_Checks to suppress all checks). | |
514 | ||
515 | procedure Insert_Before_And_Analyze | |
516 | (N : Node_Id; M : Node_Id); | |
517 | procedure Insert_Before_And_Analyze | |
518 | (N : Node_Id; M : Node_Id; Suppress : Check_Id); | |
519 | -- Inserts node M before node N and then after the insertion is complete, | |
520 | -- analyzes the inserted node and all nodes that could be generated by | |
521 | -- this analysis. If the node is empty, the call has no effect. If the | |
522 | -- Suppress argument is present, then the analysis is done with the | |
523 | -- specified check suppressed (can be All_Checks to suppress all checks). | |
524 | ||
525 | function External_Ref_In_Generic (E : Entity_Id) return Boolean; | |
526 | -- Return True if we are in the context of a generic and E is | |
527 | -- external (more global) to it. | |
528 | ||
529 | procedure Enter_Generic_Scope (S : Entity_Id); | |
530 | -- Shall be called each time a Generic subprogram or package scope is | |
531 | -- entered. S is the entity of the scope. | |
532 | -- ??? At the moment, only called for package specs because this mechanism | |
533 | -- is only used for avoiding freezing of external references in generics | |
534 | -- and this can only be an issue if the outer generic scope is a package | |
535 | -- spec (otherwise all external entities are already frozen) | |
536 | ||
537 | procedure Exit_Generic_Scope (S : Entity_Id); | |
538 | -- Shall be called each time a Generic subprogram or package scope is | |
539 | -- exited. S is the entity of the scope. | |
540 | -- ??? At the moment, only called for package specs exit. | |
541 | ||
fbf5a39b AC |
542 | function Explicit_Suppress (E : Entity_Id; C : Check_Id) return Boolean; |
543 | -- This function returns True if an explicit pragma Suppress for check C | |
544 | -- is present in the package defining E. | |
545 | ||
546 | function Is_Check_Suppressed (E : Entity_Id; C : Check_Id) return Boolean; | |
547 | -- This function is called if Checks_May_Be_Suppressed (E) is True to | |
548 | -- determine whether check C is suppressed either on the entity E or | |
549 | -- as the result of a scope suppress pragma. If Checks_May_Be_Suppressed | |
550 | -- is False, then the status of the check can be determined simply by | |
551 | -- examining Scope_Checks (C), so this routine is not called in that case. | |
552 | ||
996ae0b0 | 553 | end Sem; |