Subversion Repositories openrisc

------------------------------------------------------------------------------

--                                                                          --

--                         GNAT COMPILER COMPONENTS                         --

--                                                                          --

--                             S E M _ C H 1 2                              --

--                                                                          --

--                                 B o d y                                  --

--                                                                          --

--          Copyright (C) 1992-2012, Free Software Foundation, Inc.         --

--                                                                          --

-- GNAT is free software;  you can  redistribute it  and/or modify it under --

-- terms of the  GNU General Public License as published  by the Free Soft- --

-- ware  Foundation;  either version 3,  or (at your option) any later ver- --

-- sion.  GNAT is distributed in the hope that it will be useful, but WITH- --

-- OUT ANY WARRANTY;  without even the  implied warranty of MERCHANTABILITY --

-- or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License --

-- for  more details.  You should have  received  a copy of the GNU General --

-- Public License  distributed with GNAT; see file COPYING3.  If not, go to --

-- http://www.gnu.org/licenses for a complete copy of the license.          --

--                                                                          --

-- GNAT was originally developed  by the GNAT team at  New York University. --

-- Extensive contributions were provided by Ada Core Technologies Inc.      --

--                                                                          --

------------------------------------------------------------------------------

with Aspects;  use Aspects;

with Atree;    use Atree;

with Einfo;    use Einfo;

with Elists;   use Elists;

with Errout;   use Errout;

with Expander; use Expander;

with Exp_Disp; use Exp_Disp;

with Fname;    use Fname;

with Fname.UF; use Fname.UF;

with Freeze;   use Freeze;

with Hostparm;

with Itypes;   use Itypes;

with Lib;      use Lib;

with Lib.Load; use Lib.Load;

with Lib.Xref; use Lib.Xref;

with Nlists;   use Nlists;

with Namet;    use Namet;

with Nmake;    use Nmake;

with Opt;      use Opt;

with Rident;   use Rident;

with Restrict; use Restrict;

with Rtsfind;  use Rtsfind;

with Sem;      use Sem;

with Sem_Aux;  use Sem_Aux;

with Sem_Cat;  use Sem_Cat;

with Sem_Ch3;  use Sem_Ch3;

with Sem_Ch6;  use Sem_Ch6;

with Sem_Ch7;  use Sem_Ch7;

with Sem_Ch8;  use Sem_Ch8;

with Sem_Ch10; use Sem_Ch10;

with Sem_Ch13; use Sem_Ch13;

with Sem_Dim;  use Sem_Dim;

with Sem_Disp; use Sem_Disp;

with Sem_Elab; use Sem_Elab;

with Sem_Elim; use Sem_Elim;

with Sem_Eval; use Sem_Eval;

with Sem_Prag; use Sem_Prag;

with Sem_Res;  use Sem_Res;

with Sem_Type; use Sem_Type;

with Sem_Util; use Sem_Util;

with Sem_Warn; use Sem_Warn;

with Stand;    use Stand;

with Sinfo;    use Sinfo;

with Sinfo.CN; use Sinfo.CN;

with Sinput;   use Sinput;

with Sinput.L; use Sinput.L;

with Snames;   use Snames;

with Stringt;  use Stringt;

with Uname;    use Uname;

with Table;

with Tbuild;   use Tbuild;

with Uintp;    use Uintp;

with Urealp;   use Urealp;

with GNAT.HTable;

