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 whether we are doing a full analysis or a
215 -- pre-analysis. In normal analysis mode (Analysis-Expansion for
216 -- instructions or declarations) or (Analysis-Resolution-Expansion for
217 -- expressions) this flag is set. Note that if we are not generating
218 -- code the expansion phase merely sets the Analyzed flag to True in
219 -- this case. If we are in Pre-Analysis mode (see above) this flag is
220 -- set to False then the expansion phase is skipped.
221 -- When this flag is False the flag Expander_Active is also False
222 -- (the Expander_Activer flag defined in the spec of package Expander
223 -- tells you whether expansion is currently enabled).
224 -- You should really regard this as a read only flag.
226 In_Default_Expression : Boolean := False;
227 -- Switch to indicate that we are in a default expression, as described
228 -- above. Note that this must be recursively saved on a Semantics call
229 -- since it is possible for the analysis of an expression to result in
230 -- a recursive call (e.g. to get the entity for System.Address as part
231 -- of the processing of an Address attribute reference).
232 -- When this switch is True then Full_Analysis above must be False.
233 -- You should really regard this as a read only flag.
235 In_Deleted_Code : Boolean := False;
236 -- If the condition in an if-statement is statically known, the branch
237 -- that is not taken is analyzed with expansion disabled, and the tree
238 -- is deleted after analysis. Itypes generated in deleted code must be
239 -- frozen from start, because the tree on which they depend will not
240 -- be available at the freeze point.
242 In_Inlined_Body : Boolean := False;
243 -- Switch to indicate that we are analyzing and resolving an inlined
244 -- body. Type checking is disabled in this context, because types are
245 -- known to be compatible. This avoids problems with private types whose
246 -- full view is derived from private types.
248 Inside_A_Generic : Boolean := False;
249 -- This flag is set if we are processing a generic specification,
250 -- generic definition, or generic body. When this flag is True the
251 -- Expander_Active flag is False to disable any code expansion (see
252 -- package Expander). Only the generic processing can modify the
253 -- status of this flag, any other client should regard it as read-only.
255 Unloaded_Subunits : Boolean := False;
256 -- This flag is set True if we have subunits that are not loaded. This
257 -- occurs when the main unit is a subunit, and contains lower level
258 -- subunits that are not loaded. We use this flag to suppress warnings
259 -- about unused variables, since these warnings are unreliable in this
260 -- case. We could perhaps do a more accurate job and retain some of the
261 -- warnings, but it is quite a tricky job. See test 4323-002.
267 -- The scope stack indicates the declarative regions that are currently
268 -- being processed (analyzed and/or expanded). The scope stack is one of
269 -- basic visibility structures in the compiler: entities that are declared
270 -- in a scope that is currently on the scope stack are immediately visible.
271 -- (leaving aside issues of hiding and overloading).
273 -- Initially, the scope stack only contains an entry for package Standard.
274 -- When a compilation unit, subprogram unit, block or declarative region
275 -- is being processed, the corresponding entity is pushed on the scope
276 -- stack. It is removed after the processing step is completed. A given
277 -- entity can be placed several times on the scope stack, for example
278 -- when processing derived type declarations, freeze nodes, etc. The top
279 -- of the scope stack is the innermost scope currently being processed.
280 -- It is obtained through function Current_Scope. After a compilation unit
281 -- has been processed, the scope stack must contain only Standard.
282 -- The predicate In_Open_Scopes specifies whether a scope is currently
283 -- on the scope stack.
285 -- This model is complicated by the need to compile units on the fly, in
286 -- the middle of the compilation of other units. This arises when compiling
287 -- instantiations, and when compiling run-time packages obtained through
288 -- rtsfind. Given that the scope stack is a single static and global
289 -- structure (not originally designed for the recursive processing required
290 -- by rtsfind for example) additional machinery is needed to indicate what
291 -- is currently being compiled. As a result, the scope stack holds several
292 -- contiguous sections that correspond to the compilation of a given
293 -- compilation unit. These sections are separated by distinct occurrences
294 -- of package Standard. The currently active section of the scope stack
295 -- goes from the current scope to the first occurrence of Standard, which
296 -- is additionally marked with the flag Is_Active_Stack_Base. The basic
297 -- visibility routine (Find_Direct_Name, sem_ch8) uses this contiguous
298 -- section of the scope stack to determine whether a given entity is or
299 -- is not visible at a point. In_Open_Scopes only examines the currently
300 -- active section of the scope stack.
302 -- Similar complications arise when processing child instances. These
303 -- must be compiled in the context of parent instances, and therefore the
304 -- parents must be pushed on the stack before compiling the child, and
305 -- removed afterwards. Routines Save_Scope_Stack and Restore_Scope_Stack
306 -- are used to set/reset the visibility of entities declared in scopes
307 -- that are currently on the scope stack, and are used when compiling
308 -- instance bodies on the fly.
310 -- It is clear in retrospect that all semantic processing and visibility
311 -- structures should have been fully recursive. The rtsfind mechanism,
312 -- and the complexities brought about by subunits and by generic child
313 -- units and their instantitions, have led to a hybrid model that carries
314 -- more state than one would wish.
316 type Scope_Stack_Entry is record
318 -- Entity representing the scope
320 Last_Subprogram_Name : String_Ptr;
321 -- Pointer to name of last subprogram body in this scope. Used for
322 -- testing proper alpha ordering of subprogram bodies in scope.
324 Save_Scope_Suppress : Suppress_Array;
325 -- Save contents of Scope_Suppress on entry
327 Save_Local_Entity_Suppress : Int;
328 -- Save contents of Local_Entity_Suppress.Last on entry
330 Is_Transient : Boolean;
331 -- Marks Transient Scopes (See Exp_Ch7 body for details)
333 Previous_Visibility : Boolean;
334 -- Used when installing the parent(s) of the current compilation unit.
335 -- The parent may already be visible because of an ongoing compilation,
336 -- and the proper visibility must be restored on exit. The flag is
337 -- typically needed when the context of a child unit requires
338 -- compilation of a sibling. In other cases the flag is set to False.
339 -- See Sem_Ch10 (Install_Parents, Remove_Parents).
341 Node_To_Be_Wrapped : Node_Id;
342 -- Only used in transient scopes. Records the node which will
343 -- be wrapped by the transient block.
345 Actions_To_Be_Wrapped_Before : List_Id;
346 Actions_To_Be_Wrapped_After : List_Id;
347 -- Actions that have to be inserted at the start or at the end of a
348 -- transient block. Used to temporarily hold these actions until the
349 -- block is created, at which time the actions are moved to the block.
351 Pending_Freeze_Actions : List_Id;
352 -- Used to collect freeze entity nodes and associated actions that are
353 -- generated in a inner context but need to be analyzed outside, such as
354 -- records and initialization procedures. On exit from the scope, this
355 -- list of actions is inserted before the scope construct and analyzed
356 -- to generate the corresponding freeze processing and elaboration of
357 -- other associated actions.
359 First_Use_Clause : Node_Id;
360 -- Head of list of Use_Clauses in current scope. The list is built when
361 -- the declarations in the scope are processed. The list is traversed
362 -- on scope exit to undo the effect of the use clauses.
364 Component_Alignment_Default : Component_Alignment_Kind;
365 -- Component alignment to be applied to any record or array types that
366 -- are declared for which a specific component alignment pragma does not
367 -- set the alignment.
369 Is_Active_Stack_Base : Boolean;
370 -- Set to true only when entering the scope for Standard_Standard from
371 -- from within procedure Semantics. Indicates the base of the current
372 -- active set of scopes. Needed by In_Open_Scopes to handle cases where
373 -- Standard_Standard can be pushed anew on the scope stack to start a
374 -- new active section (see comment above).
378 package Scope_Stack is new Table.Table (
379 Table_Component_Type => Scope_Stack_Entry,
380 Table_Index_Type => Int,
381 Table_Low_Bound => 0,
382 Table_Initial => Alloc.Scope_Stack_Initial,
383 Table_Increment => Alloc.Scope_Stack_Increment,
384 Table_Name => "Sem.Scope_Stack");
386 -----------------------------------
387 -- Handling of Check Suppression --
388 -----------------------------------
390 -- There are two kinds of suppress checks: scope based suppress checks,
391 -- and entity based suppress checks.
393 -- Scope based suppress checks (from initial command line arguments,
394 -- or from Suppress pragmas not including an entity name) are recorded
395 -- in the Sem.Supress variable, and all that is necessary is to save the
396 -- state of this variable on scope entry, and restore it on scope exit.
398 -- Entity based suppress checks, from Suppress pragmas giving an Entity_Id,
399 -- are handled as follows. If a suppress or unsuppress pragma is
400 -- encountered for a given entity, then the flag Checks_May_Be_Suppressed
401 -- is set in the entity and an entry is made in either the
402 -- Local_Entity_Suppress table (case of pragma that appears in other than
403 -- a package spec), or in the Global_Entity_Suppress table (case of pragma
404 -- that appears in a package spec, which is by the rule of RM 11.5(7)
405 -- applicable throughout the life of the entity).
407 -- If the Checks_May_Be_Suppressed flag is set in an entity then the
408 -- procedure is to search first the local and then the global suppress
409 -- tables (the local one being searched in reverse order, i.e. last in
410 -- searched first). The only other point is that we have to make sure
411 -- that we have proper nested interaction between such specific pragmas
412 -- and locally applied general pragmas applying to all entities. This
413 -- is achieved by including in the Local_Entity_Suppress table dummy
414 -- entries with an empty Entity field that are applicable to all entities.
416 Scope_Suppress : Suppress_Array := Suppress_Options;
417 -- This array contains the current scope based settings of the suppress
418 -- switches. It is initialized from the options as shown, and then modified
419 -- by pragma Suppress. On entry to each scope, the current setting is saved
420 -- the scope stack, and then restored on exit from the scope. This record
421 -- may be rapidly checked to determine the current status of a check if
422 -- no specific entity is involved or if the specific entity involved is
423 -- one for which no specific Suppress/Unsuppress pragma has been set (as
424 -- indicated by the Checks_May_Be_Suppressed flag being set).
426 -- This scheme is a little complex, but serves the purpose of enabling
427 -- a very rapid check in the common case where no entity specific pragma
428 -- applies, and gives the right result when such pragmas are used even
429 -- in complex cases of nested Suppress and Unsuppress pragmas.
431 type Entity_Check_Suppress_Record is record
433 -- Entity to which the check applies, or Empty for a local check
434 -- that has no entity name (and thus applies to all entities).
437 -- Check which is set (note this cannot be All_Checks, if the All_Checks
438 -- case, a sequence of eentries appears for the individual checks.
441 -- Set True for Suppress, and False for Unsuppress
444 -- The Local_Entity_Suppress table is a stack, to which new entries are
445 -- added for Suppress and Unsuppress pragmas appearing in other than
446 -- package specs. Such pragmas are effective only to the end of the scope
447 -- in which they appear. This is achieved by marking the stack on entry
448 -- to a scope and then cutting back the stack to that marked point on
451 package Local_Entity_Suppress is new Table.Table (
452 Table_Component_Type => Entity_Check_Suppress_Record,
453 Table_Index_Type => Int,
454 Table_Low_Bound => 0,
455 Table_Initial => Alloc.Entity_Suppress_Initial,
456 Table_Increment => Alloc.Entity_Suppress_Increment,
457 Table_Name => "Local_Entity_Suppress");
459 -- The Global_Entity_Suppress table is used for entities which have
460 -- a Suppress or Unsuppress pragma naming a specific entity in a
461 -- package spec. Such pragmas always refer to entities in the package
462 -- spec and are effective throughout the lifetime of the named entity.
464 package Global_Entity_Suppress is new Table.Table (
465 Table_Component_Type => Entity_Check_Suppress_Record,
466 Table_Index_Type => Int,
467 Table_Low_Bound => 0,
468 Table_Initial => Alloc.Entity_Suppress_Initial,
469 Table_Increment => Alloc.Entity_Suppress_Increment,
470 Table_Name => "Global_Entity_Suppress");
476 procedure Initialize;
477 -- Initialize internal tables
480 -- Lock internal tables before calling back end
482 procedure Semantics (Comp_Unit : Node_Id);
483 -- This procedure is called to perform semantic analysis on the specified
484 -- node which is the N_Compilation_Unit node for the unit.
486 procedure Analyze (N : Node_Id);
487 procedure Analyze (N : Node_Id; Suppress : Check_Id);
488 -- This is the recursive procedure which is applied to individual nodes
489 -- of the tree, starting at the top level node (compilation unit node)
490 -- and then moving down the tree in a top down traversal. It calls
491 -- individual routines with names Analyze_xxx to analyze node xxx. Each
492 -- of these routines is responsible for calling Analyze on the components
495 -- Note: In the case of expression components (nodes whose Nkind is in
496 -- N_Subexpr), the call to Analyze does not complete the semantic analysis
497 -- of the node, since the type resolution cannot be completed until the
498 -- complete context is analyzed. The completion of the type analysis occurs
499 -- in the corresponding Resolve routine (see Sem_Res).
501 -- Note: for integer and real literals, the analyzer sets the flag to
502 -- indicate that the result is a static expression. If the expander
503 -- generates a literal that does NOT correspond to a static expression,
504 -- e.g. by folding an expression whose value is known at compile-time,
505 -- but is not technically static, then the caller should reset the
506 -- Is_Static_Expression flag after analyzing but before resolving.
508 -- If the Suppress argument is present, then the analysis is done
509 -- with the specified check suppressed (can be All_Checks to suppress
512 procedure Analyze_List (L : List_Id);
513 procedure Analyze_List (L : List_Id; Suppress : Check_Id);
514 -- Analyzes each element of a list. If the Suppress argument is present,
515 -- then the analysis is done with the specified check suppressed (can
516 -- be All_Checks to suppress all checks).
518 procedure Copy_Suppress_Status
522 -- If From is an entity for which check C is explicitly suppressed
523 -- then also explicitly suppress the corresponding check in To.
525 procedure Insert_List_After_And_Analyze
526 (N : Node_Id; L : List_Id);
527 procedure Insert_List_After_And_Analyze
528 (N : Node_Id; L : List_Id; Suppress : Check_Id);
529 -- Inserts list L after node N using Nlists.Insert_List_After, and then,
530 -- after this insertion is complete, analyzes all the nodes in the list,
531 -- including any additional nodes generated by this analysis. If the list
532 -- is empty or be No_List, the call has no effect. If the Suppress
533 -- argument is present, then the analysis is done with the specified
534 -- check suppressed (can be All_Checks to suppress all checks).
536 procedure Insert_List_Before_And_Analyze
537 (N : Node_Id; L : List_Id);
538 procedure Insert_List_Before_And_Analyze
539 (N : Node_Id; L : List_Id; Suppress : Check_Id);
540 -- Inserts list L before node N using Nlists.Insert_List_Before, and then,
541 -- after this insertion is complete, analyzes all the nodes in the list,
542 -- including any additional nodes generated by this analysis. If the list
543 -- is empty or be No_List, the call has no effect. If the Suppress
544 -- argument is present, then the analysis is done with the specified
545 -- check suppressed (can be All_Checks to suppress all checks).
547 procedure Insert_After_And_Analyze
548 (N : Node_Id; M : Node_Id);
549 procedure Insert_After_And_Analyze
550 (N : Node_Id; M : Node_Id; Suppress : Check_Id);
551 -- Inserts node M after node N and then after the insertion is complete,
552 -- analyzes the inserted node and all nodes that are generated by
553 -- this analysis. If the node is empty, the call has no effect. If the
554 -- Suppress argument is present, then the analysis is done with the
555 -- specified check suppressed (can be All_Checks to suppress all checks).
557 procedure Insert_Before_And_Analyze
558 (N : Node_Id; M : Node_Id);
559 procedure Insert_Before_And_Analyze
560 (N : Node_Id; M : Node_Id; Suppress : Check_Id);
561 -- Inserts node M before node N and then after the insertion is complete,
562 -- analyzes the inserted node and all nodes that could be generated by
563 -- this analysis. If the node is empty, the call has no effect. If the
564 -- Suppress argument is present, then the analysis is done with the
565 -- specified check suppressed (can be All_Checks to suppress all checks).
567 function External_Ref_In_Generic (E : Entity_Id) return Boolean;
568 -- Return True if we are in the context of a generic and E is
569 -- external (more global) to it.
571 procedure Enter_Generic_Scope (S : Entity_Id);
572 -- Shall be called each time a Generic subprogram or package scope is
573 -- entered. S is the entity of the scope.
574 -- ??? At the moment, only called for package specs because this mechanism
575 -- is only used for avoiding freezing of external references in generics
576 -- and this can only be an issue if the outer generic scope is a package
577 -- spec (otherwise all external entities are already frozen)
579 procedure Exit_Generic_Scope (S : Entity_Id);
580 -- Shall be called each time a Generic subprogram or package scope is
581 -- exited. S is the entity of the scope.
582 -- ??? At the moment, only called for package specs exit.
584 function Explicit_Suppress (E : Entity_Id; C : Check_Id) return Boolean;
585 -- This function returns True if an explicit pragma Suppress for check C
586 -- is present in the package defining E.
588 function Is_Check_Suppressed (E : Entity_Id; C : Check_Id) return Boolean;
589 -- This function is called if Checks_May_Be_Suppressed (E) is True to
590 -- determine whether check C is suppressed either on the entity E or
591 -- as the result of a scope suppress pragma. If Checks_May_Be_Suppressed
592 -- is False, then the status of the check can be determined simply by
593 -- examining Scope_Checks (C), so this routine is not called in that case.