1 |
12 |
jlechner |
------------------------------------------------------------------------------
|
2 |
|
|
-- --
|
3 |
|
|
-- GNAT COMPILER COMPONENTS --
|
4 |
|
|
-- --
|
5 |
|
|
-- S E M --
|
6 |
|
|
-- --
|
7 |
|
|
-- S p e c --
|
8 |
|
|
-- --
|
9 |
|
|
-- Copyright (C) 1992-2005, 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 2, 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 COPYING. If not, write --
|
19 |
|
|
-- to the Free Software Foundation, 51 Franklin Street, Fifth Floor, --
|
20 |
|
|
-- Boston, MA 02110-1301, USA. --
|
21 |
|
|
-- --
|
22 |
|
|
-- GNAT was originally developed by the GNAT team at New York University. --
|
23 |
|
|
-- Extensive contributions were provided by Ada Core Technologies Inc. --
|
24 |
|
|
-- --
|
25 |
|
|
------------------------------------------------------------------------------
|
26 |
|
|
|
27 |
|
|
--------------------------------------
|
28 |
|
|
-- Semantic Analysis: General Model --
|
29 |
|
|
--------------------------------------
|
30 |
|
|
|
31 |
|
|
-- Semantic processing involves 3 phases which are highly interwined
|
32 |
|
|
-- (ie mutually recursive):
|
33 |
|
|
|
34 |
|
|
-- Analysis implements the bulk of semantic analysis such as
|
35 |
|
|
-- name analysis and type resolution for declarations,
|
36 |
|
|
-- instructions and expressions. The main routine
|
37 |
|
|
-- driving this process is procedure Analyze given below.
|
38 |
|
|
-- This analysis phase is really a bottom up pass that is
|
39 |
|
|
-- achieved during the recursive traversal performed by the
|
40 |
|
|
-- Analyze_... procedures implemented in the sem_* packages.
|
41 |
|
|
-- For expressions this phase determines unambiguous types
|
42 |
|
|
-- and collects sets of possible types where the
|
43 |
|
|
-- interpretation is potentially ambiguous.
|
44 |
|
|
|
45 |
|
|
-- Resolution is carried out only for expressions to finish type
|
46 |
|
|
-- resolution that was initiated but not necessarily
|
47 |
|
|
-- completed during analysis (because of overloading
|
48 |
|
|
-- ambiguities). Specifically, after completing the bottom
|
49 |
|
|
-- up pass carried out during analysis for expressions, the
|
50 |
|
|
-- Resolve routine (see the spec of sem_res for more info)
|
51 |
|
|
-- is called to perform a top down resolution with
|
52 |
|
|
-- recursive calls to itself to resolve operands.
|
53 |
|
|
|
54 |
|
|
-- Expansion if we are not generating code this phase is a no-op.
|
55 |
|
|
-- otherwise this phase expands, ie transforms, original
|
56 |
|
|
-- declaration, expressions or instructions into simpler
|
57 |
|
|
-- structures that can be handled by the back-end. This
|
58 |
|
|
-- phase is also in charge of generating code which is
|
59 |
|
|
-- implicit in the original source (for instance for
|
60 |
|
|
-- default initializations, controlled types, etc.)
|
61 |
|
|
-- There are two separate instances where expansion is
|
62 |
|
|
-- invoked. For declarations and instructions, expansion is
|
63 |
|
|
-- invoked just after analysis since no resolution needs
|
64 |
|
|
-- to be performed. For expressions, expansion is done just
|
65 |
|
|
-- after resolution. In both cases expansion is done from the
|
66 |
|
|
-- bottom up just before the end of Analyze for instructions
|
67 |
|
|
-- and declarations or the call to Resolve for expressions.
|
68 |
|
|
-- The main routine driving expansion is Expand.
|
69 |
|
|
-- See the spec of Expander for more details.
|
70 |
|
|
|
71 |
|
|
-- To summarize, in normal code generation mode we recursively traverse the
|
72 |
|
|
-- abstract syntax tree top-down performing semantic analysis bottom
|
73 |
|
|
-- up. For instructions and declarations, before the call to the Analyze
|
74 |
|
|
-- routine completes we perform expansion since at that point we have all
|
75 |
|
|
-- semantic information needed. For expression nodes, after the call to
|
76 |
|
|
-- Analysis terminates we invoke the Resolve routine to transmit top-down
|
77 |
|
|
-- the type that was gathered by Analyze which will resolve possible
|
78 |
|
|
-- ambiguities in the expression. Just before the call to Resolve
|
79 |
|
|
-- terminates, the expression can be expanded since all the semantic
|
80 |
|
|
-- information is available at that point.
|
81 |
|
|
|
82 |
|
|
-- If we are not generating code then the expansion phase is a no-op
|
83 |
|
|
|
84 |
|
|
-- When generating code there are a number of exceptions to the basic
|
85 |
|
|
-- Analysis-Resolution-Expansion model for expressions. The most prominent
|
86 |
|
|
-- examples are the handling of default expressions and aggregates.
|
87 |
|
|
|
88 |
|
|
----------------------------------------------------
|
89 |
|
|
-- Handling of Default and Per-Object Expressions --
|
90 |
|
|
----------------------------------------------------
|
91 |
|
|
|
92 |
|
|
-- The default expressions in component declarations and in procedure
|
93 |
|
|
-- specifications (but not the ones in object declarations) are quite
|
94 |
|
|
-- tricky to handle. The problem is that some processing is required
|
95 |
|
|
-- at the point where the expression appears:
|
96 |
|
|
|
97 |
|
|
-- visibility analysis (including user defined operators)
|
98 |
|
|
-- freezing of static expressions
|
99 |
|
|
|
100 |
|
|
-- but other processing must be deferred until the enclosing entity
|
101 |
|
|
-- (record or procedure specification) is frozen:
|
102 |
|
|
|
103 |
|
|
-- freezing of any other types in the expression
|
104 |
|
|
-- expansion
|
105 |
|
|
|
106 |
|
|
-- A similar situation occurs with the argument of priority and interrupt
|
107 |
|
|
-- priority pragmas that appear in task and protected definition specs and
|
108 |
|
|
-- other cases of per-object expressions (see RM 3.8(18)).
|
109 |
|
|
|
110 |
|
|
-- Expansion has to be deferred since you can't generate code for
|
111 |
|
|
-- expressions that refernce types that have not been frozen yet. As an
|
112 |
|
|
-- example, consider the following:
|
113 |
|
|
|
114 |
|
|
-- type x is delta 0.5 range -10.0 .. +10.0;
|
115 |
|
|
-- ...
|
116 |
|
|
-- type q is record
|
117 |
|
|
-- xx : x := y * z;
|
118 |
|
|
-- end record;
|
119 |
|
|
|
120 |
|
|
-- for x'small use 0.25
|
121 |
|
|
|
122 |
|
|
-- The expander is in charge of dealing with fixed-point, and of course
|
123 |
|
|
-- the small declaration, which is not too late, since the declaration of
|
124 |
|
|
-- type q does *not* freeze type x, definitely affects the expanded code.
|
125 |
|
|
|
126 |
|
|
-- Another reason that we cannot expand early is that expansion can generate
|
127 |
|
|
-- range checks. These range checks need to be inserted not at the point of
|
128 |
|
|
-- definition but at the point of use. The whole point here is that the value
|
129 |
|
|
-- of the expression cannot be obtained at the point of declaration, only at
|
130 |
|
|
-- the point of use.
|
131 |
|
|
|
132 |
|
|
-- Generally our model is to combine analysis resolution and expansion, but
|
133 |
|
|
-- this is the one case where this model falls down. Here is how we patch
|
134 |
|
|
-- it up without causing too much distortion to our basic model.
|
135 |
|
|
|
136 |
|
|
-- A switch (sede below) is set to indicate that we are in the initial
|
137 |
|
|
-- occurence of a default expression. The analyzer is then called on this
|
138 |
|
|
-- expression with the switch set true. Analysis and resolution proceed
|
139 |
|
|
-- almost as usual, except that Freeze_Expression will not freeze
|
140 |
|
|
-- non-static expressions if this switch is set, and the call to Expand at
|
141 |
|
|
-- the end of resolution is skipped. This also skips the code that normally
|
142 |
|
|
-- sets the Analyzed flag to True). The result is that when we are done the
|
143 |
|
|
-- tree is still marked as unanalyzed, but all types for static expressions
|
144 |
|
|
-- are frozen as required, and all entities of variables have been
|
145 |
|
|
-- recorded. We then turn off the switch, and later on reanalyze the
|
146 |
|
|
-- expression with the switch off. The effect is that this second analysis
|
147 |
|
|
-- freezes the rest of the types as required, and generates code but
|
148 |
|
|
-- visibility analysis is not repeated since all the entities are marked.
|
149 |
|
|
|
150 |
|
|
-- The second analysis (the one that generates code) is in the context
|
151 |
|
|
-- where the code is required. For a record field default, this is in
|
152 |
|
|
-- the initialization procedure for the record and for a subprogram
|
153 |
|
|
-- default parameter, it is at the point the subprogram is frozen.
|
154 |
|
|
-- For a priority or storage size pragma it is in the context of the
|
155 |
|
|
-- Init_Proc for the task or protected object.
|
156 |
|
|
|
157 |
|
|
------------------
|
158 |
|
|
-- Pre-Analysis --
|
159 |
|
|
------------------
|
160 |
|
|
|
161 |
|
|
-- For certain kind of expressions, such as aggregates, we need to defer
|
162 |
|
|
-- expansion of the aggregate and its inner expressions after the whole
|
163 |
|
|
-- set of expressions appearing inside the aggregate have been analyzed.
|
164 |
|
|
-- Consider, for instance the following example:
|
165 |
|
|
--
|
166 |
|
|
-- (1 .. 100 => new Thing (Function_Call))
|
167 |
|
|
--
|
168 |
|
|
-- The normal Analysis-Resolution-Expansion mechanism where expansion
|
169 |
|
|
-- of the children is performed before expansion of the parent does not
|
170 |
|
|
-- work if the code generated for the children by the expander needs
|
171 |
|
|
-- to be evaluated repeatdly (for instance in the above aggregate
|
172 |
|
|
-- "new Thing (Function_Call)" needs to be called 100 times.)
|
173 |
|
|
-- The reason why this mecanism does not work is that, the expanded code
|
174 |
|
|
-- for the children is typically inserted above the parent and thus
|
175 |
|
|
-- when the father gets expanded no re-evaluation takes place. For instance
|
176 |
|
|
-- in the case of aggregates if "new Thing (Function_Call)" is expanded
|
177 |
|
|
-- before of the aggregate the expanded code will be placed outside
|
178 |
|
|
-- of the aggregate and when expanding the aggregate the loop from 1 to 100
|
179 |
|
|
-- will not surround the expanded code for "new Thing (Function_Call)".
|
180 |
|
|
--
|
181 |
|
|
-- To remedy this situation we introduce a new flag which signals whether
|
182 |
|
|
-- we want a full analysis (ie expansion is enabled) or a pre-analysis
|
183 |
|
|
-- which performs Analysis and Resolution but no expansion.
|
184 |
|
|
--
|
185 |
|
|
-- After the complete pre-analysis of an expression has been carried out
|
186 |
|
|
-- we can transform the expression and then carry out the full
|
187 |
|
|
-- Analyze-Resolve-Expand cycle on the transformed expression top-down
|
188 |
|
|
-- so that the expansion of inner expressions happens inside the newly
|
189 |
|
|
-- generated node for the parent expression.
|
190 |
|
|
--
|
191 |
|
|
-- Note that the difference between processing of default expressions and
|
192 |
|
|
-- pre-analysis of other expressions is that we do carry out freezing in
|
193 |
|
|
-- the latter but not in the former (except for static scalar expressions).
|
194 |
|
|
-- The routine that performs pre-analysis is called Pre_Analyze_And_Resolve
|
195 |
|
|
-- and is in Sem_Res.
|
196 |
|
|
|
197 |
|
|
with Alloc;
|
198 |
|
|
with Einfo; use Einfo;
|
199 |
|
|
with Opt; use Opt;
|
200 |
|
|
with Table;
|
201 |
|
|
with Types; use Types;
|
202 |
|
|
|
203 |
|
|
package Sem is
|
204 |
|
|
|
205 |
|
|
New_Nodes_OK : Int := 1;
|
206 |
|
|
-- Temporary flag for use in checking out HLO. Set non-zero if it is
|
207 |
|
|
-- OK to generate new nodes.
|
208 |
|
|
|
209 |
|
|
-----------------------------
|
210 |
|
|
-- Semantic Analysis Flags --
|
211 |
|
|
-----------------------------
|
212 |
|
|
|
213 |
|
|
Explicit_Overriding : Boolean := False;
|
214 |
|
|
-- Switch to indicate whether checking mechanism described in AI-218
|
215 |
|
|
-- is enforced: subprograms that override inherited operations must be
|
216 |
|
|
-- be marked explicitly, to prevent accidental or omitted overriding.
|
217 |
|
|
|
218 |
|
|
Full_Analysis : Boolean := True;
|
219 |
|
|
-- Switch to indicate whether we are doing a full analysis or a
|
220 |
|
|
-- pre-analysis. In normal analysis mode (Analysis-Expansion for
|
221 |
|
|
-- instructions or declarations) or (Analysis-Resolution-Expansion for
|
222 |
|
|
-- expressions) this flag is set. Note that if we are not generating
|
223 |
|
|
-- code the expansion phase merely sets the Analyzed flag to True in
|
224 |
|
|
-- this case. If we are in Pre-Analysis mode (see above) this flag is
|
225 |
|
|
-- set to False then the expansion phase is skipped.
|
226 |
|
|
-- When this flag is False the flag Expander_Active is also False
|
227 |
|
|
-- (the Expander_Activer flag defined in the spec of package Expander
|
228 |
|
|
-- tells you whether expansion is currently enabled).
|
229 |
|
|
-- You should really regard this as a read only flag.
|
230 |
|
|
|
231 |
|
|
In_Default_Expression : Boolean := False;
|
232 |
|
|
-- Switch to indicate that we are in a default expression, as described
|
233 |
|
|
-- above. Note that this must be recursively saved on a Semantics call
|
234 |
|
|
-- since it is possible for the analysis of an expression to result in
|
235 |
|
|
-- a recursive call (e.g. to get the entity for System.Address as part
|
236 |
|
|
-- of the processing of an Address attribute reference).
|
237 |
|
|
-- When this switch is True then Full_Analysis above must be False.
|
238 |
|
|
-- You should really regard this as a read only flag.
|
239 |
|
|
|
240 |
|
|
In_Deleted_Code : Boolean := False;
|
241 |
|
|
-- If the condition in an if-statement is statically known, the branch
|
242 |
|
|
-- that is not taken is analyzed with expansion disabled, and the tree
|
243 |
|
|
-- is deleted after analysis. Itypes generated in deleted code must be
|
244 |
|
|
-- frozen from start, because the tree on which they depend will not
|
245 |
|
|
-- be available at the freeze point.
|
246 |
|
|
|
247 |
|
|
In_Inlined_Body : Boolean := False;
|
248 |
|
|
-- Switch to indicate that we are analyzing and resolving an inlined
|
249 |
|
|
-- body. Type checking is disabled in this context, because types are
|
250 |
|
|
-- known to be compatible. This avoids problems with private types whose
|
251 |
|
|
-- full view is derived from private types.
|
252 |
|
|
|
253 |
|
|
Inside_A_Generic : Boolean := False;
|
254 |
|
|
-- This flag is set if we are processing a generic specification,
|
255 |
|
|
-- generic definition, or generic body. When this flag is True the
|
256 |
|
|
-- Expander_Active flag is False to disable any code expansion (see
|
257 |
|
|
-- package Expander). Only the generic processing can modify the
|
258 |
|
|
-- status of this flag, any other client should regard it as read-only.
|
259 |
|
|
|
260 |
|
|
Unloaded_Subunits : Boolean := False;
|
261 |
|
|
-- This flag is set True if we have subunits that are not loaded. This
|
262 |
|
|
-- occurs when the main unit is a subunit, and contains lower level
|
263 |
|
|
-- subunits that are not loaded. We use this flag to suppress warnings
|
264 |
|
|
-- about unused variables, since these warnings are unreliable in this
|
265 |
|
|
-- case. We could perhaps do a more accurate job and retain some of the
|
266 |
|
|
-- warnings, but it is quite a tricky job. See test 4323-002.
|
267 |
|
|
|
268 |
|
|
-----------------
|
269 |
|
|
-- Scope Stack --
|
270 |
|
|
-----------------
|
271 |
|
|
|
272 |
|
|
-- The scope stack holds all entries of the scope table. As in the parser,
|
273 |
|
|
-- we use Last as the stack pointer, so that we can always find the scope
|
274 |
|
|
-- that is currently open in Scope_Stack.Table (Scope_Stack.Last). The
|
275 |
|
|
-- oldest entry, at Scope_Stack (0) is Standard. The entries in the table
|
276 |
|
|
-- include the entity for the referenced scope, together with information
|
277 |
|
|
-- used to restore the proper setting of check suppressions on scope exit.
|
278 |
|
|
|
279 |
|
|
type Scope_Stack_Entry is record
|
280 |
|
|
Entity : Entity_Id;
|
281 |
|
|
-- Entity representing the scope
|
282 |
|
|
|
283 |
|
|
Last_Subprogram_Name : String_Ptr;
|
284 |
|
|
-- Pointer to name of last subprogram body in this scope. Used for
|
285 |
|
|
-- testing proper alpha ordering of subprogram bodies in scope.
|
286 |
|
|
|
287 |
|
|
Save_Scope_Suppress : Suppress_Array;
|
288 |
|
|
-- Save contents of Scope_Suppress on entry
|
289 |
|
|
|
290 |
|
|
Save_Local_Entity_Suppress : Int;
|
291 |
|
|
-- Save contents of Local_Entity_Suppress.Last on entry
|
292 |
|
|
|
293 |
|
|
Is_Transient : Boolean;
|
294 |
|
|
-- Marks Transient Scopes (See Exp_Ch7 body for details)
|
295 |
|
|
|
296 |
|
|
Previous_Visibility : Boolean;
|
297 |
|
|
-- Used when installing the parent (s) of the current compilation
|
298 |
|
|
-- unit. The parent may already be visible because of an ongoing
|
299 |
|
|
-- compilation, and the proper visibility must be restored on exit.
|
300 |
|
|
|
301 |
|
|
Node_To_Be_Wrapped : Node_Id;
|
302 |
|
|
-- Only used in transient scopes. Records the node which will
|
303 |
|
|
-- be wrapped by the transient block.
|
304 |
|
|
|
305 |
|
|
Actions_To_Be_Wrapped_Before : List_Id;
|
306 |
|
|
Actions_To_Be_Wrapped_After : List_Id;
|
307 |
|
|
-- Actions that have to be inserted at the start or at the end of a
|
308 |
|
|
-- transient block. Used to temporarily hold these actions until the
|
309 |
|
|
-- block is created, at which time the actions are moved to the
|
310 |
|
|
-- block.
|
311 |
|
|
|
312 |
|
|
Pending_Freeze_Actions : List_Id;
|
313 |
|
|
-- Used to collect freeze entity nodes and associated actions that
|
314 |
|
|
-- are generated in a inner context but need to be analyzed outside,
|
315 |
|
|
-- such as records and initialization procedures. On exit from the
|
316 |
|
|
-- scope, this list of actions is inserted before the scope construct
|
317 |
|
|
-- and analyzed to generate the corresponding freeze processing and
|
318 |
|
|
-- elaboration of other associated actions.
|
319 |
|
|
|
320 |
|
|
First_Use_Clause : Node_Id;
|
321 |
|
|
-- Head of list of Use_Clauses in current scope. The list is built
|
322 |
|
|
-- when the declarations in the scope are processed. The list is
|
323 |
|
|
-- traversed on scope exit to undo the effect of the use clauses.
|
324 |
|
|
|
325 |
|
|
Component_Alignment_Default : Component_Alignment_Kind;
|
326 |
|
|
-- Component alignment to be applied to any record or array types
|
327 |
|
|
-- that are declared for which a specific component alignment pragma
|
328 |
|
|
-- does not set the alignment.
|
329 |
|
|
|
330 |
|
|
Is_Active_Stack_Base : Boolean;
|
331 |
|
|
-- Set to true only when entering the scope for Standard_Standard from
|
332 |
|
|
-- from within procedure Semantics. Indicates the base of the current
|
333 |
|
|
-- active set of scopes. Needed by In_Open_Scopes to handle cases
|
334 |
|
|
-- where Standard_Standard can be pushed in the middle of the active
|
335 |
|
|
-- set of scopes (occurs for instantiations of generic child units).
|
336 |
|
|
end record;
|
337 |
|
|
|
338 |
|
|
package Scope_Stack is new Table.Table (
|
339 |
|
|
Table_Component_Type => Scope_Stack_Entry,
|
340 |
|
|
Table_Index_Type => Int,
|
341 |
|
|
Table_Low_Bound => 0,
|
342 |
|
|
Table_Initial => Alloc.Scope_Stack_Initial,
|
343 |
|
|
Table_Increment => Alloc.Scope_Stack_Increment,
|
344 |
|
|
Table_Name => "Sem.Scope_Stack");
|
345 |
|
|
|
346 |
|
|
-----------------------------------
|
347 |
|
|
-- Handling of Check Suppression --
|
348 |
|
|
-----------------------------------
|
349 |
|
|
|
350 |
|
|
-- There are two kinds of suppress checks: scope based suppress checks,
|
351 |
|
|
-- and entity based suppress checks.
|
352 |
|
|
|
353 |
|
|
-- Scope based suppress chems (from initial command line arguments,
|
354 |
|
|
-- or from Suppress pragmas not including an entity name) are recorded
|
355 |
|
|
-- in the Sem.Supress variable, and all that is necessary is to save the
|
356 |
|
|
-- state of this variable on scope entry, and restore it on scope exit.
|
357 |
|
|
|
358 |
|
|
-- Entity based suppress checks, from Suppress pragmas giving an Entity_Id,
|
359 |
|
|
-- are handled as follows. If a suppress or unsuppress pragma is
|
360 |
|
|
-- encountered for a given entity, then the flag Checks_May_Be_Suppressed
|
361 |
|
|
-- is set in the entity and an entry is made in either the
|
362 |
|
|
-- Local_Entity_Suppress table (case of pragma that appears in other than
|
363 |
|
|
-- a package spec), or in the Global_Entity_Suppress table (case of pragma
|
364 |
|
|
-- that appears in a package spec, which is by the rule of RM 11.5(7)
|
365 |
|
|
-- applicable throughout the life of the entity).
|
366 |
|
|
|
367 |
|
|
-- If the Checks_May_Be_Suppressed flag is set in an entity then the
|
368 |
|
|
-- procedure is to search first the local and then the global suppress
|
369 |
|
|
-- tables (the local one being searched in reverse order, i.e. last in
|
370 |
|
|
-- searched first). The only other point is that we have to make sure
|
371 |
|
|
-- that we have proper nested interaction between such specific pragmas
|
372 |
|
|
-- and locally applied general pragmas applying to all entities. This
|
373 |
|
|
-- is achieved by including in the Local_Entity_Suppress table dummy
|
374 |
|
|
-- entries with an empty Entity field that are applicable to all entities.
|
375 |
|
|
|
376 |
|
|
Scope_Suppress : Suppress_Array := Suppress_Options;
|
377 |
|
|
-- This array contains the current scope based settings of the suppress
|
378 |
|
|
-- switches. It is initialized from the options as shown, and then modified
|
379 |
|
|
-- by pragma Suppress. On entry to each scope, the current setting is saved
|
380 |
|
|
-- the scope stack, and then restored on exit from the scope. This record
|
381 |
|
|
-- may be rapidly checked to determine the current status of a check if
|
382 |
|
|
-- no specific entity is involved or if the specific entity involved is
|
383 |
|
|
-- one for which no specific Suppress/Unsuppress pragma has been set (as
|
384 |
|
|
-- indicated by the Checks_May_Be_Suppressed flag being set).
|
385 |
|
|
|
386 |
|
|
-- This scheme is a little complex, but serves the purpose of enabling
|
387 |
|
|
-- a very rapid check in the common case where no entity specific pragma
|
388 |
|
|
-- applies, and gives the right result when such pragmas are used even
|
389 |
|
|
-- in complex cases of nested Suppress and Unsuppress pragmas.
|
390 |
|
|
|
391 |
|
|
type Entity_Check_Suppress_Record is record
|
392 |
|
|
Entity : Entity_Id;
|
393 |
|
|
-- Entity to which the check applies, or Empty for a local check
|
394 |
|
|
-- that has no entity name (and thus applies to all entities).
|
395 |
|
|
|
396 |
|
|
Check : Check_Id;
|
397 |
|
|
-- Check which is set (note this cannot be All_Checks, if the All_Checks
|
398 |
|
|
-- case, a sequence of eentries appears for the individual checks.
|
399 |
|
|
|
400 |
|
|
Suppress : Boolean;
|
401 |
|
|
-- Set True for Suppress, and False for Unsuppress
|
402 |
|
|
end record;
|
403 |
|
|
|
404 |
|
|
-- The Local_Entity_Suppress table is a stack, to which new entries are
|
405 |
|
|
-- added for Suppress and Unsuppress pragmas appearing in other than
|
406 |
|
|
-- package specs. Such pragmas are effective only to the end of the scope
|
407 |
|
|
-- in which they appear. This is achieved by marking the stack on entry
|
408 |
|
|
-- to a scope and then cutting back the stack to that marked point on
|
409 |
|
|
-- scope exit.
|
410 |
|
|
|
411 |
|
|
package Local_Entity_Suppress is new Table.Table (
|
412 |
|
|
Table_Component_Type => Entity_Check_Suppress_Record,
|
413 |
|
|
Table_Index_Type => Int,
|
414 |
|
|
Table_Low_Bound => 0,
|
415 |
|
|
Table_Initial => Alloc.Entity_Suppress_Initial,
|
416 |
|
|
Table_Increment => Alloc.Entity_Suppress_Increment,
|
417 |
|
|
Table_Name => "Local_Entity_Suppress");
|
418 |
|
|
|
419 |
|
|
-- The Global_Entity_Suppress table is used for entities which have
|
420 |
|
|
-- a Suppress or Unsuppress pragma naming a specific entity in a
|
421 |
|
|
-- package spec. Such pragmas always refer to entities in the package
|
422 |
|
|
-- spec and are effective throughout the lifetime of the named entity.
|
423 |
|
|
|
424 |
|
|
package Global_Entity_Suppress is new Table.Table (
|
425 |
|
|
Table_Component_Type => Entity_Check_Suppress_Record,
|
426 |
|
|
Table_Index_Type => Int,
|
427 |
|
|
Table_Low_Bound => 0,
|
428 |
|
|
Table_Initial => Alloc.Entity_Suppress_Initial,
|
429 |
|
|
Table_Increment => Alloc.Entity_Suppress_Increment,
|
430 |
|
|
Table_Name => "Global_Entity_Suppress");
|
431 |
|
|
|
432 |
|
|
-----------------
|
433 |
|
|
-- Subprograms --
|
434 |
|
|
-----------------
|
435 |
|
|
|
436 |
|
|
procedure Initialize;
|
437 |
|
|
-- Initialize internal tables
|
438 |
|
|
|
439 |
|
|
procedure Lock;
|
440 |
|
|
-- Lock internal tables before calling back end
|
441 |
|
|
|
442 |
|
|
procedure Semantics (Comp_Unit : Node_Id);
|
443 |
|
|
-- This procedure is called to perform semantic analysis on the specified
|
444 |
|
|
-- node which is the N_Compilation_Unit node for the unit.
|
445 |
|
|
|
446 |
|
|
procedure Analyze (N : Node_Id);
|
447 |
|
|
procedure Analyze (N : Node_Id; Suppress : Check_Id);
|
448 |
|
|
-- This is the recursive procedure which is applied to individual nodes
|
449 |
|
|
-- of the tree, starting at the top level node (compilation unit node)
|
450 |
|
|
-- and then moving down the tree in a top down traversal. It calls
|
451 |
|
|
-- individual routines with names Analyze_xxx to analyze node xxx. Each
|
452 |
|
|
-- of these routines is responsible for calling Analyze on the components
|
453 |
|
|
-- of the subtree.
|
454 |
|
|
--
|
455 |
|
|
-- Note: In the case of expression components (nodes whose Nkind is in
|
456 |
|
|
-- N_Subexpr), the call to Analyze does not complete the semantic analysis
|
457 |
|
|
-- of the node, since the type resolution cannot be completed until the
|
458 |
|
|
-- complete context is analyzed. The completion of the type analysis occurs
|
459 |
|
|
-- in the corresponding Resolve routine (see Sem_Res).
|
460 |
|
|
--
|
461 |
|
|
-- Note: for integer and real literals, the analyzer sets the flag to
|
462 |
|
|
-- indicate that the result is a static expression. If the expander
|
463 |
|
|
-- generates a literal that does NOT correspond to a static expression,
|
464 |
|
|
-- e.g. by folding an expression whose value is known at compile-time,
|
465 |
|
|
-- but is not technically static, then the caller should reset the
|
466 |
|
|
-- Is_Static_Expression flag after analyzing but before resolving.
|
467 |
|
|
--
|
468 |
|
|
-- If the Suppress argument is present, then the analysis is done
|
469 |
|
|
-- with the specified check suppressed (can be All_Checks to suppress
|
470 |
|
|
-- all checks).
|
471 |
|
|
|
472 |
|
|
procedure Analyze_List (L : List_Id);
|
473 |
|
|
procedure Analyze_List (L : List_Id; Suppress : Check_Id);
|
474 |
|
|
-- Analyzes each element of a list. If the Suppress argument is present,
|
475 |
|
|
-- then the analysis is done with the specified check suppressed (can
|
476 |
|
|
-- be All_Checks to suppress all checks).
|
477 |
|
|
|
478 |
|
|
procedure Copy_Suppress_Status
|
479 |
|
|
(C : Check_Id;
|
480 |
|
|
From : Entity_Id;
|
481 |
|
|
To : Entity_Id);
|
482 |
|
|
-- If From is an entity for which check C is explicitly suppressed
|
483 |
|
|
-- then also explicitly suppress the corresponding check in To.
|
484 |
|
|
|
485 |
|
|
procedure Insert_List_After_And_Analyze
|
486 |
|
|
(N : Node_Id; L : List_Id);
|
487 |
|
|
procedure Insert_List_After_And_Analyze
|
488 |
|
|
(N : Node_Id; L : List_Id; Suppress : Check_Id);
|
489 |
|
|
-- Inserts list L after node N using Nlists.Insert_List_After, and then,
|
490 |
|
|
-- after this insertion is complete, analyzes all the nodes in the list,
|
491 |
|
|
-- including any additional nodes generated by this analysis. If the list
|
492 |
|
|
-- is empty or be No_List, the call has no effect. If the Suppress
|
493 |
|
|
-- argument is present, then the analysis is done with the specified
|
494 |
|
|
-- check suppressed (can be All_Checks to suppress all checks).
|
495 |
|
|
|
496 |
|
|
procedure Insert_List_Before_And_Analyze
|
497 |
|
|
(N : Node_Id; L : List_Id);
|
498 |
|
|
procedure Insert_List_Before_And_Analyze
|
499 |
|
|
(N : Node_Id; L : List_Id; Suppress : Check_Id);
|
500 |
|
|
-- Inserts list L before node N using Nlists.Insert_List_Before, and then,
|
501 |
|
|
-- after this insertion is complete, analyzes all the nodes in the list,
|
502 |
|
|
-- including any additional nodes generated by this analysis. If the list
|
503 |
|
|
-- is empty or be No_List, the call has no effect. If the Suppress
|
504 |
|
|
-- argument is present, then the analysis is done with the specified
|
505 |
|
|
-- check suppressed (can be All_Checks to suppress all checks).
|
506 |
|
|
|
507 |
|
|
procedure Insert_After_And_Analyze
|
508 |
|
|
(N : Node_Id; M : Node_Id);
|
509 |
|
|
procedure Insert_After_And_Analyze
|
510 |
|
|
(N : Node_Id; M : Node_Id; Suppress : Check_Id);
|
511 |
|
|
-- Inserts node M after node N and then after the insertion is complete,
|
512 |
|
|
-- analyzes the inserted node and all nodes that are generated by
|
513 |
|
|
-- this analysis. If the node is empty, the call has no effect. If the
|
514 |
|
|
-- Suppress argument is present, then the analysis is done with the
|
515 |
|
|
-- specified check suppressed (can be All_Checks to suppress all checks).
|
516 |
|
|
|
517 |
|
|
procedure Insert_Before_And_Analyze
|
518 |
|
|
(N : Node_Id; M : Node_Id);
|
519 |
|
|
procedure Insert_Before_And_Analyze
|
520 |
|
|
(N : Node_Id; M : Node_Id; Suppress : Check_Id);
|
521 |
|
|
-- Inserts node M before node N and then after the insertion is complete,
|
522 |
|
|
-- analyzes the inserted node and all nodes that could be generated by
|
523 |
|
|
-- this analysis. If the node is empty, the call has no effect. If the
|
524 |
|
|
-- Suppress argument is present, then the analysis is done with the
|
525 |
|
|
-- specified check suppressed (can be All_Checks to suppress all checks).
|
526 |
|
|
|
527 |
|
|
function External_Ref_In_Generic (E : Entity_Id) return Boolean;
|
528 |
|
|
-- Return True if we are in the context of a generic and E is
|
529 |
|
|
-- external (more global) to it.
|
530 |
|
|
|
531 |
|
|
procedure Enter_Generic_Scope (S : Entity_Id);
|
532 |
|
|
-- Shall be called each time a Generic subprogram or package scope is
|
533 |
|
|
-- entered. S is the entity of the scope.
|
534 |
|
|
-- ??? At the moment, only called for package specs because this mechanism
|
535 |
|
|
-- is only used for avoiding freezing of external references in generics
|
536 |
|
|
-- and this can only be an issue if the outer generic scope is a package
|
537 |
|
|
-- spec (otherwise all external entities are already frozen)
|
538 |
|
|
|
539 |
|
|
procedure Exit_Generic_Scope (S : Entity_Id);
|
540 |
|
|
-- Shall be called each time a Generic subprogram or package scope is
|
541 |
|
|
-- exited. S is the entity of the scope.
|
542 |
|
|
-- ??? At the moment, only called for package specs exit.
|
543 |
|
|
|
544 |
|
|
function Explicit_Suppress (E : Entity_Id; C : Check_Id) return Boolean;
|
545 |
|
|
-- This function returns True if an explicit pragma Suppress for check C
|
546 |
|
|
-- is present in the package defining E.
|
547 |
|
|
|
548 |
|
|
function Is_Check_Suppressed (E : Entity_Id; C : Check_Id) return Boolean;
|
549 |
|
|
-- This function is called if Checks_May_Be_Suppressed (E) is True to
|
550 |
|
|
-- determine whether check C is suppressed either on the entity E or
|
551 |
|
|
-- as the result of a scope suppress pragma. If Checks_May_Be_Suppressed
|
552 |
|
|
-- is False, then the status of the check can be determined simply by
|
553 |
|
|
-- examining Scope_Checks (C), so this routine is not called in that case.
|
554 |
|
|
|
555 |
|
|
end Sem;
|