-- The algorithm of Resolve_Record_Aggregate proceeds as follows:
--
-- 1. Make sure that the record type against which the record aggregate
- -- has to be resolved is not abstract. Furthermore if the type is
- -- a null aggregate make sure the input aggregate N is also null.
+ -- has to be resolved is not abstract. Furthermore if the type is a
+ -- null aggregate make sure the input aggregate N is also null.
--
-- 2. Verify that the structure of the aggregate is that of a record
-- aggregate. Specifically, look for component associations and ensure
-- node. Also make sure that if present, the N_Others_Choice occurs
-- last and by itself.
--
- -- 3. If Typ contains discriminants, the values for each discriminant
- -- is looked for. If the record type Typ has variants, we check
- -- that the expressions corresponding to each discriminant ruling
- -- the (possibly nested) variant parts of Typ, are static. This
- -- allows us to determine the variant parts to which the rest of
- -- the aggregate must conform. The names of discriminants with their
- -- values are saved in a new association list, New_Assoc_List which
- -- is later augmented with the names and values of the remaining
- -- components in the record type.
+ -- 3. If Typ contains discriminants, the values for each discriminant is
+ -- looked for. If the record type Typ has variants, we check that the
+ -- expressions corresponding to each discriminant ruling the (possibly
+ -- nested) variant parts of Typ, are static. This allows us to determine
+ -- the variant parts to which the rest of the aggregate must conform.
+ -- The names of discriminants with their values are saved in a new
+ -- association list, New_Assoc_List which is later augmented with the
+ -- names and values of the remaining components in the record type.
--
-- During this phase we also make sure that every discriminant is
- -- assigned exactly one value. Note that when several values
- -- for a given discriminant are found, semantic processing continues
- -- looking for further errors. In this case it's the first
- -- discriminant value found which we will be recorded.
+ -- assigned exactly one value. Note that when several values for a given
+ -- discriminant are found, semantic processing continues looking for
+ -- further errors. In this case it's the first discriminant value found
+ -- which we will be recorded.
--
-- IMPORTANT NOTE: For derived tagged types this procedure expects
-- First_Discriminant and Next_Discriminant to give the correct list
-- of discriminants, in the correct order.
--
- -- 4. After all the discriminant values have been gathered, we can
- -- set the Etype of the record aggregate. If Typ contains no
- -- discriminants this is straightforward: the Etype of N is just
- -- Typ, otherwise a new implicit constrained subtype of Typ is
- -- built to be the Etype of N.
+ -- 4. After all the discriminant values have been gathered, we can set the
+ -- Etype of the record aggregate. If Typ contains no discriminants this
+ -- is straightforward: the Etype of N is just Typ, otherwise a new
+ -- implicit constrained subtype of Typ is built to be the Etype of N.
--
-- 5. Gather the remaining record components according to the discriminant
-- values. This involves recursively traversing the record type
-- derived tagged types since we need to retrieve the record structure
-- of all the ancestors of Typ.
--
- -- 6. After gathering the record components we look for their values
- -- in the record aggregate and emit appropriate error messages
- -- should we not find such values or should they be duplicated.
+ -- 6. After gathering the record components we look for their values in the
+ -- record aggregate and emit appropriate error messages should we not
+ -- find such values or should they be duplicated.
--
- -- 7. We then make sure no illegal component names appear in the
- -- record aggregate and make sure that the type of the record
- -- components appearing in a same choice list is the same.
- -- Finally we ensure that the others choice, if present, is
- -- used to provide the value of at least a record component.
+ -- 7. We then make sure no illegal component names appear in the record
+ -- aggregate and make sure that the type of the record components
+ -- appearing in a same choice list is the same. Finally we ensure that
+ -- the others choice, if present, is used to provide the value of at
+ -- least a record component.
--
- -- 8. The original aggregate node is replaced with the new named
- -- aggregate built in steps 3 through 6, as explained earlier.
+ -- 8. The original aggregate node is replaced with the new named aggregate
+ -- built in steps 3 through 6, as explained earlier.
--
- -- Given the complexity of record aggregate resolution, the primary
- -- goal of this routine is clarity and simplicity rather than execution
- -- and storage efficiency. If there are only positional components in the
- -- aggregate the running time is linear. If there are associations
- -- the running time is still linear as long as the order of the
- -- associations is not too far off the order of the components in the
- -- record type. If this is not the case the running time is at worst
- -- quadratic in the size of the association list.
+ -- Given the complexity of record aggregate resolution, the primary goal of
+ -- this routine is clarity and simplicity rather than execution and storage
+ -- efficiency. If there are only positional components in the aggregate the
+ -- running time is linear. If there are associations the running time is
+ -- still linear as long as the order of the associations is not too far off
+ -- the order of the components in the record type. If this is not the case
+ -- the running time is at worst quadratic in the size of the association
+ -- list.
procedure Check_Misspelled_Component
(Elements : Elist_Id;
Component : Node_Id);
- -- Give possible misspelling diagnostic if Component is likely to be
- -- a misspelling of one of the components of the Assoc_List.
- -- This is called by Resolve_Aggr_Expr after producing
- -- an invalid component error message.
+ -- Give possible misspelling diagnostic if Component is likely to be a
+ -- misspelling of one of the components of the Assoc_List. This is called
+ -- by Resolve_Aggr_Expr after producing an invalid component error message.
procedure Check_Static_Discriminated_Subtype (T : Entity_Id; V : Node_Id);
- -- An optimization: determine whether a discriminated subtype has a
- -- static constraint, and contains array components whose length is also
- -- static, either because they are constrained by the discriminant, or
- -- because the original component bounds are static.
+ -- An optimization: determine whether a discriminated subtype has a static
+ -- constraint, and contains array components whose length is also static,
+ -- either because they are constrained by the discriminant, or because the
+ -- original component bounds are static.
-----------------------------------------------------
-- Subprograms used for ARRAY AGGREGATE Processing --
-- --
-- B o d y --
-- --
--- Copyright (C) 1992-2008, Free Software Foundation, Inc. --
+-- Copyright (C) 1992-2009, 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- --
-- The following data structures establish a mapping between nodes and
-- their interpretations. An overloaded node has an entry in Interp_Map,
-- which in turn contains a pointer into the All_Interp array. The
- -- interpretations of a given node are contiguous in All_Interp. Each
- -- set of interpretations is terminated with the marker No_Interp.
- -- In order to speed up the retrieval of the interpretations of an
- -- overloaded node, the Interp_Map table is accessed by means of a simple
- -- hashing scheme, and the entries in Interp_Map are chained. The heads
- -- of clash lists are stored in array Headers.
+ -- interpretations of a given node are contiguous in All_Interp. Each set
+ -- of interpretations is terminated with the marker No_Interp. In order to
+ -- speed up the retrieval of the interpretations of an overloaded node, the
+ -- Interp_Map table is accessed by means of a simple hashing scheme, and
+ -- the entries in Interp_Map are chained. The heads of clash lists are
+ -- stored in array Headers.
-- Headers Interp_Map All_Interp
-- Operator Overloading --
--------------------------
- -- The visibility of operators is handled differently from that of
- -- other entities. We do not introduce explicit versions of primitive
- -- operators for each type definition. As a result, there is only one
- -- entity corresponding to predefined addition on all numeric types, etc.
- -- The back-end resolves predefined operators according to their type.
- -- The visibility of primitive operations then reduces to the visibility
- -- of the resulting type: (a + b) is a legal interpretation of some
- -- primitive operator + if the type of the result (which must also be
- -- the type of a and b) is directly visible (i.e. either immediately
- -- visible or use-visible.)
+ -- The visibility of operators is handled differently from that of other
+ -- entities. We do not introduce explicit versions of primitive operators
+ -- for each type definition. As a result, there is only one entity
+ -- corresponding to predefined addition on all numeric types, etc. The
+ -- back-end resolves predefined operators according to their type. The
+ -- visibility of primitive operations then reduces to the visibility of the
+ -- resulting type: (a + b) is a legal interpretation of some primitive
+ -- operator + if the type of the result (which must also be the type of a
+ -- and b) is directly visible (either immediately visible or use-visible).
-- User-defined operators are treated like other functions, but the
-- visibility of these user-defined operations must be special-cased
projects / platform / upstream / linaro-gcc.git / commitdiff