Imported Upstream version 4.8.1
[platform/upstream/gcc48.git] / gcc / ada / sem.ads
1 ------------------------------------------------------------------------------
2 --                                                                          --
3 --                         GNAT COMPILER COMPONENTS                         --
4 --                                                                          --
5 --                                  S E M                                   --
6 --                                                                          --
7 --                                 S p e c                                  --
8 --                                                                          --
9 --          Copyright (C) 1992-2012, Free Software Foundation, Inc.         --
10 --                                                                          --
11 -- GNAT is free software;  you can  redistribute it  and/or modify it under --
12 -- terms of the  GNU General Public License as published  by the Free Soft- --
13 -- ware  Foundation;  either version 3,  or (at your option) any later ver- --
14 -- sion.  GNAT is distributed in the hope that it will be useful, but WITH- --
15 -- OUT ANY WARRANTY;  without even the  implied warranty of MERCHANTABILITY --
16 -- or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License --
17 -- for  more details.  You should have  received  a copy of the GNU General --
18 -- Public License  distributed with GNAT; see file COPYING3.  If not, go to --
19 -- http://www.gnu.org/licenses for a complete copy of the license.          --
20 --                                                                          --
21 -- GNAT was originally developed  by the GNAT team at  New York University. --
22 -- Extensive contributions were provided by Ada Core Technologies Inc.      --
23 --                                                                          --
24 ------------------------------------------------------------------------------
25
26 --------------------------------------
27 -- Semantic Analysis: General Model --
28 --------------------------------------
29
30 --  Semantic processing involves 3 phases which are highly intertwined
31 --  (i.e. mutually recursive):
32
33 --    Analysis     implements the bulk of semantic analysis such as
34 --                 name analysis and type resolution for declarations,
35 --                 instructions and expressions.  The main routine
36 --                 driving this process is procedure Analyze given below.
37 --                 This analysis phase is really a bottom up pass that is
38 --                 achieved during the recursive traversal performed by the
39 --                 Analyze_... procedures implemented in the sem_* packages.
40 --                 For expressions this phase determines unambiguous types
41 --                 and collects sets of possible types where the
42 --                 interpretation is potentially ambiguous.
43
44 --    Resolution   is carried out only for expressions to finish type
45 --                 resolution that was initiated but not necessarily
46 --                 completed during analysis (because of overloading
47 --                 ambiguities). Specifically, after completing the bottom
48 --                 up pass carried out during analysis for expressions, the
49 --                 Resolve routine (see the spec of sem_res for more info)
50 --                 is called to perform a top down resolution with
51 --                 recursive calls to itself to resolve operands.
52
53 --    Expansion    if we are not generating code this phase is a no-op.
54 --                 otherwise this phase expands, i.e. transforms, original
55 --                 declaration, expressions or instructions into simpler
56 --                 structures that can be handled by the back-end. This
57 --                 phase is also in charge of generating code which is
58 --                 implicit in the original source (for instance for
59 --                 default initializations, controlled types, etc.)
60 --                 There are two separate instances where expansion is
61 --                 invoked. For declarations and instructions, expansion is
62 --                 invoked just after analysis since no resolution needs
63 --                 to be performed. For expressions, expansion is done just
64 --                 after resolution. In both cases expansion is done from the
65 --                 bottom up just before the end of Analyze for instructions
66 --                 and declarations or the call to Resolve for expressions.
67 --                 The main routine driving expansion is Expand.
68 --                 See the spec of Expander for more details.
69
70 --  To summarize, in normal code generation mode we recursively traverse the
71 --  abstract syntax tree top-down performing semantic analysis bottom
72 --  up. For instructions and declarations, before the call to the Analyze
73 --  routine completes we perform expansion since at that point we have all
74 --  semantic information needed. For expression nodes, after the call to
75 --  Analysis terminates we invoke the Resolve routine to transmit top-down
76 --  the type that was gathered by Analyze which will resolve possible
77 --  ambiguities in the expression. Just before the call to Resolve
78 --  terminates, the expression can be expanded since all the semantic
79 --  information is available at that point.
80
81 --  If we are not generating code then the expansion phase is a no-op
82
83 --  When generating code there are a number of exceptions to the basic
84 --  Analysis-Resolution-Expansion model for expressions. The most prominent
85 --  examples are the handling of default expressions and aggregates.
86
87 -----------------------------------------------------------------------
88 -- Handling of Default and Per-Object Expressions (Spec-Expressions) --
89 -----------------------------------------------------------------------
90
91 --  The default expressions in component declarations and in procedure
92 --  specifications (but not the ones in object declarations) are quite tricky
93 --  to handle. The problem is that some processing is required at the point
94 --  where the expression appears:
95
96 --    visibility analysis (including user defined operators)
97 --    freezing of static expressions
98
99 --  but other processing must be deferred until the enclosing entity (record or
100 --  procedure specification) is frozen:
101
102 --    freezing of any other types in the expression expansion
103 --    generation of code
104
105 --  A similar situation occurs with the argument of priority and interrupt
106 --  priority pragmas that appear in task and protected definition specs and
107 --  other cases of per-object expressions (see RM 3.8(18)).
108
109 --  Another similar case is the conditions in precondition and postcondition
110 --  pragmas that appear with subprogram specifications rather than in the body.
111
112 --  Collectively we call these Spec_Expressions. The routine that performs the
113 --  special analysis is called Analyze_Spec_Expression.
114
115 --  Expansion has to be deferred since you can't generate code for expressions
116 --  that reference types that have not been frozen yet. As an example, consider
117 --  the following:
118
119 --      type x is delta 0.5 range -10.0 .. +10.0;
120 --      ...
121 --      type q is record
122 --        xx : x := y * z;
123 --      end record;
124
125 --      for x'small use 0.25
126
127 --  The expander is in charge of dealing with fixed-point, and of course the
128 --  small declaration, which is not too late, since the declaration of type q
129 --  does *not* freeze type x, definitely affects the expanded code.
130
131 --  Another reason that we cannot expand early is that expansion can generate
132 --  range checks. These range checks need to be inserted not at the point of
133 --  definition but at the point of use. The whole point here is that the value
134 --  of the expression cannot be obtained at the point of declaration, only at
135 --  the point of use.
136
137 --  Generally our model is to combine analysis resolution and expansion, but
138 --  this is the one case where this model falls down. Here is how we patch
139 --  it up without causing too much distortion to our basic model.
140
141 --  A switch (In_Spec_Expression) is set to show that we are in the initial
142 --  occurrence of a default expression. The analyzer is then called on this
143 --  expression with the switch set true. Analysis and resolution proceed almost
144 --  as usual, except that Freeze_Expression will not freeze non-static
145 --  expressions if this switch is set, and the call to Expand at the end of
146 --  resolution is skipped. This also skips the code that normally sets the
147 --  Analyzed flag to True. The result is that when we are done the tree is
148 --  still marked as unanalyzed, but all types for static expressions are frozen
149 --  as required, and all entities of variables have been recorded. We then turn
150 --  off the switch, and later on reanalyze the expression with the switch off.
151 --  The effect is that this second analysis freezes the rest of the types as
152 --  required, and generates code but visibility analysis is not repeated since
153 --  all the entities are marked.
154
155 --  The second analysis (the one that generates code) is in the context
156 --  where the code is required. For a record field default, this is in the
157 --  initialization procedure for the record and for a subprogram default
158 --  parameter, it is at the point the subprogram is frozen. For a priority or
159 --  storage size pragma it is in the context of the Init_Proc for the task or
160 --  protected object. For a pre/postcondition pragma it is in the body when
161 --  code for the pragma is generated.
162
163 ------------------
164 -- Pre-Analysis --
165 ------------------
166
167 --  For certain kind of expressions, such as aggregates, we need to defer
168 --  expansion of the aggregate and its inner expressions after the whole
169 --  set of expressions appearing inside the aggregate have been analyzed.
170 --  Consider, for instance the following example:
171 --
172 --     (1 .. 100 => new Thing (Function_Call))
173 --
174 --  The normal Analysis-Resolution-Expansion mechanism where expansion of the
175 --  children is performed before expansion of the parent does not work if the
176 --  code generated for the children by the expander needs to be evaluated
177 --  repeatedly (for instance in the above aggregate "new Thing (Function_Call)"
178 --  needs to be called 100 times.)
179
180 --  The reason why this mechanism does not work is that, the expanded code for
181 --  the children is typically inserted above the parent and thus when the
182 --  father gets expanded no re-evaluation takes place. For instance in the case
183 --  of aggregates if "new Thing (Function_Call)" is expanded before of the
184 --  aggregate the expanded code will be placed outside of the aggregate and
185 --  when expanding the aggregate the loop from 1 to 100 will not surround the
186 --  expanded code for "new Thing (Function_Call)".
187
188 --  To remedy this situation we introduce a new flag which signals whether we
189 --  want a full analysis (i.e. expansion is enabled) or a pre-analysis which
190 --  performs Analysis and Resolution but no expansion.
191
192 --  After the complete pre-analysis of an expression has been carried out we
193 --  can transform the expression and then carry out the full three stage
194 --  (Analyze-Resolve-Expand) cycle on the transformed expression top-down so
195 --  that the expansion of inner expressions happens inside the newly generated
196 --  node for the parent expression.
197
198 --  Note that the difference between processing of default expressions and
199 --  pre-analysis of other expressions is that we do carry out freezing in
200 --  the latter but not in the former (except for static scalar expressions).
201 --  The routine that performs preanalysis and corresponding resolution is
202 --  called Preanalyze_And_Resolve and is in Sem_Res.
203
204 with Alloc;
205 with Einfo;  use Einfo;
206 with Table;
207 with Types;  use Types;
208
209 package Sem is
210
211    -----------------------------
212    -- Semantic Analysis Flags --
213    -----------------------------
214
215    Full_Analysis : Boolean := True;
216    --  Switch to indicate if we are doing a full analysis or a pre-analysis.
217    --  In normal analysis mode (Analysis-Expansion for instructions or
218    --  declarations) or (Analysis-Resolution-Expansion for expressions) this
219    --  flag is set. Note that if we are not generating code the expansion phase
220    --  merely sets the Analyzed flag to True in this case. If we are in
221    --  Pre-Analysis mode (see above) this flag is set to False then the
222    --  expansion phase is skipped.
223    --
224    --  When this flag is False the flag Expander_Active is also False (the
225    --  Expander_Active flag defined in the spec of package Expander tells you
226    --  whether expansion is currently enabled). You should really regard this
227    --  as a read only flag.
228
229    In_Spec_Expression : Boolean := False;
230    --  Switch to indicate that we are in a spec-expression, as described
231    --  above. Note that this must be recursively saved on a Semantics call
232    --  since it is possible for the analysis of an expression to result in a
233    --  recursive call (e.g. to get the entity for System.Address as part of the
234    --  processing of an Address attribute reference). When this switch is True
235    --  then Full_Analysis above must be False. You should really regard this as
236    --  a read only flag.
237
238    In_Deleted_Code : Boolean := False;
239    --  If the condition in an if-statement is statically known, the branch
240    --  that is not taken is analyzed with expansion disabled, and the tree
241    --  is deleted after analysis. Itypes generated in deleted code must be
242    --  frozen from start, because the tree on which they depend will not
243    --  be available at the freeze point.
244
245    In_Assertion_Expr : Nat := 0;
246    --  This is set non-zero if we are within the expression of an assertion
247    --  pragma or aspect. It is a counter which is incremented at the start
248    --  of expanding such an expression, and decremented on completion of
249    --  expanding that expression. Probably a boolean would be good enough,
250    --  since we think that such expressions cannot nest, but that might not
251    --  be true in the future (e.g. if let expressions are added to Ada) so
252    --  we prepare for that future possibility by making it a counter.
253
254    In_Inlined_Body : Boolean := False;
255    --  Switch to indicate that we are analyzing and resolving an inlined body.
256    --  Type checking is disabled in this context, because types are known to be
257    --  compatible. This avoids problems with private types whose full view is
258    --  derived from private types.
259
260    Inside_A_Generic : Boolean := False;
261    --  This flag is set if we are processing a generic specification, generic
262    --  definition, or generic body. When this flag is True the Expander_Active
263    --  flag is False to disable any code expansion (see package Expander). Only
264    --  the generic processing can modify the status of this flag, any other
265    --  client should regard it as read-only.
266    --  Probably should be called Inside_A_Generic_Template ???
267
268    Inside_Freezing_Actions : Nat := 0;
269    --  Flag indicating whether we are within a call to Expand_N_Freeze_Actions.
270    --  Non-zero means we are inside (it is actually a level counter to deal
271    --  with nested calls). Used to avoid traversing the tree each time a
272    --  subprogram call is processed to know if we must not clear all constant
273    --  indications from entities in the current scope. Only the expansion of
274    --  freezing nodes can modify the status of this flag, any other client
275    --  should regard it as read-only.
276
277    Unloaded_Subunits : Boolean := False;
278    --  This flag is set True if we have subunits that are not loaded. This
279    --  occurs when the main unit is a subunit, and contains lower level
280    --  subunits that are not loaded. We use this flag to suppress warnings
281    --  about unused variables, since these warnings are unreliable in this
282    --  case. We could perhaps do a more accurate job and retain some of the
283    --  warnings, but it is quite a tricky job.
284
285    -----------------------------------
286    -- Handling of Check Suppression --
287    -----------------------------------
288
289    --  There are two kinds of suppress checks: scope based suppress checks,
290    --  and entity based suppress checks.
291
292    --  Scope based suppress checks for the predefined checks (from initial
293    --  command line arguments, or from Suppress pragmas not including an entity
294    --  name) are recorded in the Sem.Scope_Suppress variable, and all that
295    --  is necessary is to save the state of this variable on scope entry, and
296    --  restore it on scope exit. This mechanism allows for fast checking of the
297    --  scope suppress state without needing complex data structures.
298
299    --  Entity based checks, from Suppress/Unsuppress pragmas giving an
300    --  Entity_Id and scope based checks for non-predefined checks (introduced
301    --  using pragma Check_Name), are handled as follows. If a suppress or
302    --  unsuppress pragma is encountered for a given entity, then the flag
303    --  Checks_May_Be_Suppressed is set in the entity and an entry is made in
304    --  either the Local_Entity_Suppress stack (case of pragma that appears in
305    --  other than a package spec), or in the Global_Entity_Suppress stack (case
306    --  of pragma that appears in a package spec, which is by the rule of RM
307    --  11.5(7) applicable throughout the life of the entity). Similarly, a
308    --  Suppress/Unsuppress pragma for a non-predefined check which does not
309    --  specify an entity is also stored in one of these stacks.
310
311    --  If the Checks_May_Be_Suppressed flag is set in an entity then the
312    --  procedure is to search first the local and then the global suppress
313    --  stacks (we search these in reverse order, top element first). The only
314    --  other point is that we have to make sure that we have proper nested
315    --  interaction between such specific pragmas and locally applied general
316    --  pragmas applying to all entities. This is achieved by including in the
317    --  Local_Entity_Suppress table dummy entries with an empty Entity field
318    --  that are applicable to all entities. A similar search is needed for any
319    --  non-predefined check even if no specific entity is involved.
320
321    Scope_Suppress : Suppress_Record;
322    --  This variable contains the current scope based settings of the suppress
323    --  switches. It is initialized from Suppress_Options in Gnat1drv, and then
324    --  modified by pragma Suppress. On entry to each scope, the current setting
325    --  is saved on the scope stack, and then restored on exit from the scope.
326    --  This record may be rapidly checked to determine the current status of
327    --  a check if no specific entity is involved or if the specific entity
328    --  involved is one for which no specific Suppress/Unsuppress pragma has
329    --  been set (as indicated by the Checks_May_Be_Suppressed flag being set).
330
331    --  This scheme is a little complex, but serves the purpose of enabling
332    --  a very rapid check in the common case where no entity specific pragma
333    --  applies, and gives the right result when such pragmas are used even
334    --  in complex cases of nested Suppress and Unsuppress pragmas.
335
336    --  The Local_Entity_Suppress and Global_Entity_Suppress stacks are handled
337    --  using dynamic allocation and linked lists. We do not often use this
338    --  approach in the compiler (preferring to use extensible tables instead).
339    --  The reason we do it here is that scope stack entries save a pointer to
340    --  the current local stack top, which is also saved and restored on scope
341    --  exit. Furthermore for processing of generics we save pointers to the
342    --  top of the stack, so that the local stack is actually a tree of stacks
343    --  rather than a single stack, a structure that is easy to represent using
344    --  linked lists, but impossible to represent using a single table. Note
345    --  that because of the generic issue, we never release entries in these
346    --  stacks, but that's no big deal, since we are unlikely to have a huge
347    --  number of Suppress/Unsuppress entries in a single compilation.
348
349    type Suppress_Stack_Entry;
350    type Suppress_Stack_Entry_Ptr is access all Suppress_Stack_Entry;
351
352    type Suppress_Stack_Entry is record
353       Entity : Entity_Id;
354       --  Entity to which the check applies, or Empty for a check that has
355       --  no entity name (and thus applies to all entities).
356
357       Check : Check_Id;
358       --  Check which is set (can be All_Checks for the All_Checks case)
359
360       Suppress : Boolean;
361       --  Set True for Suppress, and False for Unsuppress
362
363       Prev : Suppress_Stack_Entry_Ptr;
364       --  Pointer to previous entry on stack
365
366       Next : Suppress_Stack_Entry_Ptr;
367       --  All allocated Suppress_Stack_Entry records are chained together in
368       --  a linked list whose head is Suppress_Stack_Entries, and the Next
369       --  field is used as a forward pointer (null ends the list). This is
370       --  used to free all entries in Sem.Init (which will be important if
371       --  we ever setup the compiler to be reused).
372    end record;
373
374    Suppress_Stack_Entries : Suppress_Stack_Entry_Ptr := null;
375    --  Pointer to linked list of records (see comments for Next above)
376
377    Local_Suppress_Stack_Top : Suppress_Stack_Entry_Ptr;
378    --  Pointer to top element of local suppress stack. This is the entry that
379    --  is saved and restored in the scope stack, and also saved for generic
380    --  body expansion.
381
382    Global_Suppress_Stack_Top : Suppress_Stack_Entry_Ptr;
383    --  Pointer to top element of global suppress stack
384
385    procedure Push_Local_Suppress_Stack_Entry
386      (Entity   : Entity_Id;
387       Check    : Check_Id;
388       Suppress : Boolean);
389    --  Push a new entry on to the top of the local suppress stack, updating
390    --  the value in Local_Suppress_Stack_Top;
391
392    procedure Push_Global_Suppress_Stack_Entry
393      (Entity   : Entity_Id;
394       Check    : Check_Id;
395       Suppress : Boolean);
396    --  Push a new entry on to the top of the global suppress stack, updating
397    --  the value in Global_Suppress_Stack_Top;
398
399    -----------------
400    -- Scope Stack --
401    -----------------
402
403    --  The scope stack indicates the declarative regions that are currently
404    --  being processed (analyzed and/or expanded). The scope stack is one of
405    --  the basic visibility structures in the compiler: entities that are
406    --  declared in a scope that is currently on the scope stack are immediately
407    --  visible (leaving aside issues of hiding and overloading).
408
409    --  Initially, the scope stack only contains an entry for package Standard.
410    --  When a compilation unit, subprogram unit, block or declarative region
411    --  is being processed, the corresponding entity is pushed on the scope
412    --  stack. It is removed after the processing step is completed. A given
413    --  entity can be placed several times on the scope stack, for example
414    --  when processing derived type declarations, freeze nodes, etc. The top
415    --  of the scope stack is the innermost scope currently being processed.
416    --  It is obtained through function Current_Scope. After a compilation unit
417    --  has been processed, the scope stack must contain only Standard.
418    --  The predicate In_Open_Scopes specifies whether a scope is currently
419    --  on the scope stack.
420
421    --  This model is complicated by the need to compile units on the fly, in
422    --  the middle of the compilation of other units. This arises when compiling
423    --  instantiations, and when compiling run-time packages obtained through
424    --  rtsfind. Given that the scope stack is a single static and global
425    --  structure (not originally designed for the recursive processing required
426    --  by rtsfind for example) additional machinery is needed to indicate what
427    --  is currently being compiled. As a result, the scope stack holds several
428    --  contiguous sections that correspond to the compilation of a given
429    --  compilation unit. These sections are separated by distinct occurrences
430    --  of package Standard. The currently active section of the scope stack
431    --  goes from the current scope to the first (innermost) occurrence of
432    --  Standard, which is additionally marked with the flag
433    --  Is_Active_Stack_Base. The basic visibility routine (Find_Direct_Name, in
434    --  Sem_Ch8) uses this contiguous section of the scope stack to determine
435    --  whether a given entity is or is not visible at a point. In_Open_Scopes
436    --  only examines the currently active section of the scope stack.
437
438    --  Similar complications arise when processing child instances. These
439    --  must be compiled in the context of parent instances, and therefore the
440    --  parents must be pushed on the stack before compiling the child, and
441    --  removed afterwards. Routines Save_Scope_Stack and Restore_Scope_Stack
442    --  are used to set/reset the visibility of entities declared in scopes
443    --  that are currently on the scope stack, and are used when compiling
444    --  instance bodies on the fly.
445
446    --  It is clear in retrospect that all semantic processing and visibility
447    --  structures should have been fully recursive. The rtsfind mechanism,
448    --  and the complexities brought about by subunits and by generic child
449    --  units and their instantiations, have led to a hybrid model that carries
450    --  more state than one would wish.
451
452    type Scope_Stack_Entry is record
453       Entity : Entity_Id;
454       --  Entity representing the scope
455
456       Last_Subprogram_Name : String_Ptr;
457       --  Pointer to name of last subprogram body in this scope. Used for
458       --  testing proper alpha ordering of subprogram bodies in scope.
459
460       Save_Scope_Suppress : Suppress_Record;
461       --  Save contents of Scope_Suppress on entry
462
463       Save_Local_Suppress_Stack_Top : Suppress_Stack_Entry_Ptr;
464       --  Save contents of Local_Suppress_Stack on entry to restore on exit
465
466       Save_Check_Policy_List : Node_Id;
467       --  Save contents of Check_Policy_List on entry to restore on exit
468
469       Save_Default_Storage_Pool : Node_Id;
470       --  Save contents of Default_Storage_Pool on entry to restore on exit
471
472       Is_Transient : Boolean;
473       --  Marks transient scopes (see Exp_Ch7 body for details)
474
475       Previous_Visibility : Boolean;
476       --  Used when installing the parent(s) of the current compilation unit.
477       --  The parent may already be visible because of an ongoing compilation,
478       --  and the proper visibility must be restored on exit. The flag is
479       --  typically needed when the context of a child unit requires
480       --  compilation of a sibling. In other cases the flag is set to False.
481       --  See Sem_Ch10 (Install_Parents, Remove_Parents).
482
483       Node_To_Be_Wrapped : Node_Id;
484       --  Only used in transient scopes. Records the node which will
485       --  be wrapped by the transient block.
486
487       Actions_To_Be_Wrapped_Before : List_Id;
488       Actions_To_Be_Wrapped_After  : List_Id;
489       --  Actions that have to be inserted at the start or at the end of a
490       --  transient block. Used to temporarily hold these actions until the
491       --  block is created, at which time the actions are moved to the block.
492
493       Pending_Freeze_Actions : List_Id;
494       --  Used to collect freeze entity nodes and associated actions that are
495       --  generated in an inner context but need to be analyzed outside, such
496       --  as records and initialization procedures. On exit from the scope,
497       --  this list of actions is inserted before the scope construct and
498       --  analyzed to generate the corresponding freeze processing and
499       --  elaboration of other associated actions.
500
501       First_Use_Clause : Node_Id;
502       --  Head of list of Use_Clauses in current scope. The list is built when
503       --  the declarations in the scope are processed. The list is traversed
504       --  on scope exit to undo the effect of the use clauses.
505
506       Component_Alignment_Default : Component_Alignment_Kind;
507       --  Component alignment to be applied to any record or array types that
508       --  are declared for which a specific component alignment pragma does not
509       --  set the alignment.
510
511       Is_Active_Stack_Base : Boolean;
512       --  Set to true only when entering the scope for Standard_Standard from
513       --  from within procedure Semantics. Indicates the base of the current
514       --  active set of scopes. Needed by In_Open_Scopes to handle cases where
515       --  Standard_Standard can be pushed anew on the scope stack to start a
516       --  new active section (see comment above).
517
518    end record;
519
520    package Scope_Stack is new Table.Table (
521      Table_Component_Type => Scope_Stack_Entry,
522      Table_Index_Type     => Int,
523      Table_Low_Bound      => 0,
524      Table_Initial        => Alloc.Scope_Stack_Initial,
525      Table_Increment      => Alloc.Scope_Stack_Increment,
526      Table_Name           => "Sem.Scope_Stack");
527
528    -----------------
529    -- Subprograms --
530    -----------------
531
532    procedure Initialize;
533    --  Initialize internal tables
534
535    procedure Lock;
536    --  Lock internal tables before calling back end
537
538    procedure Semantics (Comp_Unit : Node_Id);
539    --  This procedure is called to perform semantic analysis on the specified
540    --  node which is the N_Compilation_Unit node for the unit.
541
542    procedure Analyze (N : Node_Id);
543    procedure Analyze (N : Node_Id; Suppress : Check_Id);
544    --  This is the recursive procedure that is applied to individual nodes of
545    --  the tree, starting at the top level node (compilation unit node) and
546    --  then moving down the tree in a top down traversal. It calls individual
547    --  routines with names Analyze_xxx to analyze node xxx. Each of these
548    --  routines is responsible for calling Analyze on the components of the
549    --  subtree.
550    --
551    --  Note: In the case of expression components (nodes whose Nkind is in
552    --  N_Subexpr), the call to Analyze does not complete the semantic analysis
553    --  of the node, since the type resolution cannot be completed until the
554    --  complete context is analyzed. The completion of the type analysis occurs
555    --  in the corresponding Resolve routine (see Sem_Res).
556    --
557    --  Note: for integer and real literals, the analyzer sets the flag to
558    --  indicate that the result is a static expression. If the expander
559    --  generates a literal that does NOT correspond to a static expression,
560    --  e.g. by folding an expression whose value is known at compile-time,
561    --  but is not technically static, then the caller should reset the
562    --  Is_Static_Expression flag after analyzing but before resolving.
563    --
564    --  If the Suppress argument is present, then the analysis is done
565    --  with the specified check suppressed (can be All_Checks to suppress
566    --  all checks).
567
568    procedure Analyze_List (L : List_Id);
569    procedure Analyze_List (L : List_Id; Suppress : Check_Id);
570    --  Analyzes each element of a list. If the Suppress argument is present,
571    --  then the analysis is done with the specified check suppressed (can
572    --  be All_Checks to suppress all checks).
573
574    procedure Copy_Suppress_Status
575      (C    : Check_Id;
576       From : Entity_Id;
577       To   : Entity_Id);
578    --  If From is an entity for which check C is explicitly suppressed
579    --  then also explicitly suppress the corresponding check in To.
580
581    procedure Insert_List_After_And_Analyze
582      (N : Node_Id; L : List_Id);
583    procedure Insert_List_After_And_Analyze
584      (N : Node_Id; L : List_Id; Suppress : Check_Id);
585    --  Inserts list L after node N using Nlists.Insert_List_After, and then,
586    --  after this insertion is complete, analyzes all the nodes in the list,
587    --  including any additional nodes generated by this analysis. If the list
588    --  is empty or No_List, the call has no effect. If the Suppress argument is
589    --  present, then the analysis is done with the specified check suppressed
590    --  (can be All_Checks to suppress all checks).
591
592    procedure Insert_List_Before_And_Analyze
593      (N : Node_Id; L : List_Id);
594    procedure Insert_List_Before_And_Analyze
595      (N : Node_Id; L : List_Id; Suppress : Check_Id);
596    --  Inserts list L before node N using Nlists.Insert_List_Before, and then,
597    --  after this insertion is complete, analyzes all the nodes in the list,
598    --  including any additional nodes generated by this analysis. If the list
599    --  is empty or No_List, the call has no effect. If the Suppress argument is
600    --  present, then the analysis is done with the specified check suppressed
601    --  (can be All_Checks to suppress all checks).
602
603    procedure Insert_After_And_Analyze
604      (N : Node_Id; M : Node_Id);
605    procedure Insert_After_And_Analyze
606      (N : Node_Id; M : Node_Id; Suppress : Check_Id);
607    --  Inserts node M after node N and then after the insertion is complete,
608    --  analyzes the inserted node and all nodes that are generated by
609    --  this analysis. If the node is empty, the call has no effect. If the
610    --  Suppress argument is present, then the analysis is done with the
611    --  specified check suppressed (can be All_Checks to suppress all checks).
612
613    procedure Insert_Before_And_Analyze
614      (N : Node_Id; M : Node_Id);
615    procedure Insert_Before_And_Analyze
616      (N : Node_Id; M : Node_Id; Suppress : Check_Id);
617    --  Inserts node M before node N and then after the insertion is complete,
618    --  analyzes the inserted node and all nodes that could be generated by
619    --  this analysis. If the node is empty, the call has no effect. If the
620    --  Suppress argument is present, then the analysis is done with the
621    --  specified check suppressed (can be All_Checks to suppress all checks).
622
623    function External_Ref_In_Generic (E : Entity_Id) return Boolean;
624    --  Return True if we are in the context of a generic and E is
625    --  external (more global) to it.
626
627    procedure Enter_Generic_Scope (S : Entity_Id);
628    --  Shall be called each time a Generic subprogram or package scope is
629    --  entered. S is the entity of the scope.
630    --  ??? At the moment, only called for package specs because this mechanism
631    --  is only used for avoiding freezing of external references in generics
632    --  and this can only be an issue if the outer generic scope is a package
633    --  spec (otherwise all external entities are already frozen)
634
635    procedure Exit_Generic_Scope  (S : Entity_Id);
636    --  Shall be called each time a Generic subprogram or package scope is
637    --  exited. S is the entity of the scope.
638    --  ??? At the moment, only called for package specs exit.
639
640    function Explicit_Suppress (E : Entity_Id; C : Check_Id) return Boolean;
641    --  This function returns True if an explicit pragma Suppress for check C
642    --  is present in the package defining E.
643
644    procedure Preanalyze (N : Node_Id);
645    --  Performs a pre-analysis of node N. During pre-analysis no expansion is
646    --  carried out for N or its children. For more info on pre-analysis read
647    --  the spec of Sem.
648
649    generic
650       with procedure Action (Item : Node_Id);
651    procedure Walk_Library_Items;
652    --  Primarily for use by SofCheck Inspector. Must be called after semantic
653    --  analysis (and expansion) are complete. Walks each relevant library item,
654    --  calling Action for each, in an order such that one will not run across
655    --  forward references. Each Item passed to Action is the declaration or
656    --  body of a library unit, including generics and renamings. The first item
657    --  is the N_Package_Declaration node for package Standard. Bodies are not
658    --  included, except for the main unit itself, which always comes last.
659    --
660    --  Item is never a subunit
661    --
662    --  Item is never an instantiation. Instead, the instance declaration is
663    --  passed, and (if the instantiation is the main unit), the instance body.
664
665    --  Debugging:
666
667    function ss (Index : Int) return Scope_Stack_Entry;
668    pragma Export (Ada, ss);
669    --  "ss" = "scope stack"; returns the Index'th entry in the Scope_Stack
670
671    function sst return Scope_Stack_Entry;
672    pragma Export (Ada, sst);
673    --  "sst" = "scope stack top"; same as ss(Scope_Stack.Last)
674
675 end Sem;