package body Sem_Ch12 is

   ----------------------------------------------------------

   -- Implementation of Generic Analysis and Instantiation --

   ----------------------------------------------------------

   --  GNAT implements generics by macro expansion. No attempt is made to share

   --  generic instantiations (for now). Analysis of a generic definition does

   --  not perform any expansion action, but the expander must be called on the

   --  tree for each instantiation, because the expansion may of course depend

   --  on the generic actuals. All of this is best achieved as follows:

   --

   --  a) Semantic analysis of a generic unit is performed on a copy of the

   --  tree for the generic unit. All tree modifications that follow analysis

   --  do not affect the original tree. Links are kept between the original

   --  tree and the copy, in order to recognize non-local references within

   --  the generic, and propagate them to each instance (recall that name

   --  resolution is done on the generic declaration: generics are not really

   --  macros!). This is summarized in the following diagram:

   --              .-----------.               .----------.

   --              |  semantic |<--------------|  generic |

   --              |    copy   |               |    unit  |

   --              |           |==============>|          |

   --              |___________|    global     |__________|

   --                             references     |   |  |

   --                                            |   |  |

   --                                          .-----|--|.

   --                                          |  .-----|---.

   --                                          |  |  .----------.

   --                                          |  |  |  generic |

   --                                          |__|  |          |

   --                                             |__| instance |

   --                                                |__________|

   --  b) Each instantiation copies the original tree, and inserts into it a

   --  series of declarations that describe the mapping between generic formals

   --  and actuals. For example, a generic In OUT parameter is an object

   --  renaming of the corresponding actual, etc. Generic IN parameters are

   --  constant declarations.

   --  c) In order to give the right visibility for these renamings, we use

   --  a different scheme for package and subprogram instantiations. For

   --  packages, the list of renamings is inserted into the package

   --  specification, before the visible declarations of the package. The

   --  renamings are analyzed before any of the text of the instance, and are

   --  thus visible at the right place. Furthermore, outside of the instance,

   --  the generic parameters are visible and denote their corresponding

   --  actuals.

   --  For subprograms, we create a container package to hold the renamings

   --  and the subprogram instance itself. Analysis of the package makes the

   --  renaming declarations visible to the subprogram. After analyzing the

   --  package, the defining entity for the subprogram is touched-up so that

   --  it appears declared in the current scope, and not inside the container

   --  package.

   --  If the instantiation is a compilation unit, the container package is

   --  given the same name as the subprogram instance. This ensures that

   --  the elaboration procedure called by the binder, using the compilation

   --  unit name, calls in fact the elaboration procedure for the package.

   --  Not surprisingly, private types complicate this approach. By saving in

   --  the original generic object the non-local references, we guarantee that

   --  the proper entities are referenced at the point of instantiation.

   --  However, for private types, this by itself does not insure that the

   --  proper VIEW of the entity is used (the full type may be visible at the

   --  point of generic definition, but not at instantiation, or vice-versa).

   --  In  order to reference the proper view, we special-case any reference

   --  to private types in the generic object, by saving both views, one in

   --  the generic and one in the semantic copy. At time of instantiation, we

   --  check whether the two views are consistent, and exchange declarations if

   --  necessary, in order to restore the correct visibility. Similarly, if

   --  the instance view is private when the generic view was not, we perform

   --  the exchange. After completing the instantiation, we restore the

   --  current visibility. The flag Has_Private_View marks identifiers in the

   --  the generic unit that require checking.

   --  Visibility within nested generic units requires special handling.

   --  Consider the following scheme:

   --  type Global is ...         --  outside of generic unit.

   --  generic ...

   --  package Outer is

   --     ...

   --     type Semi_Global is ... --  global to inner.

   --     generic ...                                         -- 1

   --     procedure inner (X1 : Global;  X2 : Semi_Global);

   --     procedure in2 is new inner (...);                   -- 4

   --  end Outer;

   --  package New_Outer is new Outer (...);                  -- 2

   --  procedure New_Inner is new New_Outer.Inner (...);      -- 3

   --  The semantic analysis of Outer captures all occurrences of Global.

   --  The semantic analysis of Inner (at 1) captures both occurrences of

   --  Global and Semi_Global.

   --  At point 2 (instantiation of Outer), we also produce a generic copy

   --  of Inner, even though Inner is, at that point, not being instantiated.

   --  (This is just part of the semantic analysis of New_Outer).

   --  Critically, references to Global within Inner must be preserved, while

   --  references to Semi_Global should not preserved, because they must now

   --  resolve to an entity within New_Outer. To distinguish between these, we

   --  use a global variable, Current_Instantiated_Parent, which is set when

   --  performing a generic copy during instantiation (at 2). This variable is

   --  used when performing a generic copy that is not an instantiation, but

   --  that is nested within one, as the occurrence of 1 within 2. The analysis

   --  of a nested generic only preserves references that are global to the

   --  enclosing Current_Instantiated_Parent. We use the Scope_Depth value to

   --  determine whether a reference is external to the given parent.

   --  The instantiation at point 3 requires no special treatment. The method

   --  works as well for further nestings of generic units, but of course the

   --  variable Current_Instantiated_Parent must be stacked because nested

   --  instantiations can occur, e.g. the occurrence of 4 within 2.

   --  The instantiation of package and subprogram bodies is handled in a

   --  similar manner, except that it is delayed until after semantic

   --  analysis is complete. In this fashion complex cross-dependencies

   --  between several package declarations and bodies containing generics

   --  can be compiled which otherwise would diagnose spurious circularities.

   --  For example, it is possible to compile two packages A and B that

   --  have the following structure:

   --    package A is                         package B is

   --       generic ...                          generic ...

   --       package G_A is                       package G_B is

   --    with B;                              with A;

   --    package body A is                    package body B is

   --       package N_B is new G_B (..)          package N_A is new G_A (..)

   --  The table Pending_Instantiations in package Inline is used to keep

   --  track of body instantiations that are delayed in this manner. Inline

   --  handles the actual calls to do the body instantiations. This activity

   --  is part of Inline, since the processing occurs at the same point, and

   --  for essentially the same reason, as the handling of inlined routines.

   ----------------------------------------------

   -- Detection of Instantiation Circularities --

   ----------------------------------------------

   --  If we have a chain of instantiations that is circular, this is static

   --  error which must be detected at compile time. The detection of these

   --  circularities is carried out at the point that we insert a generic

   --  instance spec or body. If there is a circularity, then the analysis of

   --  the offending spec or body will eventually result in trying to load the

   --  same unit again, and we detect this problem as we analyze the package

   --  instantiation for the second time.

   --  At least in some cases after we have detected the circularity, we get

   --  into trouble if we try to keep going. The following flag is set if a

   --  circularity is detected, and used to abandon compilation after the

   --  messages have been posted.

   Circularity_Detected : Boolean := False;

   --  This should really be reset on encountering a new main unit, but in

   --  practice we are not using multiple main units so it is not critical.

   -------------------------------------------------

   -- Formal packages and partial parametrization --

   -------------------------------------------------

   --  When compiling a generic, a formal package is a local instantiation. If

   --  declared with a box, its generic formals are visible in the enclosing

   --  generic. If declared with a partial list of actuals, those actuals that

   --  are defaulted (covered by an Others clause, or given an explicit box

   --  initialization) are also visible in the enclosing generic, while those

   --  that have a corresponding actual are not.

   --  In our source model of instantiation, the same visibility must be

   --  present in the spec and body of an instance: the names of the formals

   --  that are defaulted must be made visible within the instance, and made

   --  invisible (hidden) after the instantiation is complete, so that they

   --  are not accessible outside of the instance.

   --  In a generic, a formal package is treated like a special instantiation.

   --  Our Ada 95 compiler handled formals with and without box in different

   --  ways. With partial parametrization, we use a single model for both.

   --  We create a package declaration that consists of the specification of

   --  the generic package, and a set of declarations that map the actuals

   --  into local renamings, just as we do for bona fide instantiations. For

   --  defaulted parameters and formals with a box, we copy directly the

   --  declarations of the formal into this local package. The result is a

   --  a package whose visible declarations may include generic formals. This

   --  package is only used for type checking and visibility analysis, and

   --  never reaches the back-end, so it can freely violate the placement

   --  rules for generic formal declarations.

   --  The list of declarations (renamings and copies of formals) is built

   --  by Analyze_Associations, just as for regular instantiations.

   --  At the point of instantiation, conformance checking must be applied only

   --  to those parameters that were specified in the formal. We perform this

   --  checking by creating another internal instantiation, this one including

   --  only the renamings and the formals (the rest of the package spec is not

   --  relevant to conformance checking). We can then traverse two lists: the

   --  list of actuals in the instance that corresponds to the formal package,

   --  and the list of actuals produced for this bogus instantiation. We apply

   --  the conformance rules to those actuals that are not defaulted (i.e.

   --  which still appear as generic formals.

   --  When we compile an instance body we must make the right parameters

   --  visible again. The predicate Is_Generic_Formal indicates which of the

   --  formals should have its Is_Hidden flag reset.

   -----------------------

   -- Local subprograms --

   -----------------------

   procedure Abandon_Instantiation (N : Node_Id);

   pragma No_Return (Abandon_Instantiation);

   --  Posts an error message "instantiation abandoned" at the indicated node

   --  and then raises the exception Instantiation_Error to do it.

   procedure Analyze_Formal_Array_Type

     (T   : in out Entity_Id;

      Def : Node_Id);

   --  A formal array type is treated like an array type declaration, and

   --  invokes Array_Type_Declaration (sem_ch3) whose first parameter is

   --  in-out, because in the case of an anonymous type the entity is

   --  actually created in the procedure.

   --  The following procedures treat other kinds of formal parameters

   procedure Analyze_Formal_Derived_Interface_Type

     (N   : Node_Id;

      T   : Entity_Id;

      Def : Node_Id);

   procedure Analyze_Formal_Derived_Type

     (N   : Node_Id;

      T   : Entity_Id;

      Def : Node_Id);

   procedure Analyze_Formal_Interface_Type

     (N   : Node_Id;

      T   : Entity_Id;

      Def : Node_Id);

   --  The following subprograms create abbreviated declarations for formal

   --  scalar types. We introduce an anonymous base of the proper class for

   --  each of them, and define the formals as constrained first subtypes of

   --  their bases. The bounds are expressions that are non-static in the

   --  generic.

   procedure Analyze_Formal_Decimal_Fixed_Point_Type

                                                (T : Entity_Id; Def : Node_Id);

   procedure Analyze_Formal_Discrete_Type       (T : Entity_Id; Def : Node_Id);

   procedure Analyze_Formal_Floating_Type       (T : Entity_Id; Def : Node_Id);

   procedure Analyze_Formal_Signed_Integer_Type (T : Entity_Id; Def : Node_Id);

   procedure Analyze_Formal_Modular_Type        (T : Entity_Id; Def : Node_Id);

   procedure Analyze_Formal_Ordinary_Fixed_Point_Type

                                                (T : Entity_Id; Def : Node_Id);

   procedure Analyze_Formal_Private_Type

     (N   : Node_Id;

      T   : Entity_Id;

      Def : Node_Id);

   --  Creates a new private type, which does not require completion

   procedure Analyze_Formal_Incomplete_Type (T : Entity_Id; Def : Node_Id);

   --  Ada 2012: Creates a new incomplete type whose actual does not freeze

   procedure Analyze_Generic_Formal_Part (N : Node_Id);

   --  Analyze generic formal part

   procedure Analyze_Generic_Access_Type (T : Entity_Id; Def : Node_Id);

   --  Create a new access type with the given designated type

   function Analyze_Associations

     (I_Node  : Node_Id;

      Formals : List_Id;

      F_Copy  : List_Id) return List_Id;

   --  At instantiation time, build the list of associations between formals

   --  and actuals. Each association becomes a renaming declaration for the

   --  formal entity. F_Copy is the analyzed list of formals in the generic

   --  copy. It is used to apply legality checks to the actuals. I_Node is the

   --  instantiation node itself.

   procedure Analyze_Subprogram_Instantiation

     (N : Node_Id;

      K : Entity_Kind);

   procedure Build_Instance_Compilation_Unit_Nodes

     (N        : Node_Id;

      Act_Body : Node_Id;

      Act_Decl : Node_Id);

   --  This procedure is used in the case where the generic instance of a

   --  subprogram body or package body is a library unit. In this case, the

   --  original library unit node for the generic instantiation must be

   --  replaced by the resulting generic body, and a link made to a new

   --  compilation unit node for the generic declaration. The argument N is

   --  the original generic instantiation. Act_Body and Act_Decl are the body

   --  and declaration of the instance (either package body and declaration

   --  nodes or subprogram body and declaration nodes depending on the case).

   --  On return, the node N has been rewritten with the actual body.

   procedure Check_Access_Definition (N : Node_Id);

   --  Subsidiary routine to null exclusion processing. Perform an assertion

   --  check on Ada version and the presence of an access definition in N.

   procedure Check_Formal_Packages (P_Id : Entity_Id);

   --  Apply the following to all formal packages in generic associations

   procedure Check_Formal_Package_Instance

     (Formal_Pack : Entity_Id;

      Actual_Pack : Entity_Id);

   --  Verify that the actuals of the actual instance match the actuals of

   --  the template for a formal package that is not declared with a box.

   procedure Check_Forward_Instantiation (Decl : Node_Id);

   --  If the generic is a local entity and the corresponding body has not

   --  been seen yet, flag enclosing packages to indicate that it will be

   --  elaborated after the generic body. Subprograms declared in the same

   --  package cannot be inlined by the front-end because front-end inlining

   --  requires a strict linear order of elaboration.

   function Check_Hidden_Primitives (Assoc_List : List_Id) return Elist_Id;

   --  Check if some association between formals and actuals requires to make

   --  visible primitives of a tagged type, and make those primitives visible.

   --  Return the list of primitives whose visibility is modified (to restore

   --  their visibility later through Restore_Hidden_Primitives). If no

   --  candidate is found then return No_Elist.

   procedure Check_Hidden_Child_Unit

     (N           : Node_Id;

      Gen_Unit    : Entity_Id;

      Act_Decl_Id : Entity_Id);

   --  If the generic unit is an implicit child instance within a parent

   --  instance, we need to make an explicit test that it is not hidden by

   --  a child instance of the same name and parent.

   procedure Check_Generic_Actuals

     (Instance      : Entity_Id;

      Is_Formal_Box : Boolean);

   --  Similar to previous one. Check the actuals in the instantiation,

   --  whose views can change between the point of instantiation and the point

   --  of instantiation of the body. In addition, mark the generic renamings

   --  as generic actuals, so that they are not compatible with other actuals.

   --  Recurse on an actual that is a formal package whose declaration has

   --  a box.

   function Contains_Instance_Of

     (Inner : Entity_Id;

      Outer : Entity_Id;

      N     : Node_Id) return Boolean;

   --  Inner is instantiated within the generic Outer. Check whether Inner

   --  directly or indirectly contains an instance of Outer or of one of its

   --  parents, in the case of a subunit. Each generic unit holds a list of

   --  the entities instantiated within (at any depth). This procedure

   --  determines whether the set of such lists contains a cycle, i.e. an

   --  illegal circular instantiation.

   function Denotes_Formal_Package

     (Pack     : Entity_Id;

      On_Exit  : Boolean := False;

      Instance : Entity_Id := Empty) return Boolean;

   --  Returns True if E is a formal package of an enclosing generic, or

   --  the actual for such a formal in an enclosing instantiation. If such

   --  a package is used as a formal in an nested generic, or as an actual

   --  in a nested instantiation, the visibility of ITS formals should not

   --  be modified. When called from within Restore_Private_Views, the flag

   --  On_Exit is true, to indicate that the search for a possible enclosing

   --  instance should ignore the current one. In that case Instance denotes

   --  the declaration for which this is an actual. This declaration may be

   --  an instantiation in the source, or the internal instantiation that

   --  corresponds to the actual for a formal package.

   function Earlier (N1, N2 : Node_Id) return Boolean;

   --  Yields True if N1 and N2 appear in the same compilation unit,

   --  ignoring subunits, and if N1 is to the left of N2 in a left-to-right

   --  traversal of the tree for the unit. Used to determine the placement

   --  of freeze nodes for instance bodies that may depend on other instances.

   function Find_Actual_Type

     (Typ       : Entity_Id;

      Gen_Type  : Entity_Id) return Entity_Id;

   --  When validating the actual types of a child instance, check whether

   --  the formal is a formal type of the parent unit, and retrieve the current

   --  actual for it. Typ is the entity in the analyzed formal type declaration

   --  (component or index type of an array type, or designated type of an

   --  access formal) and Gen_Type is the enclosing analyzed formal array

   --  or access type. The desired actual may be a formal of a parent, or may

   --  be declared in a formal package of a parent. In both cases it is a

   --  generic actual type because it appears within a visible instance.

   --  Finally, it may be declared in a parent unit without being a formal

   --  of that unit, in which case it must be retrieved by visibility.

   --  Ambiguities may still arise if two homonyms are declared in two formal

   --  packages, and the prefix of the formal type may be needed to resolve

   --  the ambiguity in the instance ???

   function In_Same_Declarative_Part

     (F_Node : Node_Id;

      Inst   : Node_Id) return Boolean;

   --  True if the instantiation Inst and the given freeze_node F_Node appear

   --  within the same declarative part, ignoring subunits, but with no inter-

   --  vening subprograms or concurrent units. Used to find the proper plave

   --  for the freeze node of an instance, when the generic is declared in a

   --  previous instance. If predicate is true, the freeze node of the instance

   --  can be placed after the freeze node of the previous instance, Otherwise

   --  it has to be placed at the end of the current declarative part.

   function In_Main_Context (E : Entity_Id) return Boolean;

   --  Check whether an instantiation is in the context of the main unit.

   --  Used to determine whether its body should be elaborated to allow

   --  front-end inlining.

   procedure Set_Instance_Env

     (Gen_Unit : Entity_Id;

      Act_Unit : Entity_Id);

   --  Save current instance on saved environment, to be used to determine

   --  the global status of entities in nested instances. Part of Save_Env.

   --  called after verifying that the generic unit is legal for the instance,

   --  The procedure also examines whether the generic unit is a predefined

   --  unit, in order to set configuration switches accordingly. As a result

   --  the procedure must be called after analyzing and freezing the actuals.

   procedure Set_Instance_Of (A : Entity_Id; B : Entity_Id);

   --  Associate analyzed generic parameter with corresponding

   --  instance. Used for semantic checks at instantiation time.

   function Has_Been_Exchanged (E : Entity_Id) return Boolean;

   --  Traverse the Exchanged_Views list to see if a type was private

   --  and has already been flipped during this phase of instantiation.

   procedure Hide_Current_Scope;

   --  When instantiating a generic child unit, the parent context must be

   --  present, but the instance and all entities that may be generated

   --  must be inserted in the current scope. We leave the current scope

   --  on the stack, but make its entities invisible to avoid visibility

   --  problems. This is reversed at the end of the instantiation. This is

   --  not done for the instantiation of the bodies, which only require the

   --  instances of the generic parents to be in scope.

   procedure Install_Body

     (Act_Body : Node_Id;

      N        : Node_Id;

      Gen_Body : Node_Id;

      Gen_Decl : Node_Id);

   --  If the instantiation happens textually before the body of the generic,

   --  the instantiation of the body must be analyzed after the generic body,

   --  and not at the point of instantiation. Such early instantiations can

   --  happen if the generic and the instance appear in  a package declaration

   --  because the generic body can only appear in the corresponding package

   --  body. Early instantiations can also appear if generic, instance and

   --  body are all in the declarative part of a subprogram or entry. Entities

   --  of packages that are early instantiations are delayed, and their freeze

   --  node appears after the generic body.

   procedure Insert_Freeze_Node_For_Instance

     (N      : Node_Id;

      F_Node : Node_Id);

   --  N denotes a package or a subprogram instantiation and F_Node is the

   --  associated freeze node. Insert the freeze node before the first source

   --  body which follows immediately after N. If no such body is found, the

   --  freeze node is inserted at the end of the declarative region which

   --  contains N.

   procedure Freeze_Subprogram_Body

     (Inst_Node : Node_Id;

      Gen_Body  : Node_Id;

      Pack_Id   : Entity_Id);

   --  The generic body may appear textually after the instance, including

   --  in the proper body of a stub, or within a different package instance.

   --  Given that the instance can only be elaborated after the generic, we

   --  place freeze_nodes for the instance and/or for packages that may enclose

   --  the instance and the generic, so that the back-end can establish the

   --  proper order of elaboration.

   procedure Init_Env;

   --  Establish environment for subsequent instantiation. Separated from

   --  Save_Env because data-structures for visibility handling must be

   --  initialized before call to Check_Generic_Child_Unit.

   procedure Install_Formal_Packages (Par : Entity_Id);

   --  Install the visible part of any formal of the parent that is a formal

   --  package. Note that for the case of a formal package with a box, this

   --  includes the formal part of the formal package (12.7(10/2)).

   procedure Install_Parent (P : Entity_Id; In_Body : Boolean := False);

   --  When compiling an instance of a child unit the parent (which is

   --  itself an instance) is an enclosing scope that must be made

   --  immediately visible. This procedure is also used to install the non-

   --  generic parent of a generic child unit when compiling its body, so

   --  that full views of types in the parent are made visible.

   procedure Remove_Parent (In_Body : Boolean := False);

   --  Reverse effect after instantiation of child is complete

   procedure Install_Hidden_Primitives

     (Prims_List : in out Elist_Id;

      Gen_T      : Entity_Id;

      Act_T      : Entity_Id);

   --  Remove suffix 'P' from hidden primitives of Act_T to match the

   --  visibility of primitives of Gen_T. The list of primitives to which

   --  the suffix is removed is added to Prims_List to restore them later.

   procedure Restore_Hidden_Primitives (Prims_List : in out Elist_Id);

   --  Restore suffix 'P' to primitives of Prims_List and leave Prims_List

   --  set to No_Elist.

   procedure Inline_Instance_Body

     (N        : Node_Id;

      Gen_Unit : Entity_Id;

      Act_Decl : Node_Id);

   --  If front-end inlining is requested, instantiate the package body,

   --  and preserve the visibility of its compilation unit, to insure

   --  that successive instantiations succeed.

   --  The functions Instantiate_XXX perform various legality checks and build

   --  the declarations for instantiated generic parameters. In all of these

   --  Formal is the entity in the generic unit, Actual is the entity of

   --  expression in the generic associations, and Analyzed_Formal is the

   --  formal in the generic copy, which contains the semantic information to

   --  be used to validate the actual.

   function Instantiate_Object

     (Formal          : Node_Id;

      Actual          : Node_Id;

      Analyzed_Formal : Node_Id) return List_Id;

   function Instantiate_Type

     (Formal          : Node_Id;

      Actual          : Node_Id;

      Analyzed_Formal : Node_Id;

      Actual_Decls    : List_Id) return List_Id;

   function Instantiate_Formal_Subprogram

     (Formal          : Node_Id;

      Actual          : Node_Id;

      Analyzed_Formal : Node_Id) return Node_Id;

   function Instantiate_Formal_Package

     (Formal          : Node_Id;

      Actual          : Node_Id;

      Analyzed_Formal : Node_Id) return List_Id;

   --  If the formal package is declared with a box, special visibility rules

   --  apply to its formals: they are in the visible part of the package. This

   --  is true in the declarative region of the formal package, that is to say

   --  in the enclosing generic or instantiation. For an instantiation, the

   --  parameters of the formal package are made visible in an explicit step.

   --  Furthermore, if the actual has a visible USE clause, these formals must

   --  be made potentially use-visible as well. On exit from the enclosing

   --  instantiation, the reverse must be done.

   --  For a formal package declared without a box, there are conformance rules

   --  that apply to the actuals in the generic declaration and the actuals of

   --  the actual package in the enclosing instantiation. The simplest way to

   --  apply these rules is to repeat the instantiation of the formal package

   --  in the context of the enclosing instance, and compare the generic

   --  associations of this instantiation with those of the actual package.

   --  This internal instantiation only needs to contain the renamings of the

   --  formals: the visible and private declarations themselves need not be

   --  created.

   --  In Ada 2005, the formal package may be only partially parameterized.

   --  In that case the visibility step must make visible those actuals whose

   --  corresponding formals were given with a box. A final complication

   --  involves inherited operations from formal derived types, which must

   --  be visible if the type is.

   function Is_In_Main_Unit (N : Node_Id) return Boolean;

   --  Test if given node is in the main unit

   procedure Load_Parent_Of_Generic

     (N             : Node_Id;

      Spec          : Node_Id;

      Body_Optional : Boolean := False);

   --  If the generic appears in a separate non-generic library unit, load the

   --  corresponding body to retrieve the body of the generic. N is the node

   --  for the generic instantiation, Spec is the generic package declaration.

   --

   --  Body_Optional is a flag that indicates that the body is being loaded to

   --  ensure that temporaries are generated consistently when there are other

   --  instances in the current declarative part that precede the one being

   --  loaded. In that case a missing body is acceptable.

   procedure Inherit_Context (Gen_Decl : Node_Id; Inst : Node_Id);

   --  Add the context clause of the unit containing a generic unit to a

   --  compilation unit that is, or contains, an instantiation.

   function Get_Associated_Node (N : Node_Id) return Node_Id;

   --  In order to propagate semantic information back from the analyzed copy

   --  to the original generic, we maintain links between selected nodes in the

   --  generic and their corresponding copies. At the end of generic analysis,

   --  the routine Save_Global_References traverses the generic tree, examines

   --  the semantic information, and preserves the links to those nodes that

   --  contain global information. At instantiation, the information from the

   --  associated node is placed on the new copy, so that name resolution is

   --  not repeated.

   --

   --  Three kinds of source nodes have associated nodes:

   --

   --    a) those that can reference (denote) entities, that is identifiers,

   --       character literals, expanded_names, operator symbols, operators,

   --       and attribute reference nodes. These nodes have an Entity field

   --       and are the set of nodes that are in N_Has_Entity.

   --

   --    b) aggregates (N_Aggregate and N_Extension_Aggregate)

   --

   --    c) selected components (N_Selected_Component)

   --

   --  For the first class, the associated node preserves the entity if it is

   --  global. If the generic contains nested instantiations, the associated

   --  node itself has been recopied, and a chain of them must be followed.

   --

   --  For aggregates, the associated node allows retrieval of the type, which

   --  may otherwise not appear in the generic. The view of this type may be

   --  different between generic and instantiation, and the full view can be

   --  installed before the instantiation is analyzed. For aggregates of type

   --  extensions, the same view exchange may have to be performed for some of

   --  the ancestor types, if their view is private at the point of

   --  instantiation.

   --

   --  Nodes that are selected components in the parse tree may be rewritten

   --  as expanded names after resolution, and must be treated as potential

   --  entity holders, which is why they also have an Associated_Node.

   --

   --  Nodes that do not come from source, such as freeze nodes, do not appear

   --  in the generic tree, and need not have an associated node.

   --

   --  The associated node is stored in the Associated_Node field. Note that

   --  this field overlaps Entity, which is fine, because the whole point is

   --  that we don't need or want the normal Entity field in this situation.

   procedure Map_Formal_Package_Entities (Form : Entity_Id; Act : Entity_Id);

   --  Within the generic part, entities in the formal package are

   --  visible. To validate subsequent type declarations, indicate

   --  the correspondence between the entities in the analyzed formal,

   --  and the entities in  the actual package. There are three packages

   --  involved in the instantiation of a formal package: the parent

   --  generic P1 which appears in the generic declaration, the fake

   --  instantiation P2 which appears in the analyzed generic, and whose

   --  visible entities may be used in subsequent formals, and the actual

   --  P3 in the instance. To validate subsequent formals, me indicate

   --  that the entities in P2 are mapped into those of P3. The mapping of

   --  entities has to be done recursively for nested packages.

   procedure Move_Freeze_Nodes

     (Out_Of : Entity_Id;

      After  : Node_Id;

      L      : List_Id);

   --  Freeze nodes can be generated in the analysis of a generic unit, but

   --  will not be seen by the back-end. It is necessary to move those nodes

   --  to the enclosing scope if they freeze an outer entity. We place them

   --  at the end of the enclosing generic package, which is semantically

   --  neutral.

   procedure Preanalyze_Actuals (N : Node_Id);

   --  Analyze actuals to perform name resolution. Full resolution is done

   --  later, when the expected types are known, but names have to be captured

   --  before installing parents of generics, that are not visible for the

   --  actuals themselves.

   function True_Parent (N : Node_Id) return Node_Id;

   --  For a subunit, return parent of corresponding stub, else return

   --  parent of node.

   procedure Valid_Default_Attribute (Nam : Entity_Id; Def : Node_Id);

   --  Verify that an attribute that appears as the default for a formal

   --  subprogram is a function or procedure with the correct profile.

   -------------------------------------------

   -- Data Structures for Generic Renamings --

   -------------------------------------------

   --  The map Generic_Renamings associates generic entities with their

   --  corresponding actuals. Currently used to validate type instances. It

   --  will eventually be used for all generic parameters to eliminate the

   --  need for overload resolution in the instance.

   type Assoc_Ptr is new Int;

   Assoc_Null : constant Assoc_Ptr := -1;

   type Assoc is record

      Gen_Id         : Entity_Id;

      Act_Id         : Entity_Id;

      Next_In_HTable : Assoc_Ptr;

   end record;

   package Generic_Renamings is new Table.Table

     (Table_Component_Type => Assoc,

      Table_Index_Type     => Assoc_Ptr,

      Table_Low_Bound      => 0,

      Table_Initial        => 10,

      Table_Increment      => 100,

      Table_Name           => "Generic_Renamings");

   --  Variable to hold enclosing instantiation. When the environment is

   --  saved for a subprogram inlining, the corresponding Act_Id is empty.

   Current_Instantiated_Parent : Assoc := (Empty, Empty, Assoc_Null);

   --  Hash table for associations

   HTable_Size : constant := 37;

   type HTable_Range is range 0 .. HTable_Size - 1;

   procedure Set_Next_Assoc (E : Assoc_Ptr; Next : Assoc_Ptr);

   function  Next_Assoc     (E : Assoc_Ptr) return Assoc_Ptr;

   function Get_Gen_Id      (E : Assoc_Ptr) return Entity_Id;

   function Hash            (F : Entity_Id) return HTable_Range;

   package Generic_Renamings_HTable is new GNAT.HTable.Static_HTable (

      Header_Num => HTable_Range,

      Element    => Assoc,

      Elmt_Ptr   => Assoc_Ptr,

      Null_Ptr   => Assoc_Null,

      Set_Next   => Set_Next_Assoc,

      Next       => Next_Assoc,

      Key        => Entity_Id,

      Get_Key    => Get_Gen_Id,

      Hash       => Hash,

      Equal      => "=");

   Exchanged_Views : Elist_Id;

   --  This list holds the private views that have been exchanged during

   --  instantiation to restore the visibility of the generic declaration.

   --  (see comments above). After instantiation, the current visibility is

   --  reestablished by means of a traversal of this list.

   Hidden_Entities : Elist_Id;

   --  This list holds the entities of the current scope that are removed

   --  from immediate visibility when instantiating a child unit. Their

   --  visibility is restored in Remove_Parent.

   --  Because instantiations can be recursive, the following must be saved

   --  on entry and restored on exit from an instantiation (spec or body).

   --  This is done by the two procedures Save_Env and Restore_Env. For