1 ------------------------------------------------------------------------------
3 -- GNAT COMPILER COMPONENTS --
9 -- Copyright (C) 1992-2023, Free Software Foundation, Inc. --
11 -- GNAT is free software; you can redistribute it and/or modify it under --
12 -- terms of the GNU General Public License as published by the Free Soft- --
13 -- ware Foundation; either version 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. --
21 -- GNAT was originally developed by the GNAT team at New York University. --
22 -- Extensive contributions were provided by Ada Core Technologies Inc. --
24 ------------------------------------------------------------------------------
26 --------------------------------------
27 -- Semantic Analysis: General Model --
28 --------------------------------------
30 -- Semantic processing involves 3 phases which are highly intertwined
31 -- (i.e. mutually recursive):
33 -- Analysis implements the bulk of semantic analysis such as
34 -- name analysis and type resolution for declarations,
35 -- statements, 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.
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.
53 -- Expansion If we are not generating code this phase is a no-op.
54 -- Otherwise this phase expands, i.e. transforms, original
55 -- source constructs into simpler constructs that can be
56 -- handled by the back-end. This phase is also in charge of
57 -- generating code which is implicit in the original source
58 -- (for instance for default initializations, controlled types,
59 -- etc.) There are two separate instances where expansion is
60 -- invoked. For declarations and instructions, expansion is
61 -- invoked just after analysis since no resolution needs to be
62 -- performed. For expressions, expansion is done just after
63 -- resolution. In both cases expansion is done from the bottom
64 -- up just before the end of Analyze for instructions and
65 -- declarations or the call to Resolve for expressions. The
66 -- main routine driving expansion is Expand. See the spec of
67 -- Expander for more details.
69 -- To summarize, in normal code generation mode we recursively traverse the
70 -- abstract syntax tree top-down performing semantic analysis bottom
71 -- up. For instructions and declarations, before the call to the Analyze
72 -- routine completes we perform expansion since at that point we have all
73 -- semantic information needed. For expression nodes, after the call to
74 -- Analyze terminates we invoke the Resolve routine to transmit top-down
75 -- the type that was gathered by Analyze which will resolve possible
76 -- ambiguities in the expression. Just before the call to Resolve
77 -- terminates, the expression can be expanded since all the semantic
78 -- information is available at that point.
80 -- If we are not generating code then the expansion phase is a no-op
82 -- When generating code there are a number of exceptions to the basic
83 -- Analysis-Resolution-Expansion model for expressions. The most prominent
84 -- examples are the handling of default expressions and aggregates.
86 -----------------------------------------------------------------------
87 -- Handling of Default and Per-Object Expressions (Spec-Expressions) --
88 -----------------------------------------------------------------------
90 -- The default expressions in component declarations and in procedure
91 -- specifications (but not the ones in object declarations) are quite tricky
92 -- to handle. The problem is that some processing is required at the point
93 -- where the expression appears:
95 -- visibility analysis (including user defined operators)
96 -- freezing of static expressions
98 -- but other processing must be deferred until the enclosing entity (record or
99 -- procedure specification) is frozen:
101 -- freezing of any other types in the expression expansion
102 -- generation of code
104 -- A similar situation occurs with the argument of priority and interrupt
105 -- priority pragmas that appear in task and protected definition specs and
106 -- other cases of per-object expressions (see RM 3.8(18)).
108 -- Another similar case is the conditions in precondition and postcondition
109 -- pragmas that appear with subprogram specifications rather than in the body.
111 -- Collectively we call these Spec_Expressions. The routine that performs the
112 -- special analysis is called Preanalyze_Spec_Expression.
114 -- Expansion has to be deferred since you can't generate code for expressions
115 -- that reference types that have not been frozen yet. As an example, consider
118 -- type x is delta 0.5 range -10.0 .. +10.0;
124 -- for x'small use 0.25;
126 -- The expander is in charge of dealing with fixed-point, and of course the
127 -- small declaration, which is not too late, since the declaration of type q
128 -- does *not* freeze type x, definitely affects the expanded code.
130 -- Another reason that we cannot expand early is that expansion can generate
131 -- range checks. These range checks need to be inserted not at the point of
132 -- definition but at the point of use. The whole point here is that the value
133 -- of the expression cannot be obtained at the point of declaration, only at
136 -- Generally our model is to combine analysis, resolution, and expansion, but
137 -- this is the one case where this model falls down. Here is how we patch
138 -- it up without causing too much distortion to our basic model.
140 -- A flag (In_Spec_Expression) is set to show that we are in the initial
141 -- occurrence of a default expression. The analyzer is then called on this
142 -- expression with the switch set true. Analysis and resolution proceed almost
143 -- as usual, except that Freeze_Expression will not freeze non-static
144 -- expressions if this switch is set, and the call to Expand at the end of
145 -- resolution is skipped. This also skips the code that normally sets the
146 -- Analyzed flag to True. The result is that when we are done the tree is
147 -- still marked as unanalyzed, but all types for static expressions are frozen
148 -- as required, and all entities of variables have been recorded. We then turn
149 -- off the switch, and later on reanalyze the expression with the switch off.
150 -- The effect is that this second analysis freezes the rest of the types as
151 -- required, and generates code but visibility analysis is not repeated since
152 -- all the entities are marked.
154 -- The second analysis (the one that generates code) is in the context
155 -- where the code is required. For a record field default, this is in the
156 -- initialization procedure for the record and for a subprogram default
157 -- parameter, it is at the point the subprogram is frozen. For a priority or
158 -- storage size pragma it is in the context of the Init_Proc for the task or
159 -- protected object. For a pre/postcondition pragma it is in the body when
160 -- code for the pragma is generated.
166 -- For certain kind of expressions, such as aggregates, we need to defer
167 -- expansion of the aggregate and its inner expressions until after the whole
168 -- set of expressions appearing inside the aggregate have been analyzed.
169 -- Consider, for instance the following example:
171 -- (1 .. 100 => new Thing (Function_Call))
173 -- The normal Analysis-Resolution-Expansion mechanism where expansion of the
174 -- children is performed before expansion of the parent does not work if the
175 -- code generated for the children by the expander needs to be evaluated
176 -- repeatedly (for instance in the above aggregate "new Thing (Function_Call)"
177 -- needs to be called 100 times).
179 -- The reason this mechanism does not work is that the expanded code for the
180 -- children is typically inserted above the parent and thus when the parent
181 -- gets expanded no re-evaluation takes place. For instance in the case of
182 -- aggregates if "new Thing (Function_Call)" is expanded before the aggregate
183 -- the expanded code will be placed outside of the aggregate and when
184 -- expanding the aggregate the loop from 1 to 100 will not surround the
185 -- expanded code for "new Thing (Function_Call)".
187 -- To remedy this situation we introduce a flag that signals whether we want a
188 -- full analysis (i.e. expansion is enabled) or a preanalysis which performs
189 -- Analysis and Resolution but no expansion.
191 -- After the complete preanalysis of an expression has been carried out we
192 -- can transform the expression and then carry out the full three stage
193 -- (Analyze-Resolve-Expand) cycle on the transformed expression top-down so
194 -- that the expansion of inner expressions happens inside the newly generated
195 -- node for the parent expression.
197 -- Note that the difference between processing of default expressions and
198 -- preanalysis of other expressions is that we do carry out freezing in
199 -- the latter but not in the former (except for static scalar expressions).
200 -- The routine that performs preanalysis and corresponding resolution is
201 -- called Preanalyze_And_Resolve and is in Sem_Res.
206 with Types
; use Types
;
210 -----------------------------
211 -- Semantic Analysis Flags --
212 -----------------------------
214 Full_Analysis
: Boolean := True;
215 -- Switch to indicate if we are doing a full analysis or a preanalysis.
216 -- In normal analysis mode (Analysis-Expansion for instructions or
217 -- declarations) or (Analysis-Resolution-Expansion for expressions) this
218 -- flag is set. Note that if we are not generating code the expansion phase
219 -- merely sets the Analyzed flag to True in this case. If we are in
220 -- Preanalysis mode (see above) this flag is set to False then the
221 -- expansion phase is skipped.
223 -- When this flag is False the flag Expander_Active is also False (the
224 -- Expander_Active flag defined in the spec of package Expander tells you
225 -- whether expansion is currently enabled). You should really regard this
226 -- as a read only flag.
228 In_Spec_Expression
: Boolean := False;
229 -- Switch to indicate that we are in a spec-expression, as described
230 -- above. Note that this must be recursively saved on a Semantics call
231 -- since it is possible for the analysis of an expression to result in a
232 -- recursive call (e.g. to get the entity for System.Address as part of the
233 -- processing of an Address attribute reference). When this switch is True
234 -- then Full_Analysis above must be False. You should really regard this as
237 In_Deleted_Code
: Boolean := False;
238 -- If the condition in an if-statement is statically known, the branch
239 -- that is not taken is analyzed with expansion disabled, and the tree
240 -- is deleted after analysis. Itypes generated in deleted code must be
241 -- frozen from start, because the tree on which they depend will not
242 -- be available at the freeze point.
244 In_Assertion_Expr
: Nat
:= 0;
245 -- This is set non-zero if we are within the expression of an assertion
246 -- pragma or aspect. It is incremented at the start of expanding such an
247 -- expression, and decremented on completion of expanding that
248 -- expression. This needs to be a counter, rather than a Boolean, because
249 -- assertions can contain declare_expressions, which can contain
250 -- assertions. As with In_Spec_Expression, it must be recursively saved and
251 -- restored for a Semantics call.
253 In_Declare_Expr
: Nat
:= 0;
254 -- This is set non-zero if we are within a declare_expression. It is
255 -- incremented at the start of expanding such an expression, and
256 -- decremented on completion of expanding that expression. This needs to be
257 -- a counter, rather than a Boolean, because declare_expressions can
258 -- nest. As with In_Spec_Expression, it must be recursively saved and
259 -- restored for a Semantics call.
261 In_Compile_Time_Warning_Or_Error
: Boolean := False;
262 -- Switch to indicate that we are validating a pragma Compile_Time_Warning
263 -- or Compile_Time_Error after the back end has been called (to check these
264 -- pragmas for size and alignment appropriateness).
266 In_Default_Expr
: Boolean := False;
267 -- Switch to indicate that we are analyzing a default component expression.
268 -- As with In_Spec_Expression, it must be recursively saved and restored
269 -- for a Semantics call.
271 In_Inlined_Body
: Boolean := False;
272 -- Switch to indicate that we are analyzing and resolving an inlined body.
273 -- Type checking is disabled in this context, because types are known to be
274 -- compatible. This avoids problems with private types whose full view is
275 -- derived from private types.
277 Inside_A_Generic
: Boolean := False;
278 -- This flag is set if we are processing a generic specification, generic
279 -- definition, or generic body. When this flag is True the Expander_Active
280 -- flag is False to disable any code expansion (see package Expander). Only
281 -- the generic processing can modify the status of this flag, any other
282 -- client should regard it as read-only.
284 Inside_Freezing_Actions
: Nat
:= 0;
285 -- Flag indicating whether we are within a call to Expand_N_Freeze_Actions.
286 -- Non-zero means we are inside (it is actually a level counter to deal
287 -- with nested calls). Used to avoid traversing the tree each time a
288 -- subprogram call is processed to know if we must not clear all constant
289 -- indications from entities in the current scope. Only the expansion of
290 -- freezing nodes can modify the status of this flag, any other client
291 -- should regard it as read-only.
293 Inside_Class_Condition_Preanalysis
: Boolean := False;
294 -- Flag indicating whether we are preanalyzing a class-wide precondition
297 Inside_Preanalysis_Without_Freezing
: Nat
:= 0;
298 -- Flag indicating whether we are preanalyzing an expression performing no
299 -- freezing. Non-zero means we are inside (it is actually a level counter
300 -- to deal with nested calls).
302 Unloaded_Subunits
: Boolean := False;
303 -- This flag is set True if we have subunits that are not loaded. This
304 -- occurs when the main unit is a subunit, and contains lower level
305 -- subunits that are not loaded. We use this flag to suppress warnings
306 -- about unused variables, since these warnings are unreliable in this
307 -- case. We could perhaps do a more accurate job and retain some of the
308 -- warnings, but it is quite a tricky job.
310 -----------------------------------
311 -- Handling of Check Suppression --
312 -----------------------------------
314 -- There are two kinds of suppress checks: scope based suppress checks,
315 -- and entity based suppress checks.
317 -- Scope based suppress checks for the predefined checks (from initial
318 -- command line arguments, or from Suppress pragmas not including an entity
319 -- name) are recorded in the Sem.Scope_Suppress variable, and all that
320 -- is necessary is to save the state of this variable on scope entry, and
321 -- restore it on scope exit. This mechanism allows for fast checking of the
322 -- scope suppress state without needing complex data structures.
324 -- Entity based checks, from Suppress/Unsuppress pragmas giving an
325 -- Entity_Id and scope based checks for non-predefined checks (introduced
326 -- using pragma Check_Name), are handled as follows. If a suppress or
327 -- unsuppress pragma is encountered for a given entity, then the flag
328 -- Checks_May_Be_Suppressed is set in the entity and an entry is made in
329 -- either the local suppress stack (case of pragma that appears in
330 -- other than a package spec), or in the global suppress stack (case
331 -- of pragma that appears in a package spec, which is by the rule of RM
332 -- 11.5(7) applicable throughout the life of the entity). Similarly, a
333 -- Suppress/Unsuppress pragma for a non-predefined check which does not
334 -- specify an entity is also stored in one of these stacks.
336 -- If the Checks_May_Be_Suppressed flag is set in an entity then the
337 -- procedure is to search first the local and then the global suppress
338 -- stacks (we search these in reverse order, top element first). The only
339 -- other point is that we have to make sure that we have proper nested
340 -- interaction between such specific pragmas and locally applied general
341 -- pragmas applying to all entities. This is achieved by including in the
342 -- local suppress stack dummy entries with an empty Entity field
343 -- that are applicable to all entities. A similar search is needed for any
344 -- non-predefined check even if no specific entity is involved.
346 Scope_Suppress
: Suppress_Record
;
347 -- This variable contains the current scope based settings of the suppress
348 -- switches. It is initialized from Suppress_Options in Gnat1drv, and then
349 -- modified by pragma Suppress. On entry to each scope, the current setting
350 -- is saved on the scope stack, and then restored on exit from the scope.
351 -- This record may be rapidly checked to determine the current status of
352 -- a check if no specific entity is involved or if the specific entity
353 -- involved is one for which no specific Suppress/Unsuppress pragma has
354 -- been set (as indicated by the Checks_May_Be_Suppressed flag being set).
356 -- This scheme is a little complex, but serves the purpose of enabling
357 -- a very rapid check in the common case where no entity specific pragma
358 -- applies, and gives the right result when such pragmas are used even
359 -- in complex cases of nested Suppress and Unsuppress pragmas.
361 -- The local and global suppress stacks are handled using dynamic
362 -- allocation and linked lists. We do not often use this approach in the
363 -- compiler (preferring to use extensible tables instead). The reason we do
364 -- it here is that scope stack entries save a pointer to the current local
365 -- stack top, which is also saved and restored on scope exit. Furthermore
366 -- for processing of generics we save pointers to the top of the stack, so
367 -- that the local stack is actually a tree of stacks rather than a single
368 -- stack, a structure that is easy to represent using linked lists, but
369 -- impossible to represent using a single table. Note that because of the
370 -- generic issue, we never release entries in these stacks, but that's no
371 -- big deal, since we are unlikely to have a huge number of
372 -- Suppress/Unsuppress entries in a single compilation.
374 type Suppress_Stack_Entry
;
375 type Suppress_Stack_Entry_Ptr
is access all Suppress_Stack_Entry
;
377 type Suppress_Stack_Entry
is record
379 -- Entity to which the check applies, or Empty for a check that has
380 -- no entity name (and thus applies to all entities).
383 -- Check which is set (can be All_Checks for the All_Checks case)
386 -- Set True for Suppress, and False for Unsuppress
388 Prev
: Suppress_Stack_Entry_Ptr
;
389 -- Pointer to previous entry on stack
391 Next
: Suppress_Stack_Entry_Ptr
;
392 -- All allocated Suppress_Stack_Entry records are chained together in
393 -- a linked list whose head is Suppress_Stack_Entries, and the Next
394 -- field is used as a forward pointer (null ends the list). This is
395 -- used to free all entries in Sem.Init (which will be important if
396 -- we ever setup the compiler to be reused).
399 Suppress_Stack_Entries
: Suppress_Stack_Entry_Ptr
:= null;
400 -- Pointer to linked list of records (see comments for Next above)
402 Local_Suppress_Stack_Top
: Suppress_Stack_Entry_Ptr
;
403 -- Pointer to top element of local suppress stack. This is the entry that
404 -- is saved and restored in the scope stack, and also saved for generic
407 Global_Suppress_Stack_Top
: Suppress_Stack_Entry_Ptr
;
408 -- Pointer to top element of global suppress stack
410 procedure Push_Local_Suppress_Stack_Entry
414 -- Push a new entry on to the top of the local suppress stack, updating
415 -- the value in Local_Suppress_Stack_Top;
417 procedure Push_Global_Suppress_Stack_Entry
421 -- Push a new entry on to the top of the global suppress stack, updating
422 -- the value in Global_Suppress_Stack_Top;
428 -- The scope stack indicates the declarative regions that are currently
429 -- being processed (analyzed and/or expanded). The scope stack is one of
430 -- the basic visibility structures in the compiler: entities that are
431 -- declared in a scope that is currently on the scope stack are immediately
432 -- visible (leaving aside issues of hiding and overloading).
434 -- Initially, the scope stack only contains an entry for package Standard.
435 -- When a compilation unit, subprogram unit, block or declarative region
436 -- is being processed, the corresponding entity is pushed on the scope
437 -- stack. It is removed after the processing step is completed. A given
438 -- entity can be placed several times on the scope stack, for example
439 -- when processing derived type declarations, freeze nodes, etc. The top
440 -- of the scope stack is the innermost scope currently being processed.
441 -- It is obtained through function Current_Scope. After a compilation unit
442 -- has been processed, the scope stack must contain only Standard.
443 -- The predicate In_Open_Scopes specifies whether a scope is currently
444 -- on the scope stack.
446 -- This model is complicated by the need to compile units on the fly, in
447 -- the middle of the compilation of other units. This arises when compiling
448 -- instantiations, and when compiling run-time packages obtained through
449 -- rtsfind. Given that the scope stack is a single static and global
450 -- structure (not originally designed for the recursive processing required
451 -- by rtsfind for example) additional machinery is needed to indicate what
452 -- is currently being compiled. As a result, the scope stack holds several
453 -- contiguous sections that correspond to the compilation of a given
454 -- compilation unit. These sections are separated by distinct occurrences
455 -- of package Standard. The currently active section of the scope stack
456 -- goes from the current scope to the first (innermost) occurrence of
457 -- Standard, which is additionally marked with flag Is_Active_Stack_Base.
458 -- The basic visibility routine (Find_Direct_Name, in Sem_Ch8) uses this
459 -- contiguous section of the scope stack to determine whether a given
460 -- entity is or is not visible at a point. In_Open_Scopes only examines
461 -- the currently active section of the scope stack.
463 -- Similar complications arise when processing child instances. These
464 -- must be compiled in the context of parent instances, and therefore the
465 -- parents must be pushed on the stack before compiling the child, and
466 -- removed afterwards. Routines Save_Scope_Stack and Restore_Scope_Stack
467 -- are used to set/reset the visibility of entities declared in scopes
468 -- that are currently on the scope stack, and are used when compiling
469 -- instance bodies on the fly.
471 -- It is clear in retrospect that all semantic processing and visibility
472 -- structures should have been fully recursive. The rtsfind mechanism,
473 -- and the complexities brought about by subunits and by generic child
474 -- units and their instantiations, have led to a hybrid model that carries
475 -- more state than one would wish.
477 type Scope_Action_Kind
is (Before
, After
, Cleanup
);
478 type Scope_Actions
is array (Scope_Action_Kind
) of List_Id
;
479 -- Transient blocks have three associated actions list, to be inserted
480 -- before and after the block's statements, and as cleanup actions.
482 Configuration_Component_Alignment
: Component_Alignment_Kind
:=
484 -- Used for handling the pragma Component_Alignment in the context of a
485 -- configuration file.
487 type Scope_Stack_Entry
is record
489 -- Entity representing the scope
491 Last_Subprogram_Name
: String_Ptr
;
492 -- Pointer to name of last subprogram body in this scope. Used for
493 -- testing proper alpha ordering of subprogram bodies in scope.
495 Save_Scope_Suppress
: Suppress_Record
;
496 -- Save contents of Scope_Suppress on entry
498 Save_Local_Suppress_Stack_Top
: Suppress_Stack_Entry_Ptr
;
499 -- Save contents of Local_Suppress_Stack on entry to restore on exit
501 Save_Check_Policy_List
: Node_Id
;
502 -- Save contents of Check_Policy_List on entry to restore on exit. The
503 -- Check_Policy pragmas are chained with Check_Policy_List pointing to
504 -- the most recent entry. This list is searched starting here, so that
505 -- the search finds the most recent applicable entry. When we restore
506 -- Check_Policy_List on exit from the scope, the effect is to remove
507 -- all entries set in the scope being exited.
509 Save_Default_Storage_Pool
: Node_Id
;
510 -- Save contents of Default_Storage_Pool on entry to restore on exit
512 Save_SPARK_Mode
: SPARK_Mode_Type
;
513 -- Setting of SPARK_Mode on entry to restore on exit
515 Save_SPARK_Mode_Pragma
: Node_Id
;
516 -- Setting of SPARK_Mode_Pragma on entry to restore on exit
518 Save_No_Tagged_Streams
: Node_Id
;
519 -- Setting of No_Tagged_Streams to restore on exit
521 Save_Default_SSO
: Character;
522 -- Setting of Default_SSO on entry to restore on exit
524 Save_Uneval_Old
: Character;
525 -- Setting of Uneval_Old on entry to restore on exit
527 Is_Transient
: Boolean;
528 -- Marks transient scopes (see Exp_Ch7 body for details)
530 Previous_Visibility
: Boolean;
531 -- Used when installing the parent(s) of the current compilation unit.
532 -- The parent may already be visible because of an ongoing compilation,
533 -- and the proper visibility must be restored on exit. The flag is
534 -- typically needed when the context of a child unit requires
535 -- compilation of a sibling. In other cases the flag is set to False.
536 -- See Sem_Ch10 (Install_Parents, Remove_Parents).
538 Node_To_Be_Wrapped
: Node_Id
;
539 -- Only used in transient scopes. Records the node that will be wrapped
540 -- by the transient block.
542 Actions_To_Be_Wrapped
: Scope_Actions
;
543 -- Actions that have to be inserted at the start, at the end, or as
544 -- cleanup actions of a transient block. Used to temporarily hold these
545 -- actions until the block is created, at which time the actions are
546 -- moved to the block.
548 Pending_Freeze_Actions
: List_Id
;
549 -- Used to collect freeze entity nodes and associated actions that are
550 -- generated in an inner context but need to be analyzed outside, such
551 -- as records and initialization procedures. On exit from the scope,
552 -- this list of actions is inserted before the scope construct and
553 -- analyzed to generate the corresponding freeze processing and
554 -- elaboration of other associated actions.
556 First_Use_Clause
: Node_Id
;
557 -- Head of list of Use_Clauses in current scope. The list is built when
558 -- the declarations in the scope are processed. The list is traversed
559 -- on scope exit to undo the effect of the use clauses.
561 Component_Alignment_Default
: Component_Alignment_Kind
;
562 -- Component alignment to be applied to any record or array types that
563 -- are declared for which a specific component alignment pragma does not
564 -- set the alignment.
566 Is_Active_Stack_Base
: Boolean;
567 -- Set to true only when entering the scope for Standard_Standard from
568 -- from within procedure Semantics. Indicates the base of the current
569 -- active set of scopes. Needed by In_Open_Scopes to handle cases where
570 -- Standard_Standard can be pushed anew on the scope stack to start a
571 -- new active section (see comment above).
573 Locked_Shared_Objects
: Elist_Id
;
574 -- List of shared passive protected objects that have been locked in
575 -- this transient scope (always No_Elist for non-transient scopes).
578 package Scope_Stack
is new Table
.Table
(
579 Table_Component_Type
=> Scope_Stack_Entry
,
580 Table_Index_Type
=> Int
,
581 Table_Low_Bound
=> 0,
582 Table_Initial
=> Alloc
.Scope_Stack_Initial
,
583 Table_Increment
=> Alloc
.Scope_Stack_Increment
,
584 Table_Name
=> "Sem.Scope_Stack");
590 procedure Initialize
;
591 -- Initialize internal tables
594 -- Lock internal tables before calling back end
597 -- Unlock internal tables
599 procedure Semantics
(Comp_Unit
: Node_Id
);
600 -- This procedure is called to perform semantic analysis on the specified
601 -- node which is the N_Compilation_Unit node for the unit.
603 procedure Analyze
(N
: Node_Id
);
604 procedure Analyze
(N
: Node_Id
; Suppress
: Check_Id
);
605 -- This is the recursive procedure that is applied to individual nodes of
606 -- the tree, starting at the top level node (compilation unit node) and
607 -- then moving down the tree in a top down traversal. It calls individual
608 -- routines with names Analyze_xxx to analyze node xxx. Each of these
609 -- routines is responsible for calling Analyze on the components of the
612 -- Note: In the case of expression components (nodes whose Nkind is in
613 -- N_Subexpr), the call to Analyze does not complete the semantic analysis
614 -- of the node, since the type resolution cannot be completed until the
615 -- complete context is analyzed. The completion of the type analysis occurs
616 -- in the corresponding Resolve routine (see Sem_Res).
618 -- Note: for integer and real literals, the analyzer sets the flag to
619 -- indicate that the result is a static expression. If the expander
620 -- generates a literal that does NOT correspond to a static expression,
621 -- e.g. by folding an expression whose value is known at compile time,
622 -- but is not technically static, then the caller should reset the
623 -- Is_Static_Expression flag after analyzing but before resolving.
625 -- If the Suppress argument is present, then the analysis is done
626 -- with the specified check suppressed (can be All_Checks to suppress
629 procedure Analyze_List
(L
: List_Id
);
630 procedure Analyze_List
(L
: List_Id
; Suppress
: Check_Id
);
631 -- Analyzes each element of a list. If the Suppress argument is present,
632 -- then the analysis is done with the specified check suppressed (can
633 -- be All_Checks to suppress all checks).
635 procedure Copy_Suppress_Status
639 -- If From is an entity for which check C is explicitly suppressed
640 -- then also explicitly suppress the corresponding check in To.
642 procedure Insert_List_After_And_Analyze
643 (N
: Node_Id
; L
: List_Id
);
644 -- Inserts list L after node N using Nlists.Insert_List_After, and then,
645 -- after this insertion is complete, analyzes all the nodes in the list,
646 -- including any additional nodes generated by this analysis. If the list
647 -- is empty or No_List, the call has no effect.
649 procedure Insert_List_Before_And_Analyze
650 (N
: Node_Id
; L
: List_Id
);
651 -- Inserts list L before node N using Nlists.Insert_List_Before, and then,
652 -- after this insertion is complete, analyzes all the nodes in the list,
653 -- including any additional nodes generated by this analysis. If the list
654 -- is empty or No_List, the call has no effect.
656 procedure Insert_After_And_Analyze
657 (N
: Node_Id
; M
: Node_Id
);
658 procedure Insert_After_And_Analyze
659 (N
: Node_Id
; M
: Node_Id
; Suppress
: Check_Id
);
660 -- Inserts node M after node N and then after the insertion is complete,
661 -- analyzes the inserted node and all nodes that are generated by
662 -- this analysis. If the node is empty, the call has no effect. If the
663 -- Suppress argument is present, then the analysis is done with the
664 -- specified check suppressed (can be All_Checks to suppress all checks).
666 procedure Insert_Before_And_Analyze
667 (N
: Node_Id
; M
: Node_Id
);
668 procedure Insert_Before_And_Analyze
669 (N
: Node_Id
; M
: Node_Id
; Suppress
: Check_Id
);
670 -- Inserts node M before node N and then after the insertion is complete,
671 -- analyzes the inserted node and all nodes that could be generated by
672 -- this analysis. If the node is empty, the call has no effect. If the
673 -- Suppress argument is present, then the analysis is done with the
674 -- specified check suppressed (can be All_Checks to suppress all checks).
676 procedure Insert_Before_First_Source_Declaration
679 -- Insert node Stmt before the first source declaration of the related
680 -- subprogram's body. If no such declaration exists, Stmt becomes the last
683 function External_Ref_In_Generic
(E
: Entity_Id
) return Boolean;
684 -- Return True if we are in the context of a generic and E is
685 -- external (more global) to it.
687 procedure Enter_Generic_Scope
(S
: Entity_Id
);
688 -- Called each time a Generic subprogram or package scope is entered. S is
689 -- the entity of the scope.
691 -- ??? At the moment, only called for package specs because this mechanism
692 -- is only used for avoiding freezing of external references in generics
693 -- and this can only be an issue if the outer generic scope is a package
694 -- spec (otherwise all external entities are already frozen)
696 procedure Exit_Generic_Scope
(S
: Entity_Id
);
697 -- Called each time a Generic subprogram or package scope is exited. S is
698 -- the entity of the scope.
700 -- ??? At the moment, only called for package specs exit.
702 function Explicit_Suppress
(E
: Entity_Id
; C
: Check_Id
) return Boolean;
703 -- This function returns True if an explicit pragma Suppress for check C
704 -- is present in the package defining E.
706 function Preanalysis_Active
return Boolean;
707 pragma Inline
(Preanalysis_Active
);
708 -- Determine whether preanalysis is active at the point of invocation
710 procedure Preanalyze
(N
: Node_Id
);
711 -- Performs a preanalysis of node N. During preanalysis no expansion is
712 -- carried out for N or its children. See above for more info on
716 with procedure Action
(Item
: Node_Id
);
717 procedure Walk_Library_Items
;
718 -- Primarily for use by CodePeer and GNATprove. Must be called after
719 -- semantic analysis (and expansion in the case of CodePeer) are complete.
720 -- Walks each relevant library item, calling Action for each, in an order
721 -- such that one will not run across forward references. Each Item passed
722 -- to Action is the declaration or body of a library unit, including
723 -- generics and renamings. The first item is the N_Package_Declaration node
724 -- for package Standard. Bodies are not included, except for the main unit
725 -- itself, which always comes last.
727 -- Item is never a subunit
729 -- Item is never an instantiation. Instead, the instance declaration is
730 -- passed, and (if the instantiation is the main unit), the instance body.
732 ------------------------
733 -- Debugging Routines --
734 ------------------------
736 function ss
(Index
: Int
) return Scope_Stack_Entry
;
737 pragma Export
(Ada
, ss
);
738 -- "ss" = "scope stack"; returns the Index'th entry in the Scope_Stack
740 function sst
return Scope_Stack_Entry
;
741 pragma Export
(Ada
, sst
);
742 -- "sst" = "scope stack top"; same as ss(Scope_Stack.Last)