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