OpenCores
URL https://opencores.org/ocsvn/openrisc_me/openrisc_me/trunk

Subversion Repositories openrisc_me

[/] [openrisc/] [trunk/] [gnu-src/] [gcc-4.5.1/] [gcc/] [ada/] [sem.ads] - Blame information for rev 281

Details | Compare with Previous | View Log

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

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.