1 ------------------------------------------------------------------------------
3 -- GNAT COMPILER COMPONENTS --
11 -- Copyright (C) 1992-2001 Free Software Foundation, Inc. --
13 -- GNAT is free software; you can redistribute it and/or modify it under --
14 -- terms of the GNU General Public License as published by the Free Soft- --
15 -- ware Foundation; either version 2, or (at your option) any later ver- --
16 -- sion. GNAT is distributed in the hope that it will be useful, but WITH- --
17 -- OUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY --
18 -- or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License --
19 -- for more details. You should have received a copy of the GNU General --
20 -- Public License distributed with GNAT; see file COPYING. If not, write --
21 -- to the Free Software Foundation, 59 Temple Place - Suite 330, Boston, --
22 -- MA 02111-1307, USA. --
24 -- GNAT was originally developed by the GNAT team at New York University. --
25 -- It is now maintained by Ada Core Technologies Inc (http://www.gnat.com). --
27 ------------------------------------------------------------------------------
29 --------------------------------------
30 -- Semantic Analysis: General Model --
31 --------------------------------------
33 -- Semantic processing involves 3 phases which are highly interwined
34 -- (ie mutually recursive):
36 -- Analysis implements the bulk of semantic analysis such as
37 -- name analysis and type resolution for declarations,
38 -- instructions and expressions. The main routine
39 -- driving this process is procedure Analyze given below.
40 -- This analysis phase is really a bottom up pass that is
41 -- achieved during the recursive traversal performed by the
42 -- Analyze_... procedures implemented in the sem_* packages.
43 -- For expressions this phase determines unambiguous types
44 -- and collects sets of possible types where the
45 -- interpretation is potentially ambiguous.
47 -- Resolution is carried out only for expressions to finish type
48 -- resolution that was initiated but not necessarily
49 -- completed during analysis (because of overloading
50 -- ambiguities). Specifically, after completing the bottom
51 -- up pass carried out during analysis for expressions, the
52 -- Resolve routine (see the spec of sem_res for more info)
53 -- is called to perform a top down resolution with
54 -- recursive calls to itself to resolve operands.
56 -- Expansion if we are not generating code this phase is a no-op.
57 -- otherwise this phase expands, ie transforms, original
58 -- declaration, expressions or instructions into simpler
59 -- structures that can be handled by the back-end. This
60 -- phase is also in charge of generating code which is
61 -- implicit in the original source (for instance for
62 -- default initializations, controlled types, etc.)
63 -- There are two separate instances where expansion is
64 -- invoked. For declarations and instructions, expansion is
65 -- invoked just after analysis since no resolution needs
66 -- to be performed. For expressions, expansion is done just
67 -- after resolution. In both cases expansion is done from the
68 -- bottom up just before the end of Analyze for instructions
69 -- and declarations or the call to Resolve for expressions.
70 -- The main routine driving expansion is Expand.
71 -- See the spec of Expander for more details.
73 -- To summarize, in normal code generation mode we recursively traverse the
74 -- abstract syntax tree top-down performing semantic analysis bottom
75 -- up. For instructions and declarations, before the call to the Analyze
76 -- routine completes we perform expansion since at that point we have all
77 -- semantic information needed. For expression nodes, after the call to
78 -- Analysis terminates we invoke the Resolve routine to transmit top-down
79 -- the type that was gathered by Analyze which will resolve possible
80 -- ambiguities in the expression. Just before the call to Resolve
81 -- terminates, the expression can be expanded since all the semantic
82 -- information is available at that point.
84 -- If we are not generating code then the expansion phase is a no-op.
86 -- When generating code there are a number of exceptions to the basic
87 -- Analysis-Resolution-Expansion model for expressions. The most prominent
88 -- examples are the handling of default expressions and aggregates.
90 -------------------------------------
91 -- Handling of Default Expressions --
92 -------------------------------------
94 -- The default expressions in component declarations and in procedure
95 -- specifications (but not the ones in object declarations) are quite
96 -- tricky to handle. The problem is that some processing is required
97 -- at the point where the expression appears:
99 -- visibility analysis (including user defined operators)
100 -- freezing of static expressions
102 -- but other processing must be deferred until the enclosing entity
103 -- (record or procedure specification) is frozen:
105 -- freezing of any other types in the expression
108 -- Expansion has to be deferred since you can't generate code for
109 -- expressions that refernce types that have not been frozen yet. As an
110 -- example, consider the following:
112 -- type x is delta 0.5 range -10.0 .. +10.0;
118 -- for x'small use 0.25
120 -- The expander is in charge of dealing with fixed-point, and of course
121 -- the small declaration, which is not too late, since the declaration of
122 -- type q does *not* freeze type x, definitely affects the expanded code.
124 -- Generally our model is to combine analysis resolution and expansion, but
125 -- this is the one case where this model falls down. Here is how we patch
126 -- it up without causing too much distortion to our basic model.
128 -- A switch (sede below) is set to indicate that we are in the initial
129 -- occurence of a default expression. The analyzer is then called on this
130 -- expression with the switch set true. Analysis and resolution proceed
131 -- almost as usual, except that Freeze_Expression will not freeze
132 -- non-static expressions if this switch is set, and the call to Expand at
133 -- the end of resolution is skipped. This also skips the code that normally
134 -- sets the Analyzed flag to True). The result is that when we are done the
135 -- tree is still marked as unanalyzed, but all types for static expressions
136 -- are frozen as required, and all entities of variables have been
137 -- recorded. We then turn off the switch, and later on reanalyze the
138 -- expression with the switch off. The effect is that this second analysis
139 -- freezes the rest of the types as required, and generates code but
140 -- visibility analysis is not repeated since all the entities are marked.
142 -- The second analysis (the one that generates code) is in the context
143 -- where the code is required. For a record field default, this is in
144 -- the initialization procedure for the record and for a subprogram
145 -- default parameter, it is at the point the subprogram is frozen.
151 -- For certain kind of expressions, such as aggregates, we need to defer
152 -- expansion of the aggregate and its inner expressions after the whole
153 -- set of expressions appearing inside the aggregate have been analyzed.
154 -- Consider, for instance the following example:
156 -- (1 .. 100 => new Thing (Function_Call))
158 -- The normal Analysis-Resolution-Expansion mechanism where expansion
159 -- of the children is performed before expansion of the parent does not
160 -- work if the code generated for the children by the expander needs
161 -- to be evaluated repeatdly (for instance in the above aggregate
162 -- "new Thing (Function_Call)" needs to be called 100 times.)
163 -- The reason why this mecanism does not work is that, the expanded code
164 -- for the children is typically inserted above the parent and thus
165 -- when the father gets expanded no re-evaluation takes place. For instance
166 -- in the case of aggregates if "new Thing (Function_Call)" is expanded
167 -- before of the aggregate the expanded code will be placed outside
168 -- of the aggregate and when expanding the aggregate the loop from 1 to 100
169 -- will not surround the expanded code for "new Thing (Function_Call)".
171 -- To remedy this situation we introduce a new flag which signals whether
172 -- we want a full analysis (ie expansion is enabled) or a pre-analysis
173 -- which performs Analysis and Resolution but no expansion.
175 -- After the complete pre-analysis of an expression has been carried out
176 -- we can transform the expression and then carry out the full
177 -- Analyze-Resolve-Expand cycle on the transformed expression top-down
178 -- so that the expansion of inner expressions happens inside the newly
179 -- generated node for the parent expression.
181 -- Note that the difference between processing of default expressions and
182 -- pre-analysis of other expressions is that we do carry out freezing in
183 -- the latter but not in the former (except for static scalar expressions).
184 -- The routine that performs pre-analysis is called Pre_Analyze_And_Resolve
185 -- and is in Sem_Res.
188 with Einfo; use Einfo;
190 with Snames; use Snames;
192 with Types; use Types;
196 New_Nodes_OK : Int := 1;
197 -- Temporary flag for use in checking out HLO. Set non-zero if it is
198 -- OK to generate new nodes.
200 -----------------------------
201 -- Semantic Analysis Flags --
202 -----------------------------
204 Full_Analysis : Boolean := True;
205 -- Switch to indicate whether we are doing a full analysis or a
206 -- pre-analysis. In normal analysis mode (Analysis-Expansion for
207 -- instructions or declarations) or (Analysis-Resolution-Expansion for
208 -- expressions) this flag is set. Note that if we are not generating
209 -- code the expansion phase merely sets the Analyzed flag to True in
210 -- this case. If we are in Pre-Analysis mode (see above) this flag is
211 -- set to False then the expansion phase is skipped.
212 -- When this flag is False the flag Expander_Active is also False
213 -- (the Expander_Activer flag defined in the spec of package Expander
214 -- tells you whether expansion is currently enabled).
215 -- You should really regard this as a read only flag.
217 In_Default_Expression : Boolean := False;
218 -- Switch to indicate that we are in a default expression, as described
219 -- above. Note that this must be recursively saved on a Semantics call
220 -- since it is possible for the analysis of an expression to result in
221 -- a recursive call (e.g. to get the entity for System.Address as part
222 -- of the processing of an Address attribute reference).
223 -- When this switch is True then Full_Analysis above must be False.
224 -- You should really regard this as a read only flag.
226 In_Inlined_Body : Boolean := False;
227 -- Switch to indicate that we are analyzing and resolving an inlined
228 -- body. Type checking is disabled in this context, because types are
229 -- known to be compatible. This avoids problems with private types whose
230 -- full view is derived from private types.
232 Inside_A_Generic : Boolean := False;
233 -- This flag is set if we are processing a generic specification,
234 -- generic definition, or generic body. When this flag is True the
235 -- Expander_Active flag is False to disable any code expansion (see
236 -- package Expander). Only the generic processing can modify the
237 -- status of this flag, any other client should regard it as read-only.
239 Unloaded_Subunits : Boolean := False;
240 -- This flag is set True if we have subunits that are not loaded. This
241 -- occurs when the main unit is a subunit, and contains lower level
242 -- subunits that are not loaded. We use this flag to suppress warnings
243 -- about unused variables, since these warnings are unreliable in this
244 -- case. We could perhaps do a more accurate job and retain some of the
245 -- warnings, but it is quite a tricky job. See test 4323-002.
251 Scope_Suppress : Suppress_Record := Suppress_Options;
252 -- This record contains the current scope based settings of the suppress
253 -- switches. It is initialized from the options as shown, and then modified
254 -- by pragma Suppress. On entry to each scope, the current setting is saved
255 -- the scope stack, and then restored on exit from the scope.
257 -- The scope stack holds all entries of the scope table. As in the parser,
258 -- we use Last as the stack pointer, so that we can always find the scope
259 -- that is currently open in Scope_Stack.Table (Scope_Stack.Last). The
260 -- oldest entry, at Scope_Stack (0) is Standard. The entries in the table
261 -- include the entity for the referenced scope, together with information
262 -- used to restore the proper setting of check suppressions on scope exit.
264 -- There are two kinds of suppress checks, scope based suppress checks
265 -- (from initial command line arguments, or from Suppress pragmas not
266 -- including an entity name). The scope based suppress checks are recorded
267 -- in the Sem.Supress variable, and all that is necessary is to save the
268 -- state of this variable on scope entry, and restore it on scope exit.
270 -- The other kind of suppress check is entity based suppress checks, from
271 -- Suppress pragmas giving an Entity_Id. These checks are reflected by the
272 -- appropriate bit being set in the corresponding entity, and restoring the
273 -- setting of these bits is a little trickier. In particular a given pragma
274 -- Suppress may or may not affect the current state. If it sets a check for
275 -- an entity that is already checked, then it is important that this check
276 -- not be restored on scope exit. The situation is made more complicated
277 -- by the fact that a given suppress pragma can specify multiple entities
278 -- (in the overloaded case), and multiple checks (by using All_Checks), so
279 -- that it may be partially effective. On exit only checks that were in
280 -- fact effective must be removed. Logically we could do this by saving
281 -- the entire state of the entity flags on scope entry and restoring them
282 -- on scope exit, but that would be ludicrous, so what we do instead is to
283 -- maintain the following differential structure that shows what checks
284 -- were installed for the current scope.
286 -- Note: Suppress pragmas that specify entities defined in a package
287 -- spec do not make entries in this table, since such checks suppress
288 -- requests are valid for the entire life of the entity.
290 type Entity_Check_Suppress_Record is record
292 -- Entity to which the check applies
295 -- Check which is set (note this cannot be All_Checks, if the All_Checks
296 -- case, a sequence of eentries appears for the individual checks.
299 -- Entity_Suppress is a stack, to which new entries are added as they
300 -- are processed (see pragma Suppress circuit in Sem_Prag). The scope
301 -- stack entry simply saves the stack pointer on entry, and restores
302 -- it on exit by reversing the checks one by one.
304 package Entity_Suppress is new Table.Table (
305 Table_Component_Type => Entity_Check_Suppress_Record,
306 Table_Index_Type => Int,
307 Table_Low_Bound => 0,
308 Table_Initial => Alloc.Entity_Suppress_Initial,
309 Table_Increment => Alloc.Entity_Suppress_Increment,
310 Table_Name => "Entity_Suppress");
312 -- Here is the scope stack itself
314 type Scope_Stack_Entry is record
316 -- Entity representing the scope
318 Last_Subprogram_Name : String_Ptr;
319 -- Pointer to name of last subprogram body in this scope. Used for
320 -- testing proper alpha ordering of subprogram bodies in scope.
322 Save_Scope_Suppress : Suppress_Record;
323 -- Save contents of Scope_Suppress on entry
325 Save_Entity_Suppress : Int;
326 -- Save contents of Entity_Suppress.Last on entry
328 Is_Transient : Boolean;
329 -- Marks Transient Scopes (See Exp_Ch7 body for details)
331 Previous_Visibility : Boolean;
332 -- Used when installing the parent (s) of the current compilation
333 -- unit. The parent may already be visible because of an ongoing
334 -- compilation, and the proper visibility must be restored on exit.
336 Node_To_Be_Wrapped : Node_Id;
337 -- Only used in transient scopes. Records the node which will
338 -- be wrapped by the transient block.
340 Actions_To_Be_Wrapped_Before : List_Id;
341 Actions_To_Be_Wrapped_After : List_Id;
342 -- Actions that have to be inserted at the start or at the end of a
343 -- transient block. Used to temporarily hold these actions until the
344 -- block is created, at which time the actions are moved to the
347 Pending_Freeze_Actions : List_Id;
348 -- Used to collect freeze entity nodes and associated actions that
349 -- are generated in a inner context but need to be analyzed outside,
350 -- such as records and initialization procedures. On exit from the
351 -- scope, this list of actions is inserted before the scope construct
352 -- and analyzed to generate the corresponding freeze processing and
353 -- elaboration of other associated actions.
355 First_Use_Clause : Node_Id;
356 -- Head of list of Use_Clauses in current scope. The list is built
357 -- when the declarations in the scope are processed. The list is
358 -- traversed on scope exit to undo the effect of the use clauses.
360 Component_Alignment_Default : Component_Alignment_Kind;
361 -- Component alignment to be applied to any record or array types
362 -- that are declared for which a specific component alignment pragma
363 -- does not set the alignment.
365 Is_Active_Stack_Base : Boolean;
366 -- Set to true only when entering the scope for Standard_Standard from
367 -- from within procedure Semantics. Indicates the base of the current
368 -- active set of scopes. Needed by In_Open_Scopes to handle cases
369 -- where Standard_Standard can be pushed in the middle of the active
370 -- set of scopes (occurs for instantiations of generic child units).
373 package Scope_Stack is new Table.Table (
374 Table_Component_Type => Scope_Stack_Entry,
375 Table_Index_Type => Int,
376 Table_Low_Bound => 0,
377 Table_Initial => Alloc.Scope_Stack_Initial,
378 Table_Increment => Alloc.Scope_Stack_Increment,
379 Table_Name => "Sem.Scope_Stack");
381 function Get_Scope_Suppress (C : Check_Id) return Boolean;
382 -- Get suppress status of check C for the current scope
384 procedure Set_Scope_Suppress (C : Check_Id; B : Boolean);
385 -- Set suppress status of check C for the current scope
391 procedure Initialize;
392 -- Initialize internal tables
395 -- Lock internal tables before calling back end
397 procedure Semantics (Comp_Unit : Node_Id);
398 -- This procedure is called to perform semantic analysis on the specified
399 -- node which is the N_Compilation_Unit node for the unit.
401 procedure Analyze (N : Node_Id);
402 procedure Analyze (N : Node_Id; Suppress : Check_Id);
403 -- This is the recursive procedure which is applied to individual nodes
404 -- of the tree, starting at the top level node (compilation unit node)
405 -- and then moving down the tree in a top down traversal. It calls
406 -- individual routines with names Analyze_xxx to analyze node xxx. Each
407 -- of these routines is responsible for calling Analyze on the components
410 -- Note: In the case of expression components (nodes whose Nkind is in
411 -- N_Subexpr), the call to Analyze does not complete the semantic analysis
412 -- of the node, since the type resolution cannot be completed until the
413 -- complete context is analyzed. The completion of the type analysis occurs
414 -- in the corresponding Resolve routine (see Sem_Res).
416 -- Note: for integer and real literals, the analyzer sets the flag to
417 -- indicate that the result is a static expression. If the expander
418 -- generates a literal that does NOT correspond to a static expression,
419 -- e.g. by folding an expression whose value is known at compile-time,
420 -- but is not technically static, then the caller should reset the
421 -- Is_Static_Expression flag after analyzing but before resolving.
423 -- If the Suppress argument is present, then the analysis is done
424 -- with the specified check suppressed (can be All_Checks to suppress
427 procedure Analyze_List (L : List_Id);
428 procedure Analyze_List (L : List_Id; Suppress : Check_Id);
429 -- Analyzes each element of a list. If the Suppress argument is present,
430 -- then the analysis is done with the specified check suppressed (can
431 -- be All_Checks to suppress all checks).
433 procedure Insert_List_After_And_Analyze
434 (N : Node_Id; L : List_Id);
435 procedure Insert_List_After_And_Analyze
436 (N : Node_Id; L : List_Id; Suppress : Check_Id);
437 -- Inserts list L after node N using Nlists.Insert_List_After, and then,
438 -- after this insertion is complete, analyzes all the nodes in the list,
439 -- including any additional nodes generated by this analysis. If the list
440 -- is empty or be No_List, the call has no effect. If the Suppress
441 -- argument is present, then the analysis is done with the specified
442 -- check suppressed (can be All_Checks to suppress all checks).
444 procedure Insert_List_Before_And_Analyze
445 (N : Node_Id; L : List_Id);
446 procedure Insert_List_Before_And_Analyze
447 (N : Node_Id; L : List_Id; Suppress : Check_Id);
448 -- Inserts list L before node N using Nlists.Insert_List_Before, and then,
449 -- after this insertion is complete, analyzes all the nodes in the list,
450 -- including any additional nodes generated by this analysis. If the list
451 -- is empty or be No_List, the call has no effect. If the Suppress
452 -- argument is present, then the analysis is done with the specified
453 -- check suppressed (can be All_Checks to suppress all checks).
455 procedure Insert_After_And_Analyze
456 (N : Node_Id; M : Node_Id);
457 procedure Insert_After_And_Analyze
458 (N : Node_Id; M : Node_Id; Suppress : Check_Id);
459 -- Inserts node M after node N and then after the insertion is complete,
460 -- analyzes the inserted node and all nodes that are generated by
461 -- this analysis. If the node is empty, the call has no effect. If the
462 -- Suppress argument is present, then the analysis is done with the
463 -- specified check suppressed (can be All_Checks to suppress all checks).
465 procedure Insert_Before_And_Analyze
466 (N : Node_Id; M : Node_Id);
467 procedure Insert_Before_And_Analyze
468 (N : Node_Id; M : Node_Id; Suppress : Check_Id);
469 -- Inserts node M before node N and then after the insertion is complete,
470 -- analyzes the inserted node and all nodes that could be generated by
471 -- this analysis. If the node is empty, the call has no effect. If the
472 -- Suppress argument is present, then the analysis is done with the
473 -- specified check suppressed (can be All_Checks to suppress all checks).
475 function External_Ref_In_Generic (E : Entity_Id) return Boolean;
476 -- Return True if we are in the context of a generic and E is
477 -- external (more global) to it.
479 procedure Enter_Generic_Scope (S : Entity_Id);
480 -- Shall be called each time a Generic subprogram or package scope is
481 -- entered. S is the entity of the scope.
482 -- ??? At the moment, only called for package specs because this mechanism
483 -- is only used for avoiding freezing of external references in generics
484 -- and this can only be an issue if the outer generic scope is a package
485 -- spec (otherwise all external entities are already frozen)
487 procedure Exit_Generic_Scope (S : Entity_Id);
488 -- Shall be called each time a Generic subprogram or package scope is
489 -- exited. S is the entity of the scope.
490 -- ??? At the moment, only called for package specs exit.
projects / platform / upstream / gcc.git / blob