1 ------------------------------------------------------------------------------
3 -- GNAT COMPILER COMPONENTS --
9 -- Copyright (C) 1992-2007, Free Software Foundation, Inc. --
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, 51 Franklin Street, Fifth Floor, --
20 -- Boston, MA 02110-1301, USA. --
22 -- GNAT was originally developed by the GNAT team at New York University. --
23 -- Extensive contributions were provided by Ada Core Technologies Inc. --
25 ------------------------------------------------------------------------------
27 --------------------------------------
28 -- Semantic Analysis: General Model --
29 --------------------------------------
31 -- Semantic processing involves 3 phases which are highly interwined
32 -- (ie mutually recursive):
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.
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.
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.
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.
82 -- If we are not generating code then the expansion phase is a no-op
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.
88 ----------------------------------------------------
89 -- Handling of Default and Per-Object Expressions --
90 ----------------------------------------------------
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:
97 -- visibility analysis (including user defined operators)
98 -- freezing of static expressions
100 -- but other processing must be deferred until the enclosing entity
101 -- (record or procedure specification) is frozen:
103 -- freezing of any other types in the expression
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)).
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:
114 -- type x is delta 0.5 range -10.0 .. +10.0;
120 -- for x'small use 0.25
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.
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
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.
136 -- A switch (sede below) is set to indicate that we are in the initial
137 -- occurence of a default expression. The analyzer is then called on this
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.
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.
154 -- For a priority or storage size pragma it is in the context of the
155 -- Init_Proc for the task or protected object.
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:
166 -- (1 .. 100 => new Thing (Function_Call))
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)".
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.
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.
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.
198 with Einfo; use Einfo;
201 with Types; use Types;
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.
209 -----------------------------
210 -- Semantic Analysis Flags --
211 -----------------------------
213 Full_Analysis : Boolean := True;
214 -- Switch to indicate if we are doing a full analysis or a pre-analysis.
215 -- In normal analysis mode (Analysis-Expansion for instructions or
216 -- declarations) or (Analysis-Resolution-Expansion for expressions) this
217 -- flag is set. Note that if we are not generating code the expansion phase
218 -- merely sets the Analyzed flag to True in this case. If we are in
219 -- Pre-Analysis mode (see above) this flag is set to False then the
220 -- expansion phase is skipped.
222 -- When this flag is False the flag Expander_Active is also False (the
223 -- Expander_Activer flag defined in the spec of package Expander tells you
224 -- whether expansion is currently enabled). You should really regard this
225 -- as a read only flag.
227 In_Default_Expression : Boolean := False;
228 -- Switch to indicate that we are in a default expression, as described
229 -- above. Note that this must be recursively saved on a Semantics call
230 -- since it is possible for the analysis of an expression to result in a
231 -- recursive call (e.g. to get the entity for System.Address as part of the
232 -- processing of an Address attribute reference). When this switch is True
233 -- then Full_Analysis above must be False. You should really regard this as
236 In_Deleted_Code : Boolean := False;
237 -- If the condition in an if-statement is statically known, the branch
238 -- that is not taken is analyzed with expansion disabled, and the tree
239 -- is deleted after analysis. Itypes generated in deleted code must be
240 -- frozen from start, because the tree on which they depend will not
241 -- be available at the freeze point.
243 In_Inlined_Body : Boolean := False;
244 -- Switch to indicate that we are analyzing and resolving an inlined
245 -- body. Type checking is disabled in this context, because types are
246 -- known to be compatible. This avoids problems with private types whose
247 -- full view is derived from private types.
249 Inside_A_Generic : Boolean := False;
250 -- This flag is set if we are processing a generic specification,
251 -- generic definition, or generic body. When this flag is True the
252 -- Expander_Active flag is False to disable any code expansion (see
253 -- package Expander). Only the generic processing can modify the
254 -- status of this flag, any other client should regard it as read-only.
256 Unloaded_Subunits : Boolean := False;
257 -- This flag is set True if we have subunits that are not loaded. This
258 -- occurs when the main unit is a subunit, and contains lower level
259 -- subunits that are not loaded. We use this flag to suppress warnings
260 -- about unused variables, since these warnings are unreliable in this
261 -- case. We could perhaps do a more accurate job and retain some of the
262 -- warnings, but it is quite a tricky job. See test 4323-002.
263 -- Should not reference TN's in the source comments ???
265 -----------------------------------
266 -- Handling of Check Suppression --
267 -----------------------------------
269 -- There are two kinds of suppress checks: scope based suppress checks,
270 -- and entity based suppress checks.
272 -- Scope based suppress checks for the predefined checks (from initial
273 -- command line arguments, or from Suppress pragmas not including an entity
274 -- entity name) are recorded in the Sem.Supress variable, and all that is
275 -- necessary is to save the state of this variable on scope entry, and
276 -- restore it on scope exit. This mechanism allows for fast checking of
277 -- the scope suppress state without needing complex data structures.
279 -- Entity based checks, from Suppress/Unsuppress pragmas giving an
280 -- Entity_Id and scope based checks for non-predefined checks (introduced
281 -- using pragma Check_Name), are handled as follows. If a suppress or
282 -- unsuppress pragma is encountered for a given entity, then the flag
283 -- Checks_May_Be_Suppressed is set in the entity and an entry is made in
284 -- either the Local_Entity_Suppress stack (case of pragma that appears in
285 -- other than a package spec), or in the Global_Entity_Suppress stack (case
286 -- of pragma that appears in a package spec, which is by the rule of RM
287 -- 11.5(7) applicable throughout the life of the entity). Similarly, a
288 -- Suppress/Unsuppress pragma for a non-predefined check which does not
289 -- specify an entity is also stored in one of these stacks.
291 -- If the Checks_May_Be_Suppressed flag is set in an entity then the
292 -- procedure is to search first the local and then the global suppress
293 -- stacks (we search these in reverse order, top element first). The only
294 -- other point is that we have to make sure that we have proper nested
295 -- interaction between such specific pragmas and locally applied general
296 -- pragmas applying to all entities. This is achieved by including in the
297 -- Local_Entity_Suppress table dummy entries with an empty Entity field
298 -- that are applicable to all entities. A similar search is needed for any
299 -- non-predefined check even if no specific entity is involved.
301 Scope_Suppress : Suppress_Array := Suppress_Options;
302 -- This array contains the current scope based settings of the suppress
303 -- switches. It is initialized from the options as shown, and then modified
304 -- by pragma Suppress. On entry to each scope, the current setting is saved
305 -- the scope stack, and then restored on exit from the scope. This record
306 -- may be rapidly checked to determine the current status of a check if
307 -- no specific entity is involved or if the specific entity involved is
308 -- one for which no specific Suppress/Unsuppress pragma has been set (as
309 -- indicated by the Checks_May_Be_Suppressed flag being set).
311 -- This scheme is a little complex, but serves the purpose of enabling
312 -- a very rapid check in the common case where no entity specific pragma
313 -- applies, and gives the right result when such pragmas are used even
314 -- in complex cases of nested Suppress and Unsuppress pragmas.
316 -- The Local_Entity_Suppress and Global_Entity_Suppress stacks are handled
317 -- using dynamic allocation and linked lists. We do not often use this
318 -- approach in the compiler (preferring to use extensible tables instead).
319 -- The reason we do it here is that scope stack entries save a pointer to
320 -- the current local stack top, which is also saved and restored on scope
321 -- exit. Furthermore for processing of generics we save pointers to the
322 -- top of the stack, so that the local stack is actually a tree of stacks
323 -- rather than a single stack, a structure that is easy to represent using
324 -- linked lists, but impossible to represent using a single table. Note
325 -- that because of the generic issue, we never release entries in these
326 -- stacks, but that's no big deal, since we are unlikely to have a huge
327 -- number of Suppress/Unsuppress entries in a single compilation.
329 type Suppress_Stack_Entry;
330 type Suppress_Stack_Entry_Ptr is access all Suppress_Stack_Entry;
332 type Suppress_Stack_Entry is record
334 -- Entity to which the check applies, or Empty for a check that has
335 -- no entity name (and thus applies to all entities).
338 -- Check which is set (can be All_Checks for the All_Checks case)
341 -- Set True for Suppress, and False for Unsuppress
343 Prev : Suppress_Stack_Entry_Ptr;
344 -- Pointer to previous entry on stack
346 Next : Suppress_Stack_Entry_Ptr;
347 -- All allocated Suppress_Stack_Entry records are chained together in
348 -- a linked list whose head is Suppress_Stack_Entries, and the Next
349 -- field is used as a forward pointer (null ends the list). This is
350 -- used to free all entries in Sem.Init (which will be important if
351 -- we ever setup the compiler to be reused).
354 Suppress_Stack_Entries : Suppress_Stack_Entry_Ptr := null;
355 -- Pointer to linked list of records (see comments for Next above)
357 Local_Suppress_Stack_Top : Suppress_Stack_Entry_Ptr;
358 -- Pointer to top element of local suppress stack. This is the entry that
359 -- is saved and restored in the scope stack, and also saved for generic
362 Global_Suppress_Stack_Top : Suppress_Stack_Entry_Ptr;
363 -- Pointer to top element of global suppress stack
365 procedure Push_Local_Suppress_Stack_Entry
369 -- Push a new entry on to the top of the local suppress stack, updating
370 -- the value in Local_Suppress_Stack_Top;
372 procedure Push_Global_Suppress_Stack_Entry
376 -- Push a new entry on to the top of the global suppress stack, updating
377 -- the value in Global_Suppress_Stack_Top;
383 -- The scope stack indicates the declarative regions that are currently
384 -- being processed (analyzed and/or expanded). The scope stack is one of
385 -- basic visibility structures in the compiler: entities that are declared
386 -- in a scope that is currently on the scope stack are immediately visible.
387 -- (leaving aside issues of hiding and overloading).
389 -- Initially, the scope stack only contains an entry for package Standard.
390 -- When a compilation unit, subprogram unit, block or declarative region
391 -- is being processed, the corresponding entity is pushed on the scope
392 -- stack. It is removed after the processing step is completed. A given
393 -- entity can be placed several times on the scope stack, for example
394 -- when processing derived type declarations, freeze nodes, etc. The top
395 -- of the scope stack is the innermost scope currently being processed.
396 -- It is obtained through function Current_Scope. After a compilation unit
397 -- has been processed, the scope stack must contain only Standard.
398 -- The predicate In_Open_Scopes specifies whether a scope is currently
399 -- on the scope stack.
401 -- This model is complicated by the need to compile units on the fly, in
402 -- the middle of the compilation of other units. This arises when compiling
403 -- instantiations, and when compiling run-time packages obtained through
404 -- rtsfind. Given that the scope stack is a single static and global
405 -- structure (not originally designed for the recursive processing required
406 -- by rtsfind for example) additional machinery is needed to indicate what
407 -- is currently being compiled. As a result, the scope stack holds several
408 -- contiguous sections that correspond to the compilation of a given
409 -- compilation unit. These sections are separated by distinct occurrences
410 -- of package Standard. The currently active section of the scope stack
411 -- goes from the current scope to the first occurrence of Standard, which
412 -- is additionally marked with the flag Is_Active_Stack_Base. The basic
413 -- visibility routine (Find_Direct_Name, sem_ch8) uses this contiguous
414 -- section of the scope stack to determine whether a given entity is or
415 -- is not visible at a point. In_Open_Scopes only examines the currently
416 -- active section of the scope stack.
418 -- Similar complications arise when processing child instances. These
419 -- must be compiled in the context of parent instances, and therefore the
420 -- parents must be pushed on the stack before compiling the child, and
421 -- removed afterwards. Routines Save_Scope_Stack and Restore_Scope_Stack
422 -- are used to set/reset the visibility of entities declared in scopes
423 -- that are currently on the scope stack, and are used when compiling
424 -- instance bodies on the fly.
426 -- It is clear in retrospect that all semantic processing and visibility
427 -- structures should have been fully recursive. The rtsfind mechanism,
428 -- and the complexities brought about by subunits and by generic child
429 -- units and their instantitions, have led to a hybrid model that carries
430 -- more state than one would wish.
432 type Scope_Stack_Entry is record
434 -- Entity representing the scope
436 Last_Subprogram_Name : String_Ptr;
437 -- Pointer to name of last subprogram body in this scope. Used for
438 -- testing proper alpha ordering of subprogram bodies in scope.
440 Save_Scope_Suppress : Suppress_Array;
441 -- Save contents of Scope_Suppress on entry
443 Save_Local_Suppress_Stack_Top : Suppress_Stack_Entry_Ptr;
444 -- Save contents of Local_Suppress_Stack on entry to restore on exit
446 Is_Transient : Boolean;
447 -- Marks Transient Scopes (See Exp_Ch7 body for details)
449 Previous_Visibility : Boolean;
450 -- Used when installing the parent(s) of the current compilation unit.
451 -- The parent may already be visible because of an ongoing compilation,
452 -- and the proper visibility must be restored on exit. The flag is
453 -- typically needed when the context of a child unit requires
454 -- compilation of a sibling. In other cases the flag is set to False.
455 -- See Sem_Ch10 (Install_Parents, Remove_Parents).
457 Node_To_Be_Wrapped : Node_Id;
458 -- Only used in transient scopes. Records the node which will
459 -- be wrapped by the transient block.
461 Actions_To_Be_Wrapped_Before : List_Id;
462 Actions_To_Be_Wrapped_After : List_Id;
463 -- Actions that have to be inserted at the start or at the end of a
464 -- transient block. Used to temporarily hold these actions until the
465 -- block is created, at which time the actions are moved to the block.
467 Pending_Freeze_Actions : List_Id;
468 -- Used to collect freeze entity nodes and associated actions that are
469 -- generated in a inner context but need to be analyzed outside, such as
470 -- records and initialization procedures. On exit from the scope, this
471 -- list of actions is inserted before the scope construct and analyzed
472 -- to generate the corresponding freeze processing and elaboration of
473 -- other associated actions.
475 First_Use_Clause : Node_Id;
476 -- Head of list of Use_Clauses in current scope. The list is built when
477 -- the declarations in the scope are processed. The list is traversed
478 -- on scope exit to undo the effect of the use clauses.
480 Component_Alignment_Default : Component_Alignment_Kind;
481 -- Component alignment to be applied to any record or array types that
482 -- are declared for which a specific component alignment pragma does not
483 -- set the alignment.
485 Is_Active_Stack_Base : Boolean;
486 -- Set to true only when entering the scope for Standard_Standard from
487 -- from within procedure Semantics. Indicates the base of the current
488 -- active set of scopes. Needed by In_Open_Scopes to handle cases where
489 -- Standard_Standard can be pushed anew on the scope stack to start a
490 -- new active section (see comment above).
494 package Scope_Stack is new Table.Table (
495 Table_Component_Type => Scope_Stack_Entry,
496 Table_Index_Type => Int,
497 Table_Low_Bound => 0,
498 Table_Initial => Alloc.Scope_Stack_Initial,
499 Table_Increment => Alloc.Scope_Stack_Increment,
500 Table_Name => "Sem.Scope_Stack");
506 procedure Initialize;
507 -- Initialize internal tables
510 -- Lock internal tables before calling back end
512 procedure Semantics (Comp_Unit : Node_Id);
513 -- This procedure is called to perform semantic analysis on the specified
514 -- node which is the N_Compilation_Unit node for the unit.
516 procedure Analyze (N : Node_Id);
517 procedure Analyze (N : Node_Id; Suppress : Check_Id);
518 -- This is the recursive procedure which is applied to individual nodes
519 -- of the tree, starting at the top level node (compilation unit node)
520 -- and then moving down the tree in a top down traversal. It calls
521 -- individual routines with names Analyze_xxx to analyze node xxx. Each
522 -- of these routines is responsible for calling Analyze on the components
525 -- Note: In the case of expression components (nodes whose Nkind is in
526 -- N_Subexpr), the call to Analyze does not complete the semantic analysis
527 -- of the node, since the type resolution cannot be completed until the
528 -- complete context is analyzed. The completion of the type analysis occurs
529 -- in the corresponding Resolve routine (see Sem_Res).
531 -- Note: for integer and real literals, the analyzer sets the flag to
532 -- indicate that the result is a static expression. If the expander
533 -- generates a literal that does NOT correspond to a static expression,
534 -- e.g. by folding an expression whose value is known at compile-time,
535 -- but is not technically static, then the caller should reset the
536 -- Is_Static_Expression flag after analyzing but before resolving.
538 -- If the Suppress argument is present, then the analysis is done
539 -- with the specified check suppressed (can be All_Checks to suppress
542 procedure Analyze_List (L : List_Id);
543 procedure Analyze_List (L : List_Id; Suppress : Check_Id);
544 -- Analyzes each element of a list. If the Suppress argument is present,
545 -- then the analysis is done with the specified check suppressed (can
546 -- be All_Checks to suppress all checks).
548 procedure Copy_Suppress_Status
552 -- If From is an entity for which check C is explicitly suppressed
553 -- then also explicitly suppress the corresponding check in To.
555 procedure Insert_List_After_And_Analyze
556 (N : Node_Id; L : List_Id);
557 procedure Insert_List_After_And_Analyze
558 (N : Node_Id; L : List_Id; Suppress : Check_Id);
559 -- Inserts list L after node N using Nlists.Insert_List_After, and then,
560 -- after this insertion is complete, analyzes all the nodes in the list,
561 -- including any additional nodes generated by this analysis. If the list
562 -- is empty or be No_List, the call has no effect. If the Suppress
563 -- argument is present, then the analysis is done with the specified
564 -- check suppressed (can be All_Checks to suppress all checks).
566 procedure Insert_List_Before_And_Analyze
567 (N : Node_Id; L : List_Id);
568 procedure Insert_List_Before_And_Analyze
569 (N : Node_Id; L : List_Id; Suppress : Check_Id);
570 -- Inserts list L before node N using Nlists.Insert_List_Before, and then,
571 -- after this insertion is complete, analyzes all the nodes in the list,
572 -- including any additional nodes generated by this analysis. If the list
573 -- is empty or be No_List, the call has no effect. If the Suppress
574 -- argument is present, then the analysis is done with the specified
575 -- check suppressed (can be All_Checks to suppress all checks).
577 procedure Insert_After_And_Analyze
578 (N : Node_Id; M : Node_Id);
579 procedure Insert_After_And_Analyze
580 (N : Node_Id; M : Node_Id; Suppress : Check_Id);
581 -- Inserts node M after node N and then after the insertion is complete,
582 -- analyzes the inserted node and all nodes that are generated by
583 -- this analysis. If the node is empty, the call has no effect. If the
584 -- Suppress argument is present, then the analysis is done with the
585 -- specified check suppressed (can be All_Checks to suppress all checks).
587 procedure Insert_Before_And_Analyze
588 (N : Node_Id; M : Node_Id);
589 procedure Insert_Before_And_Analyze
590 (N : Node_Id; M : Node_Id; Suppress : Check_Id);
591 -- Inserts node M before node N and then after the insertion is complete,
592 -- analyzes the inserted node and all nodes that could be generated by
593 -- this analysis. If the node is empty, the call has no effect. If the
594 -- Suppress argument is present, then the analysis is done with the
595 -- specified check suppressed (can be All_Checks to suppress all checks).
597 function External_Ref_In_Generic (E : Entity_Id) return Boolean;
598 -- Return True if we are in the context of a generic and E is
599 -- external (more global) to it.
601 procedure Enter_Generic_Scope (S : Entity_Id);
602 -- Shall be called each time a Generic subprogram or package scope is
603 -- entered. S is the entity of the scope.
604 -- ??? At the moment, only called for package specs because this mechanism
605 -- is only used for avoiding freezing of external references in generics
606 -- and this can only be an issue if the outer generic scope is a package
607 -- spec (otherwise all external entities are already frozen)
609 procedure Exit_Generic_Scope (S : Entity_Id);
610 -- Shall be called each time a Generic subprogram or package scope is
611 -- exited. S is the entity of the scope.
612 -- ??? At the moment, only called for package specs exit.
614 function Explicit_Suppress (E : Entity_Id; C : Check_Id) return Boolean;
615 -- This function returns True if an explicit pragma Suppress for check C
616 -- is present in the package defining E.
618 function Is_Check_Suppressed (E : Entity_Id; C : Check_Id) return Boolean;
619 -- This function is called if Checks_May_Be_Suppressed (E) is True to
620 -- determine whether check C is suppressed either on the entity E or
621 -- as the result of a scope suppress pragma. If Checks_May_Be_Suppressed
622 -- is False, then the status of the check can be determined simply by
623 -- examining Scope_Checks (C), so this routine is not called in that case.