1------------------------------------------------------------------------------
2--                                                                          --
3--                         GNAT COMPILER COMPONENTS                         --
4--                                                                          --
5--                                  S E M                                   --
6--                                                                          --
7--                                 S p e c                                  --
8--                                                                          --
9--          Copyright (C) 1992-2019, 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-- Preanalysis --
165------------------
166
167--  For certain kind of expressions, such as aggregates, we need to defer
168--  expansion of the aggregate and its inner expressions until 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 this mechanism does not work is that the expanded code for the
181--  children is typically inserted above the parent and thus when the father
182--  gets expanded no re-evaluation takes place. For instance in the case of
183--  aggregates if "new Thing (Function_Call)" is expanded before the aggregate
184--  the expanded code will be placed outside of the aggregate and when
185--  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 flag that signals whether we want a
189--  full analysis (i.e. expansion is enabled) or a preanalysis which performs
190--  Analysis and Resolution but no expansion.
191
192--  After the complete preanalysis 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--  preanalysis 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
204with Alloc;
205with Einfo;  use Einfo;
206with Opt;    use Opt;
207with Table;
208with Types;  use Types;
209
210package Sem is
211
212   -----------------------------
213   -- Semantic Analysis Flags --
214   -----------------------------
215
216   Full_Analysis : Boolean := True;
217   --  Switch to indicate if we are doing a full analysis or a preanalysis.
218   --  In normal analysis mode (Analysis-Expansion for instructions or
219   --  declarations) or (Analysis-Resolution-Expansion for expressions) this
220   --  flag is set. Note that if we are not generating code the expansion phase
221   --  merely sets the Analyzed flag to True in this case. If we are in
222   --  Preanalysis mode (see above) this flag is set to False then the
223   --  expansion phase is skipped.
224   --
225   --  When this flag is False the flag Expander_Active is also False (the
226   --  Expander_Active flag defined in the spec of package Expander tells you
227   --  whether expansion is currently enabled). You should really regard this
228   --  as a read only flag.
229
230   In_Spec_Expression : Boolean := False;
231   --  Switch to indicate that we are in a spec-expression, as described
232   --  above. Note that this must be recursively saved on a Semantics call
233   --  since it is possible for the analysis of an expression to result in a
234   --  recursive call (e.g. to get the entity for System.Address as part of the
235   --  processing of an Address attribute reference). When this switch is True
236   --  then Full_Analysis above must be False. You should really regard this as
237   --  a read only flag.
238
239   In_Deleted_Code : Boolean := False;
240   --  If the condition in an if-statement is statically known, the branch
241   --  that is not taken is analyzed with expansion disabled, and the tree
242   --  is deleted after analysis. Itypes generated in deleted code must be
243   --  frozen from start, because the tree on which they depend will not
244   --  be available at the freeze point.
245
246   In_Assertion_Expr : Nat := 0;
247   --  This is set non-zero if we are within the expression of an assertion
248   --  pragma or aspect. It is a counter which is incremented at the start of
249   --  expanding such an expression, and decremented on completion of expanding
250   --  that expression. Probably a boolean would be good enough, since we think
251   --  that such expressions cannot nest, but that might not be true in the
252   --  future (e.g. if let expressions are added to Ada) so we prepare for that
253   --  future possibility by making it a counter. As with In_Spec_Expression,
254   --  it must be recursively saved and restored for a Semantics call.
255
256   In_Compile_Time_Warning_Or_Error : Boolean := False;
257   --  Switch to indicate that we are validating a pragma Compile_Time_Warning
258   --  or Compile_Time_Error after the back end has been called (to check these
259   --  pragmas for size and alignment appropriateness).
260
261   In_Default_Expr : Boolean := False;
262   --  Switch to indicate that we are analyzing a default component expression.
263   --  As with In_Spec_Expression, it must be recursively saved and restored
264   --  for a Semantics call.
265
266   In_Inlined_Body : Boolean := False;
267   --  Switch to indicate that we are analyzing and resolving an inlined body.
268   --  Type checking is disabled in this context, because types are known to be
269   --  compatible. This avoids problems with private types whose full view is
270   --  derived from private types.
271
272   Inside_A_Generic : Boolean := False;
273   --  This flag is set if we are processing a generic specification, generic
274   --  definition, or generic body. When this flag is True the Expander_Active
275   --  flag is False to disable any code expansion (see package Expander). Only
276   --  the generic processing can modify the status of this flag, any other
277   --  client should regard it as read-only.
278
279   Inside_Freezing_Actions : Nat := 0;
280   --  Flag indicating whether we are within a call to Expand_N_Freeze_Actions.
281   --  Non-zero means we are inside (it is actually a level counter to deal
282   --  with nested calls). Used to avoid traversing the tree each time a
283   --  subprogram call is processed to know if we must not clear all constant
284   --  indications from entities in the current scope. Only the expansion of
285   --  freezing nodes can modify the status of this flag, any other client
286   --  should regard it as read-only.
287
288   Inside_Preanalysis_Without_Freezing : Nat := 0;
289   --  Flag indicating whether we are preanalyzing an expression performing no
290   --  freezing. Non-zero means we are inside (it is actually a level counter
291   --  to deal with nested calls).
292
293   Unloaded_Subunits : Boolean := False;
294   --  This flag is set True if we have subunits that are not loaded. This
295   --  occurs when the main unit is a subunit, and contains lower level
296   --  subunits that are not loaded. We use this flag to suppress warnings
297   --  about unused variables, since these warnings are unreliable in this
298   --  case. We could perhaps do a more accurate job and retain some of the
299   --  warnings, but it is quite a tricky job.
300
301   -----------------------------------
302   -- Handling of Check Suppression --
303   -----------------------------------
304
305   --  There are two kinds of suppress checks: scope based suppress checks,
306   --  and entity based suppress checks.
307
308   --  Scope based suppress checks for the predefined checks (from initial
309   --  command line arguments, or from Suppress pragmas not including an entity
310   --  name) are recorded in the Sem.Scope_Suppress variable, and all that
311   --  is necessary is to save the state of this variable on scope entry, and
312   --  restore it on scope exit. This mechanism allows for fast checking of the
313   --  scope suppress state without needing complex data structures.
314
315   --  Entity based checks, from Suppress/Unsuppress pragmas giving an
316   --  Entity_Id and scope based checks for non-predefined checks (introduced
317   --  using pragma Check_Name), are handled as follows. If a suppress or
318   --  unsuppress pragma is encountered for a given entity, then the flag
319   --  Checks_May_Be_Suppressed is set in the entity and an entry is made in
320   --  either the Local_Entity_Suppress stack (case of pragma that appears in
321   --  other than a package spec), or in the Global_Entity_Suppress stack (case
322   --  of pragma that appears in a package spec, which is by the rule of RM
323   --  11.5(7) applicable throughout the life of the entity). Similarly, a
324   --  Suppress/Unsuppress pragma for a non-predefined check which does not
325   --  specify an entity is also stored in one of these stacks.
326
327   --  If the Checks_May_Be_Suppressed flag is set in an entity then the
328   --  procedure is to search first the local and then the global suppress
329   --  stacks (we search these in reverse order, top element first). The only
330   --  other point is that we have to make sure that we have proper nested
331   --  interaction between such specific pragmas and locally applied general
332   --  pragmas applying to all entities. This is achieved by including in the
333   --  Local_Entity_Suppress table dummy entries with an empty Entity field
334   --  that are applicable to all entities. A similar search is needed for any
335   --  non-predefined check even if no specific entity is involved.
336
337   Scope_Suppress : Suppress_Record;
338   --  This variable contains the current scope based settings of the suppress
339   --  switches. It is initialized from Suppress_Options in Gnat1drv, and then
340   --  modified by pragma Suppress. On entry to each scope, the current setting
341   --  is saved on the scope stack, and then restored on exit from the scope.
342   --  This record may be rapidly checked to determine the current status of
343   --  a check if no specific entity is involved or if the specific entity
344   --  involved is one for which no specific Suppress/Unsuppress pragma has
345   --  been set (as indicated by the Checks_May_Be_Suppressed flag being set).
346
347   --  This scheme is a little complex, but serves the purpose of enabling
348   --  a very rapid check in the common case where no entity specific pragma
349   --  applies, and gives the right result when such pragmas are used even
350   --  in complex cases of nested Suppress and Unsuppress pragmas.
351
352   --  The Local_Entity_Suppress and Global_Entity_Suppress stacks are handled
353   --  using dynamic allocation and linked lists. We do not often use this
354   --  approach in the compiler (preferring to use extensible tables instead).
355   --  The reason we do it here is that scope stack entries save a pointer to
356   --  the current local stack top, which is also saved and restored on scope
357   --  exit. Furthermore for processing of generics we save pointers to the
358   --  top of the stack, so that the local stack is actually a tree of stacks
359   --  rather than a single stack, a structure that is easy to represent using
360   --  linked lists, but impossible to represent using a single table. Note
361   --  that because of the generic issue, we never release entries in these
362   --  stacks, but that's no big deal, since we are unlikely to have a huge
363   --  number of Suppress/Unsuppress entries in a single compilation.
364
365   type Suppress_Stack_Entry;
366   type Suppress_Stack_Entry_Ptr is access all Suppress_Stack_Entry;
367
368   type Suppress_Stack_Entry is record
369      Entity : Entity_Id;
370      --  Entity to which the check applies, or Empty for a check that has
371      --  no entity name (and thus applies to all entities).
372
373      Check : Check_Id;
374      --  Check which is set (can be All_Checks for the All_Checks case)
375
376      Suppress : Boolean;
377      --  Set True for Suppress, and False for Unsuppress
378
379      Prev : Suppress_Stack_Entry_Ptr;
380      --  Pointer to previous entry on stack
381
382      Next : Suppress_Stack_Entry_Ptr;
383      --  All allocated Suppress_Stack_Entry records are chained together in
384      --  a linked list whose head is Suppress_Stack_Entries, and the Next
385      --  field is used as a forward pointer (null ends the list). This is
386      --  used to free all entries in Sem.Init (which will be important if
387      --  we ever setup the compiler to be reused).
388   end record;
389
390   Suppress_Stack_Entries : Suppress_Stack_Entry_Ptr := null;
391   --  Pointer to linked list of records (see comments for Next above)
392
393   Local_Suppress_Stack_Top : Suppress_Stack_Entry_Ptr;
394   --  Pointer to top element of local suppress stack. This is the entry that
395   --  is saved and restored in the scope stack, and also saved for generic
396   --  body expansion.
397
398   Global_Suppress_Stack_Top : Suppress_Stack_Entry_Ptr;
399   --  Pointer to top element of global suppress stack
400
401   procedure Push_Local_Suppress_Stack_Entry
402     (Entity   : Entity_Id;
403      Check    : Check_Id;
404      Suppress : Boolean);
405   --  Push a new entry on to the top of the local suppress stack, updating
406   --  the value in Local_Suppress_Stack_Top;
407
408   procedure Push_Global_Suppress_Stack_Entry
409     (Entity   : Entity_Id;
410      Check    : Check_Id;
411      Suppress : Boolean);
412   --  Push a new entry on to the top of the global suppress stack, updating
413   --  the value in Global_Suppress_Stack_Top;
414
415   -----------------
416   -- Scope Stack --
417   -----------------
418
419   --  The scope stack indicates the declarative regions that are currently
420   --  being processed (analyzed and/or expanded). The scope stack is one of
421   --  the basic visibility structures in the compiler: entities that are
422   --  declared in a scope that is currently on the scope stack are immediately
423   --  visible (leaving aside issues of hiding and overloading).
424
425   --  Initially, the scope stack only contains an entry for package Standard.
426   --  When a compilation unit, subprogram unit, block or declarative region
427   --  is being processed, the corresponding entity is pushed on the scope
428   --  stack. It is removed after the processing step is completed. A given
429   --  entity can be placed several times on the scope stack, for example
430   --  when processing derived type declarations, freeze nodes, etc. The top
431   --  of the scope stack is the innermost scope currently being processed.
432   --  It is obtained through function Current_Scope. After a compilation unit
433   --  has been processed, the scope stack must contain only Standard.
434   --  The predicate In_Open_Scopes specifies whether a scope is currently
435   --  on the scope stack.
436
437   --  This model is complicated by the need to compile units on the fly, in
438   --  the middle of the compilation of other units. This arises when compiling
439   --  instantiations, and when compiling run-time packages obtained through
440   --  rtsfind. Given that the scope stack is a single static and global
441   --  structure (not originally designed for the recursive processing required
442   --  by rtsfind for example) additional machinery is needed to indicate what
443   --  is currently being compiled. As a result, the scope stack holds several
444   --  contiguous sections that correspond to the compilation of a given
445   --  compilation unit. These sections are separated by distinct occurrences
446   --  of package Standard. The currently active section of the scope stack
447   --  goes from the current scope to the first (innermost) occurrence of
448   --  Standard, which is additionally marked with flag Is_Active_Stack_Base.
449   --  The basic visibility routine (Find_Direct_Name, in Sem_Ch8) uses this
450   --  contiguous section of the scope stack to determine whether a given
451   --  entity is or is not visible at a point. In_Open_Scopes only examines
452   --  the currently active section of the scope stack.
453
454   --  Similar complications arise when processing child instances. These
455   --  must be compiled in the context of parent instances, and therefore the
456   --  parents must be pushed on the stack before compiling the child, and
457   --  removed afterwards. Routines Save_Scope_Stack and Restore_Scope_Stack
458   --  are used to set/reset the visibility of entities declared in scopes
459   --  that are currently on the scope stack, and are used when compiling
460   --  instance bodies on the fly.
461
462   --  It is clear in retrospect that all semantic processing and visibility
463   --  structures should have been fully recursive. The rtsfind mechanism,
464   --  and the complexities brought about by subunits and by generic child
465   --  units and their instantiations, have led to a hybrid model that carries
466   --  more state than one would wish.
467
468   type Scope_Action_Kind is (Before, After, Cleanup);
469   type Scope_Actions is array (Scope_Action_Kind) of List_Id;
470   --  Transient blocks have three associated actions list, to be inserted
471   --  before and after the block's statements, and as cleanup actions.
472
473   Configuration_Component_Alignment : Component_Alignment_Kind :=
474                                         Calign_Default;
475   --  Used for handling the pragma Component_Alignment in the context of a
476   --  configuration file.
477
478   type Scope_Stack_Entry is record
479      Entity : Entity_Id;
480      --  Entity representing the scope
481
482      Last_Subprogram_Name : String_Ptr;
483      --  Pointer to name of last subprogram body in this scope. Used for
484      --  testing proper alpha ordering of subprogram bodies in scope.
485
486      Save_Scope_Suppress : Suppress_Record;
487      --  Save contents of Scope_Suppress on entry
488
489      Save_Local_Suppress_Stack_Top : Suppress_Stack_Entry_Ptr;
490      --  Save contents of Local_Suppress_Stack on entry to restore on exit
491
492      Save_Check_Policy_List : Node_Id;
493      --  Save contents of Check_Policy_List on entry to restore on exit. The
494      --  Check_Policy pragmas are chained with Check_Policy_List pointing to
495      --  the most recent entry. This list is searched starting here, so that
496      --  the search finds the most recent appicable entry. When we restore
497      --  Check_Policy_List on exit from the scope, the effect is to remove
498      --  all entries set in the scope being exited.
499
500      Save_Default_Storage_Pool : Node_Id;
501      --  Save contents of Default_Storage_Pool on entry to restore on exit
502
503      Save_SPARK_Mode : SPARK_Mode_Type;
504      --  Setting of SPARK_Mode on entry to restore on exit
505
506      Save_SPARK_Mode_Pragma : Node_Id;
507      --  Setting of SPARK_Mode_Pragma on entry to restore on exit
508
509      Save_No_Tagged_Streams : Node_Id;
510      --  Setting of No_Tagged_Streams to restore on exit
511
512      Save_Default_SSO : Character;
513      --  Setting of Default_SSO on entry to restore on exit
514
515      Save_Uneval_Old : Character;
516      --  Setting of Uneval_Old on entry to restore on exit
517
518      Is_Transient : Boolean;
519      --  Marks transient scopes (see Exp_Ch7 body for details)
520
521      Previous_Visibility : Boolean;
522      --  Used when installing the parent(s) of the current compilation unit.
523      --  The parent may already be visible because of an ongoing compilation,
524      --  and the proper visibility must be restored on exit. The flag is
525      --  typically needed when the context of a child unit requires
526      --  compilation of a sibling. In other cases the flag is set to False.
527      --  See Sem_Ch10 (Install_Parents, Remove_Parents).
528
529      Node_To_Be_Wrapped : Node_Id;
530      --  Only used in transient scopes. Records the node which will be wrapped
531      --  by the transient block.
532
533      Actions_To_Be_Wrapped : Scope_Actions;
534      --  Actions that have to be inserted at the start, at the end, or as
535      --  cleanup actions of a transient block. Used to temporarily hold these
536      --  actions until the block is created, at which time the actions are
537      --  moved to the block.
538
539      Pending_Freeze_Actions : List_Id;
540      --  Used to collect freeze entity nodes and associated actions that are
541      --  generated in an inner context but need to be analyzed outside, such
542      --  as records and initialization procedures. On exit from the scope,
543      --  this list of actions is inserted before the scope construct and
544      --  analyzed to generate the corresponding freeze processing and
545      --  elaboration of other associated actions.
546
547      First_Use_Clause : Node_Id;
548      --  Head of list of Use_Clauses in current scope. The list is built when
549      --  the declarations in the scope are processed. The list is traversed
550      --  on scope exit to undo the effect of the use clauses.
551
552      Component_Alignment_Default : Component_Alignment_Kind;
553      --  Component alignment to be applied to any record or array types that
554      --  are declared for which a specific component alignment pragma does not
555      --  set the alignment.
556
557      Is_Active_Stack_Base : Boolean;
558      --  Set to true only when entering the scope for Standard_Standard from
559      --  from within procedure Semantics. Indicates the base of the current
560      --  active set of scopes. Needed by In_Open_Scopes to handle cases where
561      --  Standard_Standard can be pushed anew on the scope stack to start a
562      --  new active section (see comment above).
563
564      Locked_Shared_Objects : Elist_Id;
565      --  List of shared passive protected objects that have been locked in
566      --  this transient scope (always No_Elist for non-transient scopes).
567   end record;
568
569   package Scope_Stack is new Table.Table (
570     Table_Component_Type => Scope_Stack_Entry,
571     Table_Index_Type     => Int,
572     Table_Low_Bound      => 0,
573     Table_Initial        => Alloc.Scope_Stack_Initial,
574     Table_Increment      => Alloc.Scope_Stack_Increment,
575     Table_Name           => "Sem.Scope_Stack");
576
577   -----------------
578   -- Subprograms --
579   -----------------
580
581   procedure Initialize;
582   --  Initialize internal tables
583
584   procedure Lock;
585   --  Lock internal tables before calling back end
586
587   procedure Unlock;
588   --  Unlock internal tables
589
590   procedure Semantics (Comp_Unit : Node_Id);
591   --  This procedure is called to perform semantic analysis on the specified
592   --  node which is the N_Compilation_Unit node for the unit.
593
594   procedure Analyze (N : Node_Id);
595   procedure Analyze (N : Node_Id; Suppress : Check_Id);
596   --  This is the recursive procedure that is applied to individual nodes of
597   --  the tree, starting at the top level node (compilation unit node) and
598   --  then moving down the tree in a top down traversal. It calls individual
599   --  routines with names Analyze_xxx to analyze node xxx. Each of these
600   --  routines is responsible for calling Analyze on the components of the
601   --  subtree.
602   --
603   --  Note: In the case of expression components (nodes whose Nkind is in
604   --  N_Subexpr), the call to Analyze does not complete the semantic analysis
605   --  of the node, since the type resolution cannot be completed until the
606   --  complete context is analyzed. The completion of the type analysis occurs
607   --  in the corresponding Resolve routine (see Sem_Res).
608   --
609   --  Note: for integer and real literals, the analyzer sets the flag to
610   --  indicate that the result is a static expression. If the expander
611   --  generates a literal that does NOT correspond to a static expression,
612   --  e.g. by folding an expression whose value is known at compile time,
613   --  but is not technically static, then the caller should reset the
614   --  Is_Static_Expression flag after analyzing but before resolving.
615   --
616   --  If the Suppress argument is present, then the analysis is done
617   --  with the specified check suppressed (can be All_Checks to suppress
618   --  all checks).
619
620   procedure Analyze_List (L : List_Id);
621   procedure Analyze_List (L : List_Id; Suppress : Check_Id);
622   --  Analyzes each element of a list. If the Suppress argument is present,
623   --  then the analysis is done with the specified check suppressed (can
624   --  be All_Checks to suppress all checks).
625
626   procedure Copy_Suppress_Status
627     (C    : Check_Id;
628      From : Entity_Id;
629      To   : Entity_Id);
630   --  If From is an entity for which check C is explicitly suppressed
631   --  then also explicitly suppress the corresponding check in To.
632
633   procedure Insert_List_After_And_Analyze
634     (N : Node_Id; L : List_Id);
635   --  Inserts list L after node N using Nlists.Insert_List_After, and then,
636   --  after this insertion is complete, analyzes all the nodes in the list,
637   --  including any additional nodes generated by this analysis. If the list
638   --  is empty or No_List, the call has no effect.
639
640   procedure Insert_List_Before_And_Analyze
641     (N : Node_Id; L : List_Id);
642   --  Inserts list L before node N using Nlists.Insert_List_Before, and then,
643   --  after this insertion is complete, analyzes all the nodes in the list,
644   --  including any additional nodes generated by this analysis. If the list
645   --  is empty or No_List, the call has no effect.
646
647   procedure Insert_After_And_Analyze
648     (N : Node_Id; M : Node_Id);
649   procedure Insert_After_And_Analyze
650     (N : Node_Id; M : Node_Id; Suppress : Check_Id);
651   --  Inserts node M after node N and then after the insertion is complete,
652   --  analyzes the inserted node and all nodes that are generated by
653   --  this analysis. If the node is empty, the call has no effect. If the
654   --  Suppress argument is present, then the analysis is done with the
655   --  specified check suppressed (can be All_Checks to suppress all checks).
656
657   procedure Insert_Before_And_Analyze
658     (N : Node_Id; M : Node_Id);
659   procedure Insert_Before_And_Analyze
660     (N : Node_Id; M : Node_Id; Suppress : Check_Id);
661   --  Inserts node M before node N and then after the insertion is complete,
662   --  analyzes the inserted node and all nodes that could be generated by
663   --  this analysis. If the node is empty, the call has no effect. If the
664   --  Suppress argument is present, then the analysis is done with the
665   --  specified check suppressed (can be All_Checks to suppress all checks).
666
667   function External_Ref_In_Generic (E : Entity_Id) return Boolean;
668   --  Return True if we are in the context of a generic and E is
669   --  external (more global) to it.
670
671   procedure Enter_Generic_Scope (S : Entity_Id);
672   --  Called each time a Generic subprogram or package scope is entered. S is
673   --  the entity of the scope.
674   --
675   --  ??? At the moment, only called for package specs because this mechanism
676   --  is only used for avoiding freezing of external references in generics
677   --  and this can only be an issue if the outer generic scope is a package
678   --  spec (otherwise all external entities are already frozen)
679
680   procedure Exit_Generic_Scope  (S : Entity_Id);
681   --  Called each time a Generic subprogram or package scope is exited. S is
682   --  the entity of the scope.
683   --
684   --  ??? At the moment, only called for package specs exit.
685
686   function Explicit_Suppress (E : Entity_Id; C : Check_Id) return Boolean;
687   --  This function returns True if an explicit pragma Suppress for check C
688   --  is present in the package defining E.
689
690   function Preanalysis_Active return Boolean;
691   pragma Inline (Preanalysis_Active);
692   --  Determine whether preanalysis is active at the point of invocation
693
694   procedure Preanalyze (N : Node_Id);
695   --  Performs a preanalysis of node N. During preanalysis no expansion is
696   --  carried out for N or its children. See above for more info on
697   --  preanalysis.
698
699   generic
700      with procedure Action (Item : Node_Id);
701   procedure Walk_Library_Items;
702   --  Primarily for use by CodePeer and GNATprove. Must be called after
703   --  semantic analysis (and expansion in the case of CodePeer) are complete.
704   --  Walks each relevant library item, calling Action for each, in an order
705   --  such that one will not run across forward references. Each Item passed
706   --  to Action is the declaration or body of a library unit, including
707   --  generics and renamings. The first item is the N_Package_Declaration node
708   --  for package Standard. Bodies are not included, except for the main unit
709   --  itself, which always comes last.
710   --
711   --  Item is never a subunit
712   --
713   --  Item is never an instantiation. Instead, the instance declaration is
714   --  passed, and (if the instantiation is the main unit), the instance body.
715
716   ------------------------
717   -- Debugging Routines --
718   ------------------------
719
720   function ss (Index : Int) return Scope_Stack_Entry;
721   pragma Export (Ada, ss);
722   --  "ss" = "scope stack"; returns the Index'th entry in the Scope_Stack
723
724   function sst return Scope_Stack_Entry;
725   pragma Export (Ada, sst);
726   --  "sst" = "scope stack top"; same as ss(Scope_Stack.Last)
727
728end Sem;
